RequestThe API MUST use proper HTTP methods, and operation idempotency* MUST be respected. Below is a list of methods that APIs SHOULD support. Not all resources will support all methods, but all resources using the methods below MUST conform to their usage. Method | Description | Is Idempotent* | Is Safe** | Example | |
---|
GET | Retrieve a collection of objects | True | True | GET /dogs | - 200 (OK), with list
- 404 (NOT FOUND)
- when resource doesn't exist
| GET | Retrieve a specific object | True | True | GET /dogs/10 | - 200 (OK), with data
- 404 (NOT FOUND)
| POST | Create a new object | False | False | POST /dogs | - 201 (CREATED)
- upon successful creation
- with Location header with link to newly created resource
- optionally, with HATEOAS link
| PUT | Replace a specific object | True | False | PUT /dogs/10 | - 200 (OK), with data
- 204 (NO CONTENT)
- 404 (NOT FOUND)
| PATCH | Partially update a specific object | False | False | PATCH /dogs/10 | - 200 (OK), with data
- 204 (NO CONTENT)
- 404 (NOT FOUND)
| DELETE | Delete a specific object | True | False | DELETE /dogs/10 | - 204 (NO CONTENT)
- 404 (NOT FOUND)
| OPTIONS | Get information about a request, notably which other methods are supported | True | True | OPTIONS /dogs | - 200 (OK), with Allow header
| HEAD | Identical to GET, except MUST NOT return a body Response headers SHOULD be the same as equivalent GET request | True | True | HEAD /dogs/10 | |
*Idempotence is the idea that a client can make the same call repeatedly while producing the same result. In other words, making multiple identical requests has the same effect as making a single request. **An operation is considered safe if the operation does not significantly alter the state of the application ResponseSuccess Scenario- 200 if you want send some additional data in the Response.
- 201 Response to a POST that results in a creation of a resource. Should be combined with a Location header pointing to the location of the new resource.
- 202 Operation deleted has not been committed yet.
- 204 Request successful but no content.
- 304 Not Modified - Used in response to conditional GET calls to reduce bandwidth usage. If used, must set the Date, Content-Location, ETag headers to what they would have been on a regular GET call. There must be no response body.
ERRORS and Exceptions:Errors should be as descriptive as possible. The following format is recommended Code | Error code (over and above HTTP code) to describe the error message | Message | User-friendly message | Developer message | Message to debug the problem | More info | Link to additional information |
JSON payload Code Block |
---|
| {
"message": string,
"developerMessage": string,
"moreInformation": string,
"errors": [
{
"message": string
}
],
"code": string
} |
Note:- Either message or message array needs to exist.
- All other elements are optional and if the value is null, the element should be omitted. An element should not be an empty string.
- Use an array of messages to capture multiple validation errors.
- 400 The request is malformed, such as if the body does not parse
- 401 Unauthenticated. When no or invalid authentication details are provided. Also useful to trigger an auth popup if the API is used from a browser
- 403 The request is a legal request but user is unauthorized
- 404 Not Found - When a non-existent resource is requested
- 405 When an HTTP method is being requested that isn't allowed for the authenticated user.
- 409 Resource Conflict can be possible in complex systems. It can be caused by fulfilling the request. Duplicate entries, deleting root objects when cascade-delete not supported are a couple of examples.
- 410 Gone - Indicates that the resource at this endpoint is no longer available. Useful as a blanket response for old API versions
- 415 Unsupported Media Type - If incorrect content type was provided as part of the request
- 422 Unprocessable Entity - Used for validation errors
- 429 Too Many Requests - When a request is rejected due to rate limiting
HTTP Error Code Client error codesServer Error Codes- 500 INTERNAL SERVER ERROR – The general catch-all error when the server-side throws an exception
- 501, Not Implemented. The server does not support the functionality required to fulfill the request. This is the appropriate response when the server does not recognize the request method and is not capable of supporting it for any resource
- 503 Service Unavailable. The server is currently unable to handle the request due to a temporary overloading or maintenance of the serve
Business ExceptionsWhile none of the HTTP response codes match well with a business rule exception, use of the HTTP code 403 indicates that the server is refusing to fulfill the request. This status code can be used when a business rule won’t allow fulfillment of the request - e.g. Enrollment when a class is full. TimestampPer ISO 8601 guidelines, always use UTC time zone. Security It is recommended to follow all of OWASP’s REST security guidelines and to specifically pay careful attention to: - Always use SSL. No exceptions
- Keep it stateless as much as possible
- Avoid sequential numbers for the resource ID
|