* Ian Docherty <[EMAIL PROTECTED]> [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/> _______________________________________________ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
