The entry itself can still be readable even if the collection is
write-only.
Say the collection is at /comments
A GET to /comments will return a 401
However, a POST to /collection will succeed with a 201 that can
return a Location to, say, /comment/37
The user can then GET /comment/37
They may even be able to PUT /comment/37 to update their comment
They just can't GET /comments
So Tim's question about POSTing to something you can't GET refers to
the collection, not the entry.
James
On 14/05/2006, at 4:46 PM, Daniel E. Renfer wrote:
Would it be okay to do this if the server responds with a '202
Accepted'?
Looking at section 5.2 it only mentions returning 201, but by previous
conversations on the list, it looks like that is allowed. Is it? In a
situation like that, do you still have to return a location? (even if
a GET on that location returns 401)
It seems to me that a 202 with no location would be fine. The client
has no way to track the post, but that's kinda the point of a
WRITE-only server.
What do you think? Should the spec be made more explicit as to whether
this is allowed or not?
Daniel E. Renfer (http://kronkltd.net/)
On 5/14/06, Bill Kearney <[EMAIL PROTECTED]> wrote:
> I think servers should be free to list read-only resources (w/ no
> "edit" link relation) or omit them as is situationally appropriate.
Except he's not asking about READ-only, he's asking about WRITE-only.
Is there some mechanism for determining that the endpoint is write-
only? I
could see where not being able to post back to an item that's become
'write-only' in that it's no longer editable. But I'm not sure how
convenient it's going to be for tool to dump something to an endpoint
without being able to turn around and retrieve it again. I can
see where
some situations would find it appealing to use a write-only
interface but
wonder if they're anything more than edge cases?
-Bill Kearney
Syndic8.com
