Showing posts with label restservices. Show all posts
Showing posts with label restservices. Show all posts

December 08, 2017

SOAP vs REST Web Services

No.SOAPREST
1)SOAP is a protocol.REST is an architectural style.
2)SOAP stands for Simple Object Access Protocol.REST stands for REpresentational State Transfer.
3)SOAP can't use REST because it is a protocol.REST can use SOAP web services because it is a concept and can use any protocol like HTTP, SOAP.
4)SOAP uses services interfaces to expose the business logic.REST uses URI to expose business logic.
5)JAX-WS is the Java API for SOAP web services.JAX-RS is the Java API for RESTful web services.
6)SOAP defines standards to be strictly followed.REST does not define too many standards like SOAP.
7)SOAP requires more bandwidth and resource than REST.REST requires less bandwidth and resource than SOAP.
8)SOAP defines its own security.RESTful web services inherit security measures from the underlying transport.
9)SOAP permits XML data format only.REST permits different data format such as Plain text, HTML, XML, JSON etc.
10)SOAP is less preferred than REST.REST more preferred than SOAP.


Reference: https://www.javatpoint.com/soap-vs-rest-web-services
Read more ...

July 21, 2017

Evolving a REST API is a difficult problem – one for which many options are available - Solution for API Versioning

 Situation:
    Evolving a REST API is a difficult problem – one for which many options are available - Solution for API Versioning.

Action
 > Specifying the version number in URI  E.g.: /v2/products/
              The URI in REST should represent the resource only
              This is not suggested unless the entire set of APIs migrate to a new platform
> Passing the version number as a URI Parameter: E.g.: /products?version=2
            • This is used by Amazon, Google and Netflix
            • Parameters are used for filtering resources and should not specify the implementation
            • The APIs have to parse the param string before knowing where to route the request.
> Using the well-known HTTP header: The Accept header is used to make up our own resource types. E.g.: Accept: application/vnd.test.v2 + json

This means that I, as a vendor, can define (and can register) a media type. If we do this it's called a 'vendor' media type. It works and well-known.

The disadvantage with this approach is it is not very intuitive.
According to the Rest API specifications, A REST API should be entered with no prior knowledge beyond the initial URI (bookmark) and set of standardized media types that are appropriate for the intended audience. Failure here implies that out-of-band information is driving interaction instead of hypertext.

So URIs are not part of the contract!
A REST API should spend almost all of its descriptive effort in defining the media type(s) used for representing resources and driving application state, or in defining extended relation names and/or hypertext-enabled mark-up for existing standard media types.

So the Media Type definitions are part of the contract and should be prior knowledge for the client that consumes the API.


Conclusion:
This article tried to provide an overview of the very diverse and difficult problem of evolving a REST Service. We discussed the two common solutions, advantages and disadvantages of each one, and ways to reason about these approaches in the context of REST. The article concludes by making the case for the second solution – versioning the media types, while examining the possible changes to a RESTful API.Finally Considering all the above, using well-known HTTP header, Accept may be a better option.
 
 

@RequestMapping(..., produces = "application/vnd.company.app-[1.0-1.6]+json)
@ResponseBody
public Object method1() {
   // so something
   return object;
}
@RequestMapping(..., produces = "application/vnd.company.app-[1.7-]+json)
@ResponseBody
public Object method2() {
   // so something
   return object;
}
 
Result:
We can get the different version data without any changes in the code level. 

Ref:
http://www.baeldung.com/rest-versioning

Solution implementation at: https://github.com/mspapant/restVersioningExample/


Read more ...

June 17, 2016

Swagger - RESTful API Documentation Specification

Swagger : The goal of Swagger is to define a standard, language-agnostic interface to REST APIs which allows both humans and computers to discover and understand the capabilities of the service without access to source code, documentation, or through network traffic inspection.

Swagger is a formal specification surrounded by a large ecosystem of tools, which includes everything from front-end user interfaces, low-level code libraries and commercial API management solutions.

Swagger api: https://github.com/swagger-api/swagger.io/blob/wordpress//tools/index.md

Swagger integration on web application example: http://www.3pillarglobal.com/insights/restful-api-documentation-using-swagger-and-spring-mvc

Ref: http://swagger.io
Read more ...

Online test web application deployment environment (Openshift, Interserver) and Online project workspace (Codenvy)

Codenvy makes on-demand workspaces to give you a better agile experience. Codenvy SaaS is available for self-service at codenvy.com. You can also install Codenvy on your own infrastructure with Codenvy On-Prem. Ref: http://codenvy.readme.io/docs/release-notes

Online test web application deployment environment are :Openshift , Interserver

Read more ...

June 16, 2016

To run real time RESTful services on Windows OS

In Chorme plugins: REST Client, Postman, InsomniaAdvanced REST client

Postman helps you develop APIs faster compare to other apps.
To understand more postman click me 


Read more ...

My Favorite Site's List

#update below script more than 500 posts