REST – REpresentational State Transfer

Introduction:

  • Identification of resources – The interface must uniquely identify each resource involved in the interaction between the client and the server.
  • The client-server design pattern enforces the separation of concerns, which helps the client and the server components evolve independently.
  • Stateless mandates that each request from the client to the server must contain all of the information necessary to understand and complete the request.

Split Application to two part of applications:

  • Backend (Server) – Java, PHP, Python, JavaScript….
  • Frontend (Client) – JavaScript with framework or library (Angular, VueJS, React, jQuery…), Mobile application, Desktop application…

Communication:

REST != HTTP

  • Applications communicate over HTTP

All requests contains:

  • Path to the resource
  • HTTP method
  • Request Body
  • Request Headers

All responses contains:

    • Response headers
    • Response Body
    • Status Code

HTTP methods:

  • HEAD
  • GET
  • POST
  • PUT
  • DELETE
  • PATCH

Actions on the server:

  • HEAD is using for getting all methods which available on the path
  • GET is using for getting resource or collection of resources
  • POST is using for creating resource
  • PUT is using for updating resource
  • DELETE is using for deleting resource
  • PATCH is using for updating resource but it is only modifying fields which sent from request

REST api path – Practic:

  • Good practice is adding prefix API (Application Program Interface)
  • When we combine methods and path then we have action on resource on the server
  • Resource with name ITEM, the REST specification says that when working with the resource then we use the plural as the initial part of the path.

Example:

Paths for ITEM:

  • …/api/items
  • …/api/items/{ID}
  • …/api/items/{ID}/{NAME_OF_SUBRESOURCE}
  • …/api/items/{ID}/{NAME_OF_SUBRESOURCE}/{ID_OF_SUBRESOURCE}

REST api Path + Methods:

  • …/api/items
    • GET is using for getting collection of resources
    • POST is using for creating resource
  • …/api/items/{ID}
    • ID is identifier of resource
    • GET is using for getting resource
    • PUT/PATCH is using for updating resource
    • DELETE is using for deleting resource

Status codes:

 

 

REST success status codes:

GET– 200 (OK)

POST – 201 (CREATED)

PUT – 200 (OK)

PATCH – 200 (OK

DELETE – 204 (NO CONTENT)

REST error status codes:

GET – 404 (NOT FOUND), 400 (BAD REQUEST)

POST – 400 (BAD REQUEST), 409 (CONFLICT)

PUT – 404 (NOT FOUND), 400 (BAD REQUEST), 409 (CONFLICT)

PATCH – 404 (NOT FOUND), 400 (BAD REQUEST), 409 (CONFLICT)

DELETE – 404 (NOT FOUND), 400 (BAD REQUEST), 409 (CONFLICT)

Of course 5xx is also an error response, but it says that the problem is on server side, but it is not on client side.

Path param VS Query param:

Path param is an integral part of path: …/api/items/{ID}

  • It is integral path of path
  • It is mandatory
  • Example: Identifier of resource

Query param is an additional part of path: …/api/items?page=2&size=10

  • It is an additional part of path
  • It is not mandatory
  • Example: Filters, paginations…