I am designing an API endpoint that uses natural keys as resource identifiers.
PUT /api/thing/key
GET /api/thing/key
etc.
My service exposes an Update(...) operation that would result in an SQL UPDATE query that could change this key i.e.
void Update(key, newRow);
When using immutable surrogate keys I had instead
void Update(key, newRowExceptKey);
but since newData can now contain a key the resource can be moved as a result.
Is it acceptable to respond to PUT with 201 AND a Location header to the new resource? This is normal for POST requests but seems antithetical to PUT. A PUT with a new key actually results in a DELETE (in terms of server state) at the request URI and a PUT/POST at some other URI.
On the other hand maybe I shouldn't be using PUT at all. RFC 2616 says "the URI in a PUT request identifies the entity enclosed with the request". In relational terms, if the new key doesn't match the old key, then the request URI doesn't identify the enclosed resource. But it's not that simple. The enclosed resource is a replacement for the request URI so in some context (specifically the one reified by a surrogate key) the the URI does identify the enclosed entity.
I could just use POST here since that doesn't seem to violate any rules, but using POST everywhere seems fast and loose.
