Aristotle Pagaltzis wrote:
* Ian Docherty <[EMAIL PROTECTED]> [2008-01-28 13:45]:
OK, so I put the item into the request body, but this does not
tell the remote client the ID of the created item.
Why does it need it? Is the URI not enough? If not, is the URI
*really* not enough (ie. could things be arranged so that it is)?
The 'create' is a POST to the URI http://mydomain.com/svc/doc with the
content being
the document to save. However, the client has to know the ID of the
created document
(which at this point is only known by the server).
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.
Well, then don’t render the body of the item in the 201 response,
and do not set Content-Location, and instead just put some JSON
or XML or whatever in there.
OK, this would have been my first choice but I was misled I think by
some other threads.
I do this in the Location header.
Location may only ever be a URI. If you put anything else there,
you’re doing it wrong.
Yes I agree.
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?
No. Clients should never parse URIs. If you need to tell them
something they need to be able to understand, you put it in the
body.
(They should not construct URIs either. If they need to request
parametrisable URIs, the server should send them a form. Or if
you’re creating a non-browser HTTP API, you can send the client
a URI Template.)
This is something I have not seen mentioned before. I have no idea what
a 'URI Template'
would look like. I don't see what is wrong with 'constructing' a URI,
e.g. what is wrong
with the client 'knowing' that URI http://mydomain.com/svc/view/1234 is
the location to
retrieve item 1234?
This is the hypermedia constraint in REST: clients only follow
links and forms. They don’t have any hardwired knowledge of the
server URI space.
(Note, though, that things get muddled with Ajax clients. If the
Ajax client is code served by the server (called _Code on Demand_
in REST), then it’s effectively a Turing-complete kind of form
markup, so it’s fine for that code to have hardwired knowledge.
But in practice, the Ajax client probably talks to a publically
available HTTP interface, and making that interface require hard-
wired knowledge of non-Code-on-Demand clients is wrong, so it’s
probably better to follow the hypermedia constraint even in on-
demand code.)
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/
