Using http status codes on REST API design
To properly design a REST API we should look into RESTful principles, these were first introduced by Roy Fielding in Chapter 5 of his dissertation on network based software architectures. These divide the REST service into separated resources, manipulated using the different HTTP methods and that performs responses by the usage of the different http status codes.
So the basic design guidelines comprises the following:
As we already covered the design guidelines for Resources in REST API design and design guidelines for http methods in REST API design we will move into the http status codes.
It is very important that as a RESTful API, you make use of the proper HTTP Status Codes especially when mocking RESTful API.
The mostly used status codes:
200 – OK
Everything is ok and working
201 – CREATED
New resource has been created, with the proper Id returned.
400 – BAD REQUEST
The request was invalid or cannot be served.
401 – UNATHORIZED
The request requires user authentication.
403 – FORBIDDEN
The server understood the request but is refusing it or the access is not allowed.
404 – NOT FOUND
There is no resource behind the URI.
500 – INTERNAL SERVER ERROR
The problem is at the server side.
With this we end the cycle of basic design guidelines for the different elements:
Resources - Guidelines for Resources in REST API design
Http Status methods - Using http methods in REST API design
Status Codes - Using http status codes on REST API design