Aristotle Pagaltzis wrote:
* 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?
Yes I am
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.
OK, so I put the item into the request body, but this does not tell the
remote client the ID
of the created item. Say for example that I am putting arbitrary
documents (xml, text,
images) etc. onto the server via a web service in a RESTful manner, I do
this with a POST
to my server. The server needs to respond with something in the header
to indicate the
ID of the document just POSTed. I do this in the Location header.
e.g. POST /svc/upload (the document save)
Location /svc/view/1234 (the location of the item just saved, ID=1234)
So the URI is parsed by the programmatic client to extract the '1234'
yes/no?
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,
_______________________________________________
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/
