RESTful Web Services
Guys, I am going to keep this tutorial as short and precise and possible. So let us start this way…
REST stands for Representational State Transfer.
REST web services are based on the HTTP protocol. They are characterized by being light weight, maintainable and scalable.
A web service build based on the REST architecture is termed a RESTful web service.
The REST web services provide for a way to access resources lying somewhere in some environment; like a server for example.
So say you have some document/database with information that you want to access. The information is termed as resources. What RESt does is define a way of accessing the resouce(s).
For you to implement a REST web service, you need to understand the following simple terminologies:
- Resource- This is the key element. It is what needs to be accessed. The resource(s) could be a set of records lying in some database/files in some server somewhere. So the need to access the resources trigger a thinking for someone to develop a web-service.
- URL- For the resource to be accessed, it must be identified first. This identification is provided for by the URIs (Universal Resource Identifiers) or URL (Uniform Resource Locator). For example: http://www.persons.com/1 could be a url to return the list of person where the id for example is 1.
- Request Verbs- The verbs define what should be done to the resource. The verb could be GET, POST, DELETE, PUT whose functions are as follows:
GET- instructing the just get the resource. E.g a list of persons.
POST- to update the resource(s).
DELETE- to delete the resource.
PUT- to create a new resource.
4. Request head- Additional instructions that accompanies the request. it could be defining the type of response expected by the client.
5. Request Body- The data that accompanies the request. The data in this case is meant to be added to the server. usually happens in the POST request verb. In this case, the client is telling the server that “hey, I can’t to add this resource.”
6. Response body- What the client requested. It contains all the requested resource.
7. The status codes that returned alongside the request. The code usually tell us the state of the request. Whether it was successful, available, not found etc.
So someone want to ask me a question. “Davies, why REST”?
My answer is simple: it supports communication between different languages and the environment on which the resource is located is not a barrier. So whether you are doing java and the other party is doing php, it doesn’t really matter. Whether you are running on linux and the other party is running on windows it doesn’t matter. The result of the execution is same.
Principles of REST Web-services
Client-Server
RESTful web services are client-serve based. Meaning the resource is somewhere in the server and is available upon the client request.
Stateless- The communication between the client and the server is in the form of a QA. The client asks the question (request) the server answers (responds) and the server does not keep memory of the previous question. Simply, the server does not keep the state of the request it has served or responded to. Once done it is done. So it is up to the client to be sure of what they are requesting and any time they need they must request.
Cache- temporary storage of the client request. This comes in handy to help with the issue of stateless. Remember we said earlier that the server does not remember what the client asked previously. The concept of cache is implemented in the client side so that, once the server has responded the client can keep the response temporarily. As a result, if the client makes the same request again instead of the request going to the server, the response is just fetched from the cache and served. As a result the traffic to the server is reduced and communication is made efficient.
Layered System- It allows for layering. This means that a middleware can be created between the client and the server to serve whatever logic that is required then make a request to the serve. However the middleware should be public. Public in the sense that it does not hinder communication between the client and the server.
Hey friends, it is that simple. In my next article we should be “fingers on the keyboard” implementing the one web service.
