HTTP Status Codes for PUT DELETE Operations

For successful UPDATE (PUT) and DELETE operations in REST APIs, the most appropriate HTTP status codes are 204 No Content (when no response body is needed) or 200 OK (when returning updated resource information). According to RFC 7231, DELETE operations can also return 202 Accepted for asynchronous operations. The choice between these codes depends on whether your API returns response bodies and whether the operation is synchronous or asynchronous.

Contents

• PUT Operation Status Codes
• DELETE Operation Status Codes
• RFC Standards and Best Practices
• Common Scenarios and Recommendations
• Error Handling Considerations

PUT Operation Status Codes

When implementing successful UPDATE operations using the HTTP PUT method, you have several status code options:

204 No Content is the most commonly recommended status code for successful PUT operations when:

• The update operation completes successfully
• No response body needs to be returned to the client
• The client doesn’t need to navigate away from the current page
• You want to minimize network traffic

The HTTP 204 No Content response is cacheable by default and doesn’t include a message body, making it efficient for update operations.

200 OK should be used when:

• You want to return the updated resource representation to the client
• The client needs confirmation of the updated state
• Your API design includes returning resource bodies for successful updates

As noted in the Stack Overflow discussion, there’s no RFC requirement that PUT should never return a body, and 200 OK with a response body is perfectly acceptable.

202 Accepted can be appropriate for:

• Asynchronous update operations
• When the request has been accepted but processing hasn’t completed
• Long-running update operations

DELETE Operation Status Codes

For successful DELETE operations, the HTTP specification provides clear guidance according to RFC 7231:

204 No Content is the preferred choice when:

• The resource has been successfully deleted
• No further information needs to be supplied
• You want to indicate success without returning a response body

The Moesif Blog explains that “204 No Content - The most fitting status code for this case. It’s better to reduce traffic and simply tell the client the deletion is complete and return no response body (as the resource has been deleted).”

200 OK should be returned when:

• You want to return information about the deleted resource
• The client needs confirmation of what was deleted
• Your API design includes success messages with payload

202 Accepted is appropriate for:

• Asynchronous delete operations
• When the deletion request has been accepted but not yet processed
• Background delete operations that take time to complete

RFC Standards and Best Practices

The RFC 7231 specification provides authoritative guidance on HTTP status codes:

“If a DELETE method is successfully applied, the origin server SHOULD send a 202 (Accepted) status code if the action will likely succeed but has not yet been enacted, a 204 (No Content) status code if the action has been enacted and no further information is to be supplied, or a 200 (OK) status…”

This establishes the three main success status codes for DELETE operations based on the operation’s nature.

For PUT operations, while RFC 7231 doesn’t specify mandatory status codes, the HTTP.dev documentation clarifies that “204 No Content status code is received, it is in HTTP response to a HTTP operation such as a POST, PUT, or DELETE, where no message body is expected.”

Key RFC-compliant best practices include:

• Using 204 No Content when no response body is required
• Ensuring 204 responses don’t include a message body
• Being consistent in your API’s status code usage
• Providing appropriate Allow headers when supporting multiple methods

Common Scenarios and Recommendations

PUT Operation Scenarios

Scenario 1: Updating a user profile

• Use 204 No Content if the client doesn’t need the updated profile data
• Use 200 OK with the updated profile data if the client needs confirmation

Scenario 2: Updating with validation failures

• Use 400 Bad Request for client-side validation errors
• Use 422 Unprocessable Entity for server-side validation issues

Scenario 3: Partial updates (PATCH)

• Consider using 200 OK with the updated resource representation
• Use 204 No Content for successful updates where no response is needed

DELETE Operation Scenarios

Scenario 1: Synchronous file deletion

• Use 204 No Content for immediate, successful deletion
• Use 200 OK if you want to return metadata about the deleted file

Scenario 2: Asynchronous resource cleanup

• Use 202 Accepted to indicate the request is queued
• Follow up with 204 No Content when the operation completes

Scenario 3: Resource not found

• Use 404 Not Found if the resource doesn’t exist
• However, as noted in Tugberk Ugurlu’s article, “If the resource is already removed and you receive an HTTP DELETE request for that resource, return 200 or 204 in that case; not 404”

Error Handling Considerations

When implementing PUT and DELETE operations, consider these error cases:

Common PUT errors:

• 400 Bad Request for malformed requests
• 401 Unauthorized for authentication issues
• 403 Forbidden for authorization problems
• 404 Not Found for non-existent resources
• 422 Unprocessable Entity for semantic errors
• 500 Internal Server Error for server issues

Common DELETE errors:

• 400 Bad Request for invalid requests
• 401 Unauthorized for authentication failures
• 403 Forbidden for authorization problems
• 404 Not Found for non-existent resources (though consider RFC guidance)
• 409 Conflict for dependent resource issues
• 423 Locked for resource locks
• 500 Internal Server Error for server problems

The CodeJava REST API guide emphasizes that “Return the appropriate status code for each request” as a fundamental REST API best practice.

---

Sources

1. RFC 7231 - Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
2. HTTP 204 No Content - MDN Web Docs
3. Which HTTP Status Code to Use for Every CRUD App - Moesif Blog
4. HTTP DELETE: HTTP 200, 202 or 204 All the Time? - Tugberk Ugurlu
5. Best Practices for REST API Design - Stack Overflow
6. REST API Best Practices - CodeJava
7. HTTP.dev - 204 No Content
8. The API Changelog - HTTP 204 Is the Best DELETE Response

Conclusion

• For PUT operations: Use 204 No Content when no response body is needed, or 200 OK when returning updated resource data. 202 Accepted is appropriate for asynchronous operations.
• For DELETE operations: Follow RFC 7231 guidance - use 204 No Content for immediate success, 200 OK when returning metadata, or 202 Accepted for asynchronous processing.
• Consistency is key: Choose a pattern and stick with it throughout your API for predictable behavior.
• Consider your API consumers: Think about what information clients need after successful operations to guide your status code choices.
• Error handling matters: Implement appropriate error status codes (400, 401, 403, 404, 422, etc.) for various failure scenarios.

By following these RFC-compliant best practices, your REST API will be more predictable, efficient, and easier for developers to consume.