When developing a web-service, there are always many points to be considered by the product owner and the development team. The product owner provides his team with project requirements so the team knows exactly what to do. Depending on goals and requirements you should choose application’s architecture from the very start – it surely has a great impact on how the app is going to work after it’s release. Today we will talk about one of the most popular architecture types – REST.
You can get the most basic understanding of REST conception in Ryan Tomayko’s post called “How I explained REST to my wife”. But if you want to know more about technical details, you can learn more in our article. Let’s begin.
Representational state transfer is an architectural style which is used for web services development. There are 6 rules that need to be followed while developing a product. If your service follows all those rules, then it can be called RESTful service. In addition, REST requires your project to use most of http protocol’s features.
So, what are REST rules?
Let’s have more in-depth look at them.
REST architecture implies usage of uniform interface for all client-server interactions.
While using REST, the client is interacting with server to get resources and to manipulate them. For example, tables can be considered as a resources, though it is not always possible (in cases when queries have complex logic of interaction with resources).
The interface itself has to use different URLs while working with various resources. Proper separation of queries can be used to split an application into multiple ones. It significantly increases project’s portability and scalability. In addition it makes easier for developers to understand API (even if there is no any detailed documentation).
REST also requires to use only plural nouns for resource’s names. You should not overload the system with multiple URLs. Each resource should only have 2 URLs in most of common cases. For instance:
The information being transferred between clients and servers has to be converted to appropriate transferring format. JSON or XML, for instance, though JSON is the most popular at the moment. Nevertheless there are some web-services that support simultaneous work with multiple formats. Both formats (of returned and processed data) have to be controlled by http-headers – Accept and Content-type. HTTP header provide various information about the request or response, or, per say, about the object sent in the message body. For example: application/json or application/xml.
RESTful service’s query has to identify itself with a resource or resources while controlling their full state. RESTful web-services should not store any data regarding queries or cookies.
Clients should be able to cache queries. Responses should define themselves as cacheable or not (implicitly or explicitly), to prevent any clients from re-using outdated or even inappropriate data in response to further requests. Well-managed caching can partially (or even completely) eliminate some of client–server interactions, which helps to improve overall scalability and performance.
A uniform interface has to separate clients from servers. This implies the separation of their responsibilities (the interface should work independently from both client and server). For example:
The system can have intermediary servers so the client won’t know exactly which server he is interacting with. Intermediary servers can also decrease server load acting as load balancers and providing shared caches.
Despite the fact that REST can be used in every http-based product, sometimes its implementation is impossible because of lack of experience. But if your team is skillful enough for REST implementation, your project can get lots of advantages:
Http contains 4 methods: GET, POST, PUT, DELETE. Each method should be used for specific tasks. It should identify the functionality provided with query.
We’ve made up a little table for your convenience. This table contains all of http methods and their possible responses.
It is important to use right status codes for certain server responses. Http has several dozens of various status codes, but we are going to list only most popular ones:
Http has plenty of various error codes, but still it’s not enough for any application out there. But it’s possible to insert an additional message into response body to clarify the issue (via json, xml, etc.).
Feel free to contact us via quote form if you have any questions left. Here at Smartum Pro we provide professional consultancy services and we’ll be glad to help you with implementation of your great ideas!
We will process the request and contact you.
Now fill in information about yourself: