REST Architecture Best Practice

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.
  • Consider connectedness. Provide hypermedia linkes in the response. !!!

Leave a comment