Skip to main content

REST

REST API (Representational State Transfer API):

  • REST is an architectural style for designing networked applications.
  • It uses standard HTTP methods (GET, POST, PUT, DELETE) to perform CRUD operations on resources.
  • REST APIs are stateless, meaning each request from a client to the server must contain all the information needed to understand and fulfill the request.

API Versioning:

  • API versioning is the practice of managing changes to an API by creating different versions.
  • It allows existing clients to continue using the older version while new clients can use the latest version.
  • Common methods for versioning include adding version numbers to the URL or using custom headers.

Request Components:

  • Body: Used to send data to the server, typically in JSON or XML format. For example, when creating a new resource, you may include the resource's details in the request body.
  • Header: Contains metadata about the request, such as authentication tokens or content type.
  • Query Parameters: Provide additional data to the server for filtering, sorting, or pagination. For example, when fetching a list of resources, you might use query parameters like ?page=2 or

?filter=name.

CRUD Operations:

  • GET: Used to retrieve data from the server. For example, GET /users fetches a list of users.
  • POST: Used to create a new resource on the server. For example, POST /users creates a new user.
  • PUT: Used to update an existing resource on the server. For example, PUT /users/123 updates user 123.
  • DELETE: Used to remove a resource from the server. For example, DELETE /users/123 deletes user 123.

Response Components: Responses typically consist of status codes, headers, and message bodies.

Error Handling and HTTP Status Codes: HTTP status codes indicate the outcome of an API request. Common status codes include:

  • 200 OK: Successful GET request.
  • 201 Created: Successful resource creation (POST or PUT).
  • 204 No Content: Successful DELETE request.
  • 400 Bad Request: Invalid request format or missing parameters.
  • 401 Unauthorized: Authentication failure.
  • 403 Forbidden: Authorized, but access is not allowed.
  • 500 Internal Server Error: Server-side error.

Headers:

Common response headers include:

  • Content-Type: Specifies the format of the response data (e.g., JSON, XML).
  • Location: Used to indicate the URL of a newly created resource.
  • Cache-Control: Controls caching behavior in the client's browser.
  • Allow: Lists the HTTP methods supported by the resource.
  • ETag: Provides a unique identifier for the current state of the resource.

Message Body:

  • The response message body contains the actual data returned by the server.
  • It may contain data in JSON, XML, HTML, or other formats, depending on the API's design.
  • For successful responses, the message body typically includes requested data or confirmation messages.
  • In error responses, the body may contain error details or error messages for the client to interpret.

Caching in APIs with ETag and "If-None-Match":

  1. Resource Identification: Each resource on the server is assigned a unique identifier called an ETag. The ETag represents the current version of the resource.
  2. Client Request: When a client requests a resource, the server includes the ETag of that resource in the response headers.
  3. Caching by Client: The client stores the received ETag as part of its cache.
  4. Subsequent Requests: In subsequent requests, the client includes the "If-None-Match" header with the previously stored ETag value.
  5. Server Validation: Upon receiving a request with "If-None-Match," the server checks if the provided ETag matches the current ETag of the resource.
  6. Matching ETags: If the ETags match, the server responds with a "304 Not Modified" status code, indicating the client's cached resource is still valid.
  7. Non-Matching ETags: If the ETags do not match, it means the resource has been updated. The server processes the request and returns the updated resource along with its new ETag.

Benefits:

  • Efficient Caching: ETags and "If-None-Match" reduce data transfer by allowing clients to validate cached resources.
  • Bandwidth Savings: Unchanged resources are not re-downloaded, saving bandwidth.
  • Improved Performance: Clients receive updated resources only when necessary.