Scribd
Upload
11 views

REST APIs

REST APIs use standard HTTP methods to perform CRUD operations on resources. They are stateless and use URL versions, request bodies, headers and query parameters. Common operations include GET, POST, PUT and DELETE. Responses use status codes like 200, 401 and 500 with headers like Content-Type and caching uses ETags.

Uploaded by

keshrishiwam
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
11 views

REST APIs

REST APIs use standard HTTP methods to perform CRUD operations on resources. They are stateless and use URL versions, request bodies, headers and query parameters. Common operations include GET, POST, PUT and DELETE. Responses use status codes like 200, 401 and 500 with headers like Content-Type and caching uses ETags.

Uploaded by

keshrishiwam
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 2

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.

You might also like