Re: ISSUE-36: Summary of ways of making containers

hello arnaud.

On 2013-01-24 01:38 , "Arnaud Le Hors" <lehors@us.ibm.com> wrote:
>If I got this right, the premise for doing anything else other than using
>POST the way it's done for other resources is that some don't want to pay
>the price of having to parse the content to find out what the type of the
>resource
> to be created is.

it's not just creation, it's understanding what the request is all about.
when transferring state from client (client intent) to the server, the
server needs to look at the state to understand what it has been requested
to do. in some cases, this really may just mean to store whatever it has
been handed (that would be the database scenario), but in most cases,
transferred state communicates to the server what the client is asking
for, and this often means quite a bit of processing.

i'd argue that since servers have to inspect and validate incoming
requests anyway, building dispatch logic into that processing pipeline is
not that much overhead, but it is true that some frameworks make it harder
(than it should be) to properly dispatch based on request contents.

>Yet, it also seems to be accepted that in most cases one will parse the
>content to validate it anyway, if nothing else.

yup, and dispatching then is rather simple.

>Given all that, I have to ask: Why don't we just accept that finding out
>what type of resource needs to be created is a price some will have to
>pay and stick to POST?

people disliking the idea of having to look at the content of a POST
usually go two ways to engineer around it:

- you tunnel the "request type" in a custom method rather than in the
content. MKCOL is one of these specific methods, and there are various
protocols out there that take that even further.

- you design links so that every link target only accepts exactly one kind
of request. this essentially encodes the "request type" in the URI instead
of a custom method, and URIs of this flavor often look like
http://...../?action=something

i'd argue that in both cases, the protocol is unnecessarily complicated.
if you can do 25 things with a resource, for example, i'd rather not have
25 methods or have to expose 25 links for interacting with it. i'd rather
have one resource URI that i can POST 25 different things to, and if i
have to pass a reference to this resource on, i don't have to hand
somebody 25 bookmarks. all of the interactions are then captured in the
media type, instead of pushing them into extensions of the uniform
interface, or into URI space bloat.

>In practice, I think there are two general categories of use cases. 1.
>generic/vanilla server that simply stores triples and regurgitates them
>without doing anything special with them. 2. application specific server
>- this is
> a bug tracking system for instance - which translates the triples into
>an actual application specific object.

as long as there are no new interactions required, 1 and 2 are identical,
aren't they? only that a specific client has more understanding of
resources, whereas a generic one only sees resources and protocol-level
data, plus opaque payload.

>In the latter case, the server for sure will want to parse the content
>received to figure out exactly what type of object is to be created and
>if the content received has all the bits and pieces required to satisfy
>the application
> needs to create such an object. So, this requirement adds no extra
>burden.

that would almost require some form of "schema installation" service on
the server, so that i could take an out-of-the-box LDP server, and then
constrain its behavior by making it more selective in what it is managing,
right?

cheers,

dret.

Received on Thursday, 24 January 2013 12:30:29 UTC