Based in Milan, Italy, Diary of a Digital Engineer is a blog by Stefano Sandrini. Here I post about my journey as a software engineer and solution architect, new ideas, thoughts and quotes by influential architects, engineers, and digital innovators.

Mapping HTTP status codes for REST API Response

In D-Share I'm always involved in the design and definition of API layers for our solutions. Often, talking with devs, I find myself having to indicate what are the appropriate responses that the API must provide as appropriate.

In particular, for each API endpoint we always need to consider what response code(s) to return in case of success or failure.

From my experience, I believe it is important to map both success and error codes in the design phase, as it will be part of our documentation delivered to developers and because it is a good exercise to verify the correctness and the complexity of our API.

Usually, my mapping is:

  • 200 OK - Response to a successful invocation, for all HTTP verbs.
  • 201 Created - Resource created successfully , for a HTTP POST.
  • 204 No Content - Resource deleted successfully (will not return a body) , for a HTTP DELETE
  • 304 Not Modified - Cached result
  • 400 Bad Request - The request is malformed, or don't pass validation. Used with GET, POST, PUT
  • 401 Unauthorized - No authentication credentials provided or credentials are invalid.
  • 403 Forbidden - Authenticated user is not authorized to access the resource
  • 404 Not Found  - The requested resource was not found


I hope you have some advice with this mapping. See you next time, Ste 

Small guide on resource URL design for REST API

Amazon ECS: using the CLI with Docker Compose