Being as stubborn as it gets, I'm building my own PHP-based CMS and framework (named RAmen/FSM just for the kicks) that has been deployed multiple times for my customers. Now, I'm going to develop a support ticket application for it that I will deploy on a 'central' server for convenience of maintenance.
Now, I've looked into SOAP services and was happy until I got to WSDL generation in PHP and in itself. So, what would you suggest for me to 'securely' (as in, no https) manage this with SOAP-like simplicity on the client side ($support->newTicket), without the WSDL headaches on the server side? Or should I –gasp– stop being so stubborn and just go with a PHP library (in which case, please do recommend!)
Thank you, fellow pastafarians/spagnostic coders!
PHP has a native SOAP extension, that automates client as well as server. It is a little buggy in some places, but still better than nusoap (IMHO).
That said, I would never chose SOAP if I had any bearing on the decision. Use xml-rpc or a rest-based approach.
I have a similar question, whether to use REST or SOAP. I am using REST but that is beacuse i want a simple API like function not so much the rigid functionality associated with REST.
That being said here is a nice little library to get you started on SOAP
http://sourceforge.net/projects/nusoap/
By the sounds of it SOAP is actually what you want. you will fin it a bit easier to implement as you get the domain models from the WSDL.
Related
If I want to create a web service or consume a web service that is defined as WSDL 2.0, what options do I have in PHP?
As I understand it the in-built SOAP libs in 5.x don't currently support WSDL 2.0 spec, and I can't see future support for this.
One of my former colleagues used to devour SOAP services manually, simply because he disliked the current .net implementation.
The SOAP implementation is based around you posting XML across the web to the service, and you "just" need to build a such XML and parse the results coming back. It is not as simple as it sounds, but it definitely is possible.
The WSDL2PHP project seems very interesting, and im very sure this can lead you in the right direction.
The most useful thing I like about SOAP vs REST is the WSDL. It makes my life much easier when creating applications for the iPhone as my classes can be generated for me without me doing much monkey work.
However, I'm trying to find a suitable alternative to ASMX/WCF. I predominantly use a Mac so Java, PHP or Mono solutions are mainly of interest to me.
I understand PHP has a SOAP service offering but it can't automatically generate a WSDL? Are there any tools which can facilitate this?
There are many java based soap stacks. I would look at Apache CXF (http://cxf.apache.org/). See also its WSDL generation at http://cxf.apache.org/docs/soap-12.html.
The latest versions have pretty good support for WSDL.
http://php.net/manual/en/book.soap.php
Here's a quick guide for it:
http://www.phpbuilder.com/columns/adam_delves20060606.php3
I am working on a task where it is required to distribute live data (being fetched from some other server) to client using sockets. We user drupal as a framework and thus my choice of PHP.
1)I want to know the major factors that should be taken into consideration while developing this server.Like security,authentication,load etc and how should i approach this.Is there any blog/article that could be of help.
2)Is there a better choice than PHP for this?
3)ALSO is there any drupal module that could assist me in this.
I can think about one issue when you are talking about several servers connecting to you, you may want to conceder a nonblock mode.
Because when you are working with blocking mod, each server can connect at the time, meaning that there will be delay delivering the message.
http://il2.php.net/manual/en/function.socket-set-nonblock.php
I think java would be better choise, multi thread may help here.
from my point of view, this is something that you need to develop your self, socket programming needs a lot of attention.
Drupal is a Web CMS, it can be used as framework for advanced web features or light to medium web application that fits well in the traditional HTTP request paradigm. IMHO, distributing live data from multiple servers to client using sockets doesn't fit with the base assumption behind Drupal's design.
PHP can be used to write socket server. It used to be un-common, but it is becoming more and more available. ReactPHP is a non-blocking I/O library/framework suited for socket programing. Racthet is a websocket server in PHP using ReactPHP.
In any case, this would ne nothing like developing a web application with RoR, Drupal, Django, Symfony, etc.
If integration with a Drupal website is required, the Service module is a nice solution to provides a REST or XML-RPC API. Or course, direct access to Drupal's MySQL database is also an option but will probably require more knowledge of the used Drupal modules since you will have to replicate their behaviors and understand how they manage their data (for instance, how a particular CCK field is stored in your database).
Note: Previous version of this answer included reference to the following solutions in other languages: Twisted (Python), EventMachine (Ruby) and Node.js (JavaScript). These are all valid solutions when PHP is not required.
Previous version of the answer also referenced phpsocketdaemon, but nowadays ReactPHP is a more clean and robust solution.
My question is needed for some basic understanding of webservices and more specificly
in conjunction with php
I would like to know, if it is necessary to have a wsdl file for the creation of a webservice or is that just something that is usefull to third party's that want to access the webservice?
Also, it's generated automaticly in .net environments, but for php it's a bit more difficult.
What are my options?
The thing I am after is to create a jm2ee application on my mobile that sends data to the webservice from time to time.
I read somewhere that you have to supply the arguments when there is no wsdl file.
What is meant by that? and/or what are the implications of that?
Thanks in advance, Richard
I would like to know, if it is
neccasary to have a wsdl file for the
creation off a webservice
No, it is not necessary (at least, not in PHP) : it helps others know how to access your webservice (which methods, objects, ... should be used), but a WS can be called even if it doesn't export a WSDL
For PHP, yes, it is a bit difficult to get a WSDL (many classes don't generated them :-( ) ; still, you can generatd it with another tool (there are tools in Eclipse to write WSDL files, for example).
There was PEAR::Soap that was able to generate WSDL from PHP code (but you had to write down many lines of code to get it right) -- considering there is a class included in PHP 5 to work with SOAP, I wouldn't recommend using this one, anyway.
For more informations, you can have a look at :
SoapServer ; especially, if you look at the documentation of SoapServer::__construct, you will notice it can work both in WSDL and non-WSDL mode
Zend_Soap
If you are creating both the client and the web service, then there is no particular need to futz with SOAP, WSDL, or any of that jazz.
Just use the basics of the web: the client can use GET to fetch information, and POST to send it. You can format the data any way you like, but JSON and XML are common, well-defined approaches.
If you'd like inspiration for your API design, check out some popular examples:
Twitter API
Flickr API
all the Google APIs
all the Yahoo APIs
That's enough to get you started, but if you're curious about the design philosophy, you can read up on Representational State Transfer or REST.
WSDL file documents in a machine readable (XML) format what the methods (and args for methods) offered by a web service. You do not need a WSDL file if you know what the methods and args are - though WSDL is very good to have as a means of making the web service public interface more 'contractified', if you will.
To the best of my knowledge the PHP library does not have functions to automagically generate a WSDL file for you.
Web service support is built into php5, your best starting place is the documentation.
Some sources will use the term "webservice" as synonymous with SOAP. That is a misnomer. SOAP is a particular protocol - It is one way to create a web service. There are other technologies available. In general SOAP is the preferred standard with in Java and .net, but it is a bad fit outside of this sphere. If you have the option, I would strongly suggest that you consider either xml-rpc (Which is simpler and has better direct support on php) or a http-based service (Also called REST based).
What is the best method for communication between Flex and PHP?
In the past, we used AMFPHP with AS2, and it worked great for the most part (advantage of AMFPHP is that it also has a JSON mode that can let you seamlessly use the same remote PHP with either Javascript or Actionscript frontends).
However, it seems like AMFPHP isn't realy maintained anymore. So what do people recommend to replace it? So far, what I've found is:
Zend_AMF (looks too complex for us, we're not using the Zend framework otherwise)
AMFPHP (there were some updated made to support Flex, and it seems fairly stable, but not sure on long-term support)
XML (AS3 has nice XML handling routines, but it's more of a pain on the PHP side)
WebORB (I have no experience with this)
Roll-our-own using JSON or some other data-to-text serialization system (php's serialize(), XML, etc etc)
Mostly I'm leaning towards AMFPHP, even because of the downsides, since that's what I'm used to. Any reason I should consider switching to something else?
If you want to have fast and efficient communication, I highly recommend sticking with an AMF protocol instead of a REST or JSON custom format.
ZendAMF is actually not very confusing. Watch the introduction tutorial on GotoAndLearn, it's quite simple.
And just so you know, some of the developers from AMFPHP moved to work on ZendAMF. So in a sense, ZendAMF is the continuation of AMFPHP.
ZendAMF
Good short read - http://theflashblog.com/?p=441
For me this is no brainer. The Zend framework is one of the best php frameworks out there, and now you can talk to Flash clients. Top it off with Adobe support, that's a done deal in my book.
Alternatives :
WebORB for php
http://www.themidnightcoders.com/products/weborb-for-php
AMFPHP
http://www.amfphp.com
If you read the url above, you'll probably know why this is no longer on my radar.
I can't tell you what's best (because that's probably somewhat subjective anyway), but what I can do is tell you about a recent project of mine.
Since this was a very rich web app, and data requests to the server would be frequent, I wanted to make sure the size of the requests were as small as possible. This mean choosing JSON as the format.
Next, becuase of the nature of the application and the fact that my flash/flex developers were 1000 miles away, I needed an API that was simple and stateless. This ultimately led us to HTTP + REST.
So, the communication layer of my app is a simple Zend Framework powered set of REST resources with URIs like
user/10
review/15
location/8/reviews
They all return JSON. There's a common JSON format for all errors, as well (exceptions are trapped and converted into JSON objects) so that the flash client can easily handle failure.
If you're not using a framework like Zend, regular ol AMFPHP is still great, if for no other reason than that it's simple. I think if you feel comfortable with it, why not go for it? The thing about the role of these AMF interfaces is that they really don't need to do too much, and what AMFPHP does have in class mapping, recordset parsing into ArrayCollection, great performance.... it even does well with XML, since it gets compressed. The service browser combined with Charles has covered me as well.
I haven't been able to make much sense of how the ZendAMF effort relates to the original AMFPHP. While I can dig, I'm just saying that in following the AMFPHP mailing list on Nabble, reading Wade Arnold's blog... it's just not entirely clear.
You should consider using Zend AMF. The Zend Framework is designed to be a pick and chose framework so it is completely OK to pick a single component (in this case Zend AMF) for your application.
Zend AMF is extremely easy to use. All you have to do is specify the functions/classes you want to expose and specify class mapping to your action-script classes. Everything else is pretty much transparent.
This link is a screencast showing how to use WebORB for PHP WDMF (WebORB Data Management for Flex).
http://www.themidnightcoders.com/products/weborb-for-php/developer-den/screencasts/weborb-data-management-for-flex-and-php.html
In all projects involving Flash and PHP backend, I worked with either AMFPHP or XML requests.
AMFPHP really simplifies understanting the application for future maintenance, although it ties the whole thing to that specific technology and involves some additional overhead on the server side - to create all needed classes.
As per XML, well, what you gain here are standard REST webservices and it doesn't depend on Flash (you could pull data from a desktop app as well, for example, whereas using JSON or any other technology dependent on browsers don't allow for that).
If you want 100% future "support", then I'd recommend what doesn't need any support at all: XML.
XML on PHP can be a lot simpler with SimpleXML.
I'd just use JSON as your returns for simple calls against your PHP api.
I would definitely go for WebORB. I used it with .NET in a previous job I had and it was a joy to code with. Its ease of use and its well thought management console make it very fast to learn, and its documentation is very complete; I know it's tempting to stay with AMF just because it's what you already know, but I believe it's worth to give WebORB a try.
Take a look at this screencast for Actionscript generation with PHP, it's quite fancy.
Cheers.
PHP has a pretty good serialize() function, so for a recent project I did (high scores for a game), I used Sephiroth's Serializer. It makes the serialization on Flash's side nearly as easy as it is in PHP. Serializer also deals with datatypes (unlike json/xml) like AMF.
Downside--it's not as compact as AMF, but that's nothing gzip compression can't handle.
AMF has a pretty situational advantage. If you're looking to transfer large and complex Object, by all means go with AMF. But little does people know about the overhead that AMF carries when you're transferring small objects. If you're only transferring an object with 3 properties, using AMF can triple your payload size.
On a side note, I'm a big advocate of RESTful architecture. Since JSON and AMF are both just representations, you can build a REST service that accepts both, and negotiate the actual representation with your client at runtime.
"If you want to have fast and efficient communication, I highly recommend sticking with an AMF protocol"
And if you want a fast, efficient, and generalized communication, go with json. Then your web service will be available to flash, ajax, or regular http requests.