[Catalyst] Re: REST - like uri design for CRUD

[Aristotle Pagaltzis]

* Ian Docherty <catalyst at iandocherty.com> [2008-01-26 20:10]:
> I am just doing this now. The way I have implemented it is that
> an item is created by doing a POST to /class/create and the
> item is saved in the database. Then the browser is redirected
> to GET /class/id/1234 (for example) where the newly created
> item (with id 1234) can be read.
>
> Now, this means that the client system will have a http
> response returned with 'status' '302' and 'location'
> '/class/id/1234' which I presume they will have to parse to
> determine the ID of the newly created item?
>
> Is this correct?

No. URIs should never ever be parsed by clients. Only the server
is allowed to treat them as meaningful. Clients rely on
hypermedia for extracting meaning.

Are you asking specifically about what programmatic clients
should do?

For them, the best approach is to return 201 Created instead of a
redirect – the URI of the new resource still goes in the Location
header with 201. Then you render the item into the request body
and set Content-Location equal to Location. That’s a strong
assertion that the body is the same representation that the
client would GET from the URI in the Location header, so
sufficiently savvy clients won’t bother requesting it.

If you don’t have anything to tell the client, you use 204 (again
with a Location header).


PS.: never use 302. It’s ambiguous. Most of the time you really
mean 303, sometimes 307, and on occasion 301. (Well, for complete
correctness, you’d have to send 302 in place of 303 or 307 if the
client at the other end of the connection is speaking HTTP 1.0,
because 303 and 307 were added in 1.1.)

Regards,
-- 
Aristotle Pagaltzis // <http://plasmasturm.org/>