Web services (Road to J2EE)

I'm starting this series of posts about J2EE to get an idea of concepts about restful web service implementations using J2EE.

Before we go into Restful web services lets see what is a web service first...

Web service

Did you ever think of when you are playing a game and it's asking you to post your score in your facebook wall? you don't need to go to the facebook to do so, the game itself gives the ability to post your score. That's how web services come in.

Websites like Facebook twitter publish their API's on the web that another application can use.

Think about what happens when you visit a website. how it differs with web services.

When you want to visit, let's say Facebook, the client makes Http request to the server and the server will respond to the client by sending an Http request. that response is basically an HTML response. But when client call to a web service the response will be an XML/ JSON/ text whatever type of response. Rest web services have no restriction at all about what a response contains whether its an XML  JSON or whatever it is it is ok if client and server can understand,

Types of web services

Now you know what a web service is and let's see what are the types of web services. There are two types of web services.

• SOAP ( Simple Object Access Protocol)
• REST ( Representational State Transfer)

SOAP is highly restricted with its protocols(SOAP protocol) and service definitions( manage using WSDL file). REST has no service definitions and no protocol specified. No response type restricted also.

Ok then. You might get an idea about what a REST web service and how it differs from SOAP. Both two are web services but one has rules to follow and one doesn't. and one has limitations and restrictions and one doesn't. So what do prefer most? From my end it's REST.

Let's see some important concepts of HTTP you should know when implementing Rest full web services.

Some Concepts you should know 

• You might familiar with these concepts if you were ever doing even a very small web application. there are HTTP error codes that will ease the client what happened.  When developing a Restful web service you should return the proper HTTP code so that the client could understand what is happening actually. 
• Content types -  As I already described restful web services have no restrictions. but both client and server should understand each other,  So the header type should specify the content type. whether it is XML or JSON or whatever it is. 
• instead of action based URLs should use Resouce based URIs
• Should use HTML methods better, (PUT, GET, POST, DELETE) not like in SOAP that only uses POST

PUT or POST confusion

thought of writing the difference between PUT and POST methods because many are unaware of what's happening when you make a PUT or POST request, Yes guys there are differences between those two. 

You can make the same PUT request again and again , there will be no effect on the server after the first call made, but if you make a POST it will create a new change in the server (Lets say you are saving something on a server) and when you call the same again it will create a duplicate record. So it a non-repeatable call. That is why for the update, PUT is recommended and for create, POST is recommended. 

RESPONSE

Resource URI is used for representing a resource as the Name suggests REST(Representation of state transfer). HTTP headers are used to identify what type of response we get. and HTTP error codes are used to identify what happened

100 -199 informational (like ACK, not much used)

200 - 299  success (200 OK)

300 - 399 Redirected

400 - 499 Client ERROR codes (404 not found )

500- 599 Server ERROR codes (500 - Internal Server Error)

HATEOAS concept

Before going to the Acronym meaning lets think about a developer who is going to use a provided API.
Let's say a person makes a get request to get a specific object. As I mentioned earlier REST API has no service specifications like SOAP so that clients would know what are the available methods and so on, then there should be a way to describe what are the available methods we can call for a specific resource. there comes the HATEOAS concept.

Hypermedia As The Engine Of Application State (This is simply a way to provide links to the client inside the HTTP response)

--------- more description needed ( using href and rel attributes in the response )------


Full Restful ?? Not Restful ?? SOAP ??

have you ever heard someone say, this API is not restful at all or this is a fully restful API or this is SOAP web service... what are those ?? how can someone decide a RESTFULNESS of an API.
Here comes a RICHARDSON MATURITY MODEL. I'm not going to go for more details here since we didn't start our cording yet.
But let's have a look at SOAP web services.

How SOAP works

I've already given some information about SOAP web services and how they differ from. Do you remember that I said SOAP only uses the POST method, 🤔🤔🤔🤔 ?

The concept of SOAP is not like having several URI for the same resource to do several operations it only has one URI and you describe what action you want to take inside the response.

ex:-    <CreateMember>  <name> Ravinda <name> <CreateMember>

As the request, itself describes what action needs to take and what content needs to add.