Web service is an integration technology. It best demonstrates its value when integrating heterogeneous systems because it supports many kinds of programming languages, run times, and networks. When there is a need to connect applications from incompatible environments, the stage is set for Web services.
Most of the APIs available to developers today have been coded for robust web server integration with little thought of incorporation into lightweight mobile applications. This talk will look at the pitfalls of using these APIs directly and methods of incorporating APIs, such as Amazon, eBay, Google and other API sets into mobile and lightweight applications, while maintaining a quality user experience.
Benefit of using web services with your mobile apps.
- Centrelized data storage used for all the users
- Large dataset available for analysis and manipulation.
- Mobile application is just used for displaying the data other complex work can be done on web server.
- Sometimes many changes do not required to deploy the mobile application again.
- Total control of users of your application.
- One web service can be used with many mobile applications across all the platform because web services are platform independent.
Let’s Understands the Web Services
There are 3 types of web services generally used with Mobile Applications. We have gain expertise on all the types of web services which includes HTTP API, SOAP Based web services and restful web services.
- SOAP refers to Simple Object Access Protocol
- HTTP based APIs refer to APIs that are exposed as one or more HTTP URIs and typical responses are in XML / JSON. Response schemas are custom per object
- REST on the other hand adds an element of using standrdized URIs, and also giving importance to the HTTP verb used (ie GET / POST / PUT etc)
- easy to consume (XML)
- development tools
- built-in error handling (faults)
- built-in type checking
- more difficult
- harder to develop
- human readable results
- easy to build
- closer in philosophy and design to the web
- tied to HTTP
- lack of standards support for security, policy, reliable messaging, etc.
- assumes a point-to-point communication model
In the end I believe SOAP requires greater implementation effort and understanding on the client side while HTTP based or REST based APIs require greater implementation effort on the server side. API adoption can increase considerably if a HTTP based interface is provided. Infact an HTTP-based API with XML/JSON responses represents the best of both breeds and is easy to implement on the server as well as easy to consume from a client.