SOAP vs REST
1.
SOAP is good for applications that require formal contracts between the API Server and Client since it can enforce the use of formal contracts by using WSDL (Web Services Description Language).
REST is always better than SOAP in situations where lower bandwidth[ie. connectivity is expensive] between API Server and Client is required. An API consumed mostly by mobile applications is one of the use-cases where you should avoid SOAP at all costs. Simply calls services via URL end points.
2.
Performance is not great as SOAP is heavyweight as its uses XML and have extra overhead due to their headers.
Performance is much better than SOAP as REST is lightweight as it uses JSON and no extra overhead as no header provided. just key-value pair data. But it can use other data type also like XML,text etc.
3.
SOAP defines its own security BUT REST doesn't have its own security.
4.
Learning curve is high in case of SOAP.
XML - XML stands for eXtensible Markup Language. It is a markup language much like HTML which was designed to store and transport data.
It is often used for distributing data over the Internet. It's what we had before JSON became the big thing.JSON - It's a human readable object serialisation format, less verbose than XML. Very popular nowadays.
JAXB - "Java Architecture for XML Binding" is the primary mechanism for turning XML data into objects which you can then interact with, and vice versa. It's important to realize that it's an specification and not an implementation, so it mostly defines a set of annotations and simple classes / interfaces in the javax.xml.bind package.
Jackson - a library for data binding. It supports both XML and JSON as document formats, and implements the JAXB API.
Java DOM and SAX Parser are lower-level APIs to parse XML documents, while JAXB is a higher-level API for converting XML Documents (elements and attributes) to a Java object (and vice versa). Implementations of JAXB will most likely use a DOM or SAX parser behind the scenes to do the actual parsing of the XML input data.
JAXB is used to Marshalling(Java objects to XML representations) and Unmarshalling (XML contents to Java object).
Web Services - let applications exchange information over web
Web Services work on client-server model where they communicate over the network. Web services accept incoming requests from client and send response to client in either plain text, JSON or XML format. Server side component provides the endpoint URL where service is located and client application can invoke different methods.
The beautiful thing about web services is they are language independent. So a web service written in Python can be requested from a client written in Java, C#, Ruby etc.
Web services are classified into two categories:-
SOAP – In SOAP-based web services both client and service transfer SOAP messages to communicate.
REST – While in REST-style services both client and service transfer raw XML OR JSON to communicate.
Java provides APIs for creating both SOAP and REST-style web services and these are:-
JAX-WS (Java API for XML Web Services)
is a set of APIs for creating web services in XML format particularly SOAP and can also develop RESTful Web services. Plus, creating corresponding clients that communicate using XML OR use remote procedure calls(JAVA-RPC) to exchange data between client and service provider. It’s part of standard Java API, so we don’t need to include anything else which working with it.
Developers use this API to define methods, then code one or more classes to implement those methods and leave the communication details to the underlying JAX-WS API. Clients create a local proxy to represent a service, then invoke methods on the proxy. The JAX-WS runtime system converts API calls and matching replies to and from SOAP messages.
JAX-WS provides many annotation to simplify the development and deployment for both web service consumers (clients) and web service providers (endpoints).
client <----------------------------------SOAP Message------------------------------------------->server
<--------------------------------------------SOAP Protocol------------------------------------------------------>
<------------------------------------------- HTTP Protocol ------------------------------------------------------>
(proxy.methods)
JAX-WS + Spring integration
JAX-WS + Spring + cxf integration
JAX-RS (Java API for RESTful Web Services)
is a set of APIs and specification that provides support in creating web services according to the Representational State Transfer (REST) architectural pattern.
JAX-RS is a standard defined in Java Specification Request 311 (JSR-311) and Jersey / RESTEasy are implementations of it.
Being implementations mean that the spec says "if you put @GET("/foo") on a method (bar()), you may access data X" - now in an app server, someone needs to go in and actually read your deployed code, parse the byte code with the @GET annotation and then if the user actually browses to e.g. http://localhost/foo get this web request to reach bar() and translate the return value of bar() into a http answer (e.g in XML or JSON representation).
So the spec with the name "JAX-RS" only provides the syntax and semantics of e.g. @GET, but the work of parsing requests, calling the right methods, marshalling the result values etc. need to be done by a package that implements the spec.
Some guidelines for a good way to structure REST API URLs
- Most rest APIs tend to only have resource names and resource IDs in the path. Such as:
/depatments/{dept}/employees/{id}
- Some REST APIs use query strings for filtering, pagination and sorting.
Recommended:- putting any required parameters in the path, and any optional parameters should certainly be query string parameters.
If there is a scenario to retrieve a record based on id, for example you need to get the details of the employee whose id is 15, then you can have resource with @PathParam.
GET /employee/{id}
If there is a scenario where you need to get the details of all employees but only 10 at a time, you may use query param
GET /employee?start=1&size=10
This says that starting employee id 1 get ten records.
Parameters
http://localhost:8080/user
@RequestMapping{
value="/user"
method
consumes
produces
}
http://localhost:8080/user?marketplace=1&merchant=2 => queryparameters
@RequestParam(name="marketplace") int marketplace, @RequestParam(name="merchant") int merchant
@RequestBody Object object
http://localhost:8080/user/{marketplace}
@PathVariable("marketplace")
@PathVariable is to obtain some placeholder from the uri (Spring call it an URI Template)
@PathParam/PathVariable :- for retrieval based on resource id
@QueryParam/RequestParam :- for filter or if you have any fixed list of options that user can pass
Web services are part of the SOA Services Oriented Architecture. So, when to use SOAP or REST web services to expose your API to third party clients?
Both approaches work, both have advantages and disadvantages to interfacing to web services, but it is up to the web developer to make the decision of which approach may be best for each particular case.
1. By now, most developers have at least been exposed to the REST approach, which uses a standard URI (Uniform Resource Identifier) that makes a call to a web service like http/https://www.mycompany.com/program/method?Parameters=xx. The approach is very simple to understand and can be executed on really any client or server that has HTTP/HTTPS support.
Using SOAP 1.2 has some additional overhead that is not found in the REST approach, but that overhead also has advantages.
So developers use REST approach for ease of development with little learning overhead as key advantages to the style.
2. Now, if your application needs a guaranteed level of reliability and security then SOAP 1.2 offers additional standards to ensure this type of operation. Comparatively, the REST approach would make the developers build this custom plumbing.
3. RESTFul Web Services serves JSON that is faster to parse than XML.
4. While REST today uses HTTP/HTTPS, SOAP can use almost any transport to send the request between clients and servers.
REST is very easy to understand and is extremely approachable, but does lack standards and is considered an architectural approach. In comparison, SOAP is an industry standard with a well-defined protocol and a set of well-established rules to be implemented, and it has been used in systems both big and small.
No comments:
Post a Comment