Home/ Questions/Q 8793901
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-13T23:10:54+00:00

I’m curious to learn more about RESTful design patterns around the PUT call. Specifically,

  • 0

I’m curious to learn more about RESTful design patterns around the PUT call. Specifically, am I violating norms by changing the resource ID as part of a PUT call?

Consider the following…

POST /api/event/  { ... } - returns the resource ID (eventid) of the new event in the body
GET  /api/event/eventid
PUT  /api/event/eventid   - returns the (possibly new) resource ID depending on request body
GET  /api/event/eventid   - fails if the original eventid was used in the URI

The endpoints for GET and PUT can quickly access the resource if the eventid represents internal resources (like a database record). If the PUT results in the server moving the underlying resource, the ID can change.

Am I violating norms when I do this?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    REST is not a strict specification, but more a set of guidelines and best practices that can be followed to build web-services that are easy to understand and work with. So there’s nothing that prevents you from changing a resource IDs during a PUT.

    That being said, doing so is IMO a bad practice. One of the ideas behind REST is that each resource can be referenced using a URI. In your case this URI is the concatenation of the path and (I assume) an internal ID. This URI could be used by other “systems” and stored as references. If you change the ID of a resource on a PUT, you change the URI and all references to that resource will be broken (404).

    If you feel the need to change the ID that is part of the URI, you may not have picked the right property for it. Consider something else that would be immutable (e.g.: tag your resource with a UUID and use it rather than an internal DB ID).

    • 0