REST API Design : Is it ok to change the resource identifier during a PUT call?

Question

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?

Answer 1

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).

Answer 2

Not addressing your question full on, but this makes me worry:

returns the resource ID (eventid) of the new event in the body

You aren't returning an integer id, and then letting the client construct urls from this, are you? A proper REST application should give url's to resources, not ids.

As for your question - PUT means something like "Create a new resource at this location". You could conceivably reply with a redirect and a Location header, but it's a bit of a strange thing to do. Besides, the semantics of PUT dictates that you send the entire entity with the request, which is probably not what you want in this scenario. Maybe it would be more fitting to use POST in this situation? (E.g. POST on /api/event/1234

Answer 3

I think it's ok; PUT is still idempotent (repeated calls will not lead to other modifications).

Just: I would ensure that the old ID is not reused, and have the api return 301 codes for calls to old ID (in case other clients had links to the resource).

Maybe the initial PUT that modifies the ID should return a 303 code that point to the new resource location, I'm not sure here.