In the last post, we learnt about the intricacies of SOAP Webservices. In this post, we will learn and explore REST Webservices in detail.
REST stands for Representational State Transfer. It is a lightweight alternative to SOAP,RPC etc for data transfer. It uses HTTP as communication medium and mostly JSON as message format. It is preferred to be consumed in mobile applications as it is lightweight in comparison to SOAP, however, it has no inbuilt security mechanisms. SOAP can be thought of as letter in an envelope whereas REST is postcard in this analogy. Before knowing more about REST, we need to understand HTTP messages.
HTTP Messages are made of a header and a body. The body can often remain empty; it contains data that you want to transmit over the network, in order to use it according to the instructions in the header. The header contains metadata, such as encoding information; but, in the case of a request, it also contains the important HTTP methods.
REST is basically a set of design principles consisting of resources and methods to access/manipulate those resources. Resources are best thought of as nouns. For example, the following is not RESTful because it uses a URL to describe an action.
HTTP Verbs are specified along with the request. Methods are then mapped to HTTP verbs/methods. Mostly, 4 HTTP verbs/methods are used (GET/PUT/POST/DELETE)
a) GET – It is used to request the resource
b) PUT – It is used to update the resource
c) DELETE – It is used to delete the resource
d) POST – It is used to create the resource.
Here, it is very important to know about Idempotent methods. These methods achieve the same result, no matter how many times the request is repeated. In the above 4 methods, GET, PUT and DELETE are idempotent methods whereas POST is non-idempotent method.
HTTP Responses contains response codes in its header that is basically a way of informing client about the results of its request. Following are some of the response codes:
a) 200 OK – It indicates that the request was successful.
b) 201 Created – It indicates the request was successful and a resource was created.
c) 400 Bad Request – The request was malformed.
d) 404 Not Found – Required resource could not be found.
e) 401 Unauthorized – Authentication needed / not successful.
f) 405 Method Not Allowed – HTTP method not supported for this resource.
g) 409 Conflict – This indicates a conflict. For instance, POST request is used to create the same resource twice.
h) 500 Internal Server Error – When all else fails; generally, a 500 response is used when processing fails due to unanticipated circumstances on the server side, which causes the server to error out.
In the next article, I will introduce you to new version of UFT (which has API Testing Capability)