Thursday 14 January 2016

Web Services in Android

What is Web Service?

A web service is a standard used for exchanging information between applications or systems of heterogeneous type. Software applications written in various programming languages and running on various platforms can use web services to exchange information over Internet using http protocol.
This inter-operability can be achieved between Java and Dot net applications, or PHP and Java applications.

Why Web Service?

Here are the reasons for using Web Service:

Expose method as a service over network:
Web service is a chunk of code written in some programming language (Say C# or Java) that can be invoked remotely through http protocol. Once the Web methods are exposed publically, any applications can invoke it and use the functionality of the web methods.

Application Inter-operability – Connect heterogeneous applications:
With the help of web service, heterogeneous applications (Java and Dot Net / Java and PHP application) can communicate with each other. Web service written in Java can be invoked from PHP by passing the required parameters to web methods. This makes the applications platform and technology independent.

Standardized protocol:
Web Services uses standardized industry standard protocol for the communication which must be adhered and followed by the applications creating Web Service.  
                                                     
Cost effective communication:
Web service is using SOAP over HTTP protocol for communication which is much cheaper than systems.

What is the need of using Web Service in Android applications?

Existing Web applications are in a need of creating mobile applications to show their presence in mobile platform as well. Almost all web applications are having their Mobile applications created in Android, IOS or Windows platform.

Exposing the existing functionalities of the applications is bit tough as all the functionalities have to re-written in the respective platforms.

But it can be easily achieved with much ease by creating Web Service and expose the existing functionalities as web methods to Mobile platforms.

Here are the few advantages of using Web Service in Android:

Make client more lightweight:
Adding a web service layer makes the client more lightweight, both in terms of the required CPU power and the bandwidth used during the processing. Most of the processing to be done in client end can be separated and put inside a web service layer which will be extremely helpful for end-users in terms of:
Using less CPU increases the battery life
Using less bandwidth reduces monthly payments over data charge.

Re-usage of existing functionalities:
While designing the web service, we could also get significant benefits by reusing the existing functionalities by exposing them as web methods.

Remote DB hit made simple:
DB residing remotely can be hit from inside Android applications through Web Service calls.
Making Web Service call from Android applications allows us to add functionality outside the scope of a DB like caching data, applying business rules over the data etc.,

Types of web services.

1) xml
2) json
3) soap
3) rest

Which one is better XML or JSON ?

XML and JSON both are the data interchange formats accessed over WEB. Both of these formats have their own pros/cons. No one is replacement of other. Use the right tool for the right job.

XML: Extensible Markup Language

1. An open standard for describing data defined by the World Wide Web Consortium (W3C).

2. XML lets Web developers and designers create customized tags that offer greater flexibility in organizing and presenting information.

3. XML defines rules to mark-up a document in a way that allows the author to express semantic meaning in the mark-up. XML does not necessarily restrict the author to certain tags (elements) as HTML does.

4. Internet media type: application/xml

JSON: JavaScript Object Notation

1. A lightweight text-based open standard designed for human-readable data interchange.

2. A text-based format for exchanging objects.

3. It is an alternative to XML that is more concise because, unlike XML,  it is not a markup language that requires open and close tags.

4. It is derived from the object literals of JavaScript.

5. Design goals were for it to be minimal, portable, textual, and a subset of JavaScript.

6. Internet media type: application/json


JSON is built on two structures:

1. A collection of name/value pairs. In various languages, this is realized as an object, record, struct, dictionary, hash table, keyed list, or associative array.

2. An ordered list of values. In most languages, this is realized as an array, vector, list, or sequence.

Below are the differences between XML and JSON.

XML vs JSON

1.  JSON format is lightweight over XML.

2. JSON is recognized natively by JavaScript.

3. JSON can contain integers, strings, lists, arrays. XML is just elements and nodes that need to be parsed into integers and so on before it can be consumed.

4. The most important disadvantage of JSON is that the format is very hard to read for humans, and that, of course,    every single comma, quote, and bracket should be in exactly the correct place. While this is also true of XML, JSON’s welter of complicated-looking syntax, like the }}]} at the end of the data snippet, may frighten the newbies and make for complicated debugging.

5. Serialization format for your data, JSON is smaller, lighterweight and generally faster than XML.

6. JSON is best for consumption of data in web applications from webservices for its size and ease of use, especially due to the built-in support in JavaScript.
Imagine the computation overhead for parsing an xml fragment compared to the instant lookup in JSON.

7. XML is still great. JSON’s just the “latest and greatest” compared to XML.

8. For configurations file XML is better choice to make because it more human readable.

9. A browser JSON is faster to serialize/deserialize as it’s simpler, more compact and more importantly natively supported.

10. XML is document-oriented. JSON is data-oriented. JSON can be mapped more easily to object-oriented systems.

11. XML and JSON both use Unicode.That help in support for internationalization.

12. JSON does not have afeature, so it is not well suited to act as a carrier of sounds or images or other large binary payloads. JSON is optimized for data.

13. XML documents can contain any imaginable data type – from classical data like text and numbers, or multimedia objects such as sounds, to active formats like Java applets or ActiveX components.

14. JSON is a better data exchange format. XML is a better document exchange format. Use the right tool for the right job.

15. XML requires translating the structure of the data into a document structure. This mapping can be complicated. JSON structures are based on arrays and records. That is what data is made of. XML structures are based on elements (which can be nested), attributes (which cannot), raw content text, entities, DTDs, and other meta structures.

16. JSON is not extensible because it does not need to be. JSON is not a document markup language, so it is not necessary to define new tags or attributes to represent data in it.

Summary:

1. For Data delivery between servers and browsers, JSON is better choice.
2. For storing Information in configuration files on the server side, XML is better choice.
3. On Browser Side: The speed and ease with which JSON is parsed and the ease of simple data          retrieval from JavaScript object; makes JSON is a better choice.
4. Server Side: The querying data and format changes; makes XML a better choice.

Querying data: Using XPath, it’s possible to get direct access to a part of multiple parts of an XML data structure; no such interface exists for JSON. To get data from a JSON structure, you must know exactly where it is or else iterate over everything until you find it.

Format changes: You have your data in one format but you want it in another. If the data is in XML, you can write an XSLT template and run it over the XML to output the data into another format: HTML, SVG, plain text, comma-delimited, even JSON. When you have data in JSON, it’s pretty much stuck there. There’s no easy way to change it into another data format.

5. Security: JSON is less secure because of absence of JSON parser in the Browser; only way is to use eval() function. For security reasons on the browser side XML is better choice.

6. To extract data from database; XML is the only choice.

Below is the example:
I used to explain each one’s usage in the Browser. This usage will also show you which one is easy to use on the browser side.

Example Data Operations:

XML

<?xml version="1.0" encoding="UTF-8"?>
<root>
    <data>
        <id>1</id>                   
        <name>PHP </name>
    </data>
    <data>
        <id>2</id>                   
        <name>Table of Contents</name>
    </data>
<root>

JSON

 {
                "data": [
                           {
                                "id" :    "1",
                                "name" :    "PHP"                           
                            },
                            {
                                "id" :    "2",
                                "name" :    "Table of Contents"
                            }
]}



What is REST ?

REST describes a set of architectural principles by which data can be transmitted over a standardized interface (such as HTTP). The acronym REST stands for Representational State Transfer, this basically means that each unique URL is a representation of some object.
REST asks developers to use HTTP methods explicitly and in a way that’s consistent with the protocol definition. This basic REST design principle establishes a one-to-one mapping between create, read, update, and delete (CRUD) operations and HTTP methods. According to this mapping:
To create a resource on the server, use POST.
To retrieve a resource, use GET.
To change the state of a resource or to update it, use PUT.
To remove or delete a resource, use DELETE.

Advantages of using RESTful webservice:

RESTful Web services are designed with less dependence on proprietary middleware (for example, an application server) than the SOAP- and WSDL-based kind.

As per the RESTful interface design, XML or JSON over HTTP is a powerful interface that allows internal applications, such as Asynchronous JavaScript + XML/JSON (Ajax)-based custom user interfaces, to easily connect, address, and consume resources.

The great fit between Ajax and REST has increased the amount of attention REST is getting these days.

Exposing a system’s resources through a RESTful API is a flexible way to provide different kinds of applications with data formatted in a standard way. It helps to meet integration requirements that are critical to building systems where data can be easily combined (mashups) and to extend or build on a set of base, RESTful services into something much bigger.

What is SOAP?
SOAP (Simple Object Access Protocol) is a messaging protocol that allows programs that run on disparate operating systems (such as Windows and Linux) to communicate using Hypertext Transfer Protocol (HTTP) and its Extensible Markup Language (XML).

SOAP defines the XML-based message format that Web service-enabled applications use to communicate and inter-operate with each other over the Web. The heterogeneous environment of the Web demands that applications support a common data encoding protocol and message format. SOAP is a standard for encoding messages in XML that invoke functions in other applications.

SOAP:
Pros:
Langauge, platform, and transport agnostic
Designed to handle distributed computing environments
Is the prevailing standard for web services, and hence has better support from other standards (WSDL, WS-*) and tooling from vendors
Built-in error handling (faults)
Extensibility

Cons:
Conceptually more difficult, more "heavy-weight" than REST
More verbose
Harder to develop, requires tools

REST
Pros:
Language and platform agnostic
Much simpler to develop than SOAP
Small learning curve, less reliance on tools
Concise, no need for additional messaging layer
Closer in design and philosophy to the Web.

Cons:
Assumes a point-to-point communication model--not usable for distributed computing environment where message may go through one or more intermediaries
Lack of standards support for security, policy, reliable messaging, etc., so services that have more sophisticated requirements are harder to develop ("roll your own")
Tied to the HTTP transport model.

SOAP vs REST 

No comments:

Post a Comment