> I would make this argument instead: REST or SOAP?
That was prob. the question that the orignal poster wanted to ask.
> A big part of creating a seamless experience on mobile devices is to be able
> to handle* limited connectivity* (temporary loss of connection) and to have
> *stateless* (remote) services available (user can access data directly
> without going through a list of other prior service-calls to get there).
Yes, this is a very important propperty of mobile programs to handel.
Connection could be very unstable, even in cities (like tunnels).
> SOAP can't handle this very well. SOAP is very stateful. It's much like RPC
> where the caller often needs to be aware of the server's state to make
> correct calls.
> SOAP calls are hard to cache. And you'll need a cache if you want to handle
> limited connectivity.
SOAP has more than one way to skin a cat, so to speak.
You can design SOAP services in a RPC manner, but it could also be
documment orientated, more like RESTful services.
You are also not limited to HTTP(S) transports with Web Services (WS)
and SOAP, you can also use SMTP and XMPP as transport. With SMTP you
don't want RPC-orientated WS. :)
> REST is better suited to deal with this. True RESTful services are stateless
> (you could have a cookie for authentication, for example, but no more than
> that should be stored in a stateful session). RESTful services are designed
> to handle caches efficiently.
A true RESTful service, which many are not, is only stateless. So
yes, in many ways RESTful services are good choices, esp. for smal
projects. The strong part about WS is that usually the service is
defined with a WSDL-file which clearly defines syntax of all calls to
the service. You can't send arguments with the wrong argument type or
order, and can easy get stubs generated for you.
> In addition, SOAP is more involved, more complex to handle. REST is much
> easier.
Yes, SOAP and WS is more complex, but that is not in all cases a bad
thing, like in larger projects. But it has a steaper learning curve
than RESTful services.
> If you choose REST, then there's another choice you can make: Which format?
> You can choose XML (applicatin/xml) or JSON (application/json) (GSON), which
> are 2 of the most popular formats for REST.
> Personally, I would choose XML because Android already includes pull and
> push parsing of XML data from the server. Pull and push parsing allows you
> to only read the parts of the REST response in which your app is interested
> and skip the rest: somewhat better performance, much better memory usage for
> larg REST responses.
>
> In short: If you can chose everything, i would choose REST services using
> XML.
As you wrote, XML are not as bad as many tend to say. It is designed
to be easy to parse, compared to many other formats like JSON and
HTML. This is a good thing.
But as usually, the choices are not all easy to make. It depends on
many facts, which are different to each project. Like what you know
before you start and how much time you have to learn new skills.
A. Jackson
--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
No comments:
Post a Comment