Now a day, most of the industries use RESTful APIs to develop their web and mobile applications.
REST stands for Representational State Transfer. REST is an architectural style of developing web services. Web services developed using REST style are known as RESTful web services. These web services use HTTP methods to implement the concept of REST architecture. A RESTful web service usually defines a URI, Uniform Resource Identifier a service, provides resource representation such as JSON and set of HTTP Methods.
It’s been a trend now to develop REST APIs using JSON and consume using front end technologies like ReactJs/AngularJs. Also, It can be consumed in mobile apps like / React native and there are several advantages of it.
There are two types of web services. SOAP and RESTful. SOAP support only XML while REST support XML/TEXT or JSON. And JSON is the most popular representations of resources these days.
Difference between REST and SOAP WEB SERVICES.
REST is lightweight and much faster than SOAP. Rest use JSON and used HTTP protocols to communicate client and server.
SOAP has WSDL (Web Services Description Language) while REST has WADL (Web Application Description Language). SOAP used soap protocol to communicate.
Benefits of JSON over XML
.JSON parsing is generally faster than XML parsing.
· Formatted JSON is generally easier to read than formatted XML.
· JSON can contain Integer, String, List, Arrays. XML is just nodes and elements that need to be parsed into Integer, String and so on before it is used by your application
What Is A “Resource” In REST?
REST is a resource-based URI. Not action-based. This is a very simple and easy way to handle and create APIs. REST architecture treats every content as a resource. These resources can be either text files, HTML pages, images, videos or dynamic business data
This is not a resource-based. This is an action-based URL.
Ex:- weatherapp.com/Zipcode/12345 or weatherapp.com/Countries/Srilanka
This is resource-based URI. So As this is resource-based then it means this one is Independent with server-side implementations.
HTTP status codes
These codes are the general codes which are returned along with the response from the webserver. An example is the code 200 which is normally returned if there is no error when returning a response to the client.
200:- this indicates the success of the request or response.
201: -successfully creation [POST]
204:- This indicates that there is no content in the response body. [DELETE]
400:- Client-side errors. (Bad Request) [customer id doesn't exist in database like that]
401:- Authentication failed.
404 -: Resource was not found. (no this kind of method which in API)
405 -: method not allowed. Used GET instead of POST. Like that.
415:- unsupported media type.
500:- Server-side error. Request is all set and ok. But when server-side error occur then server send this kind of status.
Most Commonly Used HTTP Methods
HTTP methods which interact with URI’s
GET: this is read only method support by REST. This one repeatable. So this one called as idempotent. Safely repeatable. 200, 404, 500
POST:- This is something to write the server. This one cannot repeatable. So this is non-idempotent. Do validation here. 200, 201, 400, 415, 500, 404
PUT:- This is something write to server. When this repeat there is no effect on server-side. So this one called safely repeatable. 200, 404, 500, 400, 415
DELETE: this is something write to server. When this repeat there is no effect on server-side. So this one called safely repeatable. 200, 204, 404, 500
Good practices about Resource URI
Don’t use singular format in resource
· Ex:- facebook.com/message/2 this is wrong
· Ex: facebook.com/messages/2 this is correct
Don’t use verbs in resource. Always use nouns.
Ex: facebook.com/getmessages/2 this is wrong. facebook.com/messages/2 this is correct.
Resource URI Realtions
Filtering URI (pagination)
Ex:- /messages?offset=30 & limit=10
Limit end point.