feda alshahwan wrote:What is better for implementing mobile web services : SOAP or REST
In most cases SOAP is not required because its flexibity, extensibility (and therefore associated complexity) isn't required for the mobile to service interaction. And in any case the web service can always act a proxy for the mobile client, taking the burden of the necessary conversions.
RESTful web services can be accessed with simple HTTP interactions and aren't restricted to XML content either. So when appropriate, your mobile client can set the HTTP-request Accept header to text/plain and receive, for example, a comma separated list of values, provided of course that the resource supports the text/plain media type with that representation format.
The point is that a resource can be implemented to support any number of IANA MIME Media Types (simultaneously).
It seems however that mobile clients prefer web servers that are capable of flushing the HTTP reponse headers separately from the HTTP response body. That gives the client environment a chance to properly prepare for the receipt of potentially large amounts of data.
What do you mean by Mime Iana? I want web services both for mobile client and mobile server. The advantage of Soap over rest that it allows running over other protocols not only HTTP? Do you have any other opinion?
feda alshahwan wrote:What do you mean by Mime Iana?
Click on the link.
SOAP is restricted to XML. So non-XML content has to be base64 encoded or you have to employ one of the attachment technologies for SOAP (no attachment technology enjoys universal support). You can put anything in the HTTP body as long as you identify it with the correct IANA MIME Media Type in the Content-Type HTTP header.
The advantage of Soap over rest that it allows running over other protocols not only HTTP?
That is correct. However in the majority of cases that feature will never be used. So all the development effort and runtime overhead that goes into dealing with the added SOAP layer is completely wasted for features that are never harnessed.
If you have a legitimate reason right now or in the near future to require moving SOAP messages over a protocol other than HTTP, development tools that support binding to protocols other than HTTP and a mobile platform that has plenty of power to spare to absorb the processing overhead of XML and SOAP - then go ahead. However in many cases it still makes more sense to keep the communication between the mobile and (stationary) server "light" - if necessary the stationary server can add the necessary SOAP layer if the message needs to move on.
I read about rest and rpc differences and I think that using REST for consuming and producing web services by mobiles is better. But since I know nothing about mobile applications and REST. So How can I start doing it please?