Category Cloud

Archives

Month: January 2017

Why Use REST Architecture:

For a new project I will be working on, REST architecture is to be used to mainly decouple the front-end and the back-end. By doing this, front-end may be expended from a web application to a mobile application in the future.

The Six REST Architecture Constraints:

Uniform interface

Decouples the front-end and the back-end.

Resources are displayed as a representation (HTML, XML or JSON), and resources are manipulatable by the clients.

HATEOAS !!!

Stateless

Server does not maintain a session.

The client must include all information for the server to fulfill a request. (resending state as necessary if that state must span multiple requests)

Cacheable

Responses must be implicitly or explicitly define themselves as cacheable. This eliminates some client-server interactions, further improving scalability and performance.

Client-Server

Client is not concerned with data storage.

Server is not concerned with the user interface or user state.

As long as the interface is not altered, servers and clients may also be replaced and developed independently.

Layered System

A client cannot tell whether it is connected directly to the end-system or not.

Intermediary servers may improve system scalability.

Code on Demand (optional)

Servers may transfer logic such as Java applet or Javascript codes to the client to temporarily extend or customize the functionality.

If any of the non-optional constraints are broken, the service cannot strictly be referred to as RESTful.

REST Tips:

Use HTTP verbs (GET, POST, PUT and DELETE) to mean something.

Resource names should be nouns.

Create fine-grained resources. Start providing CRUD functionality for small resources, and move on to aggregated functions.