Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Thinking About API Status Codes for Destroying Entities Using DELETE

DZone's Guide to

Thinking About API Status Codes for Destroying Entities Using DELETE

An API thought leader and consultant discusses some interesting things organizations are doing with their HTTP requests for developing APIs.

· Integration Zone ·
Free Resource

SnapLogic is the leading self-service enterprise-grade integration platform. Download the 2018 GartnerMagic Quadrant for Enterprise iPaaS or play around on the platform, risk free, for 30 days.

I am pulling together some API design guidance for some projects I’m consulting on, so I’m spending time reviewing the API design guides by the leading API providers who have published them publicly. Learning from what they are doing across their own companies, organizations, institutions, and government agencies when it comes to sensible API governance.

Today, I am learning from the British food delivery company, Deliveroo, and documenting their guidance for which HTTP status codes should be returned for any API methods that use DELETE:

If it exists, it should return status:

  • 204 No Content if the entity was successfully destroyed.
  • 404 Not Found if the entity does not exist.
  • 410 Gone if the entity is known to have existed but no longer does.

Additionally, 4xx response codes may be used:

  • 412 Precondition Failed.
  • 415 Unsupported if using versioning and the server doesn’t support the specified version.

I have to admit, I haven’t been properly publishing status codes of any DELETE methods I provide. I’ve just been returning a 200 if successful, and 404 if it didn’t exist. I hadn’t put any further thought into the proper way of handling it. I just haven’t had the time, or the knowledge within reach to be able to handle it properly.

I know that the RESTafarians enjoy debating these finer details of API design and using HTTP, but for the rest of us, we just need some guidance from y’all. Which is why I spend time learning from existing API leaders who publish their API design guidance, and sharing as individual stories here on the blog, as well as including in my official project consulting guidance.

Download A Buyer's Guide to Application and Data Integration, your one-stop-shop for research, checklists, and explanations for an application and data integration solution.

Topics:
integration ,api ,api design

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}