Re: A proposal for clarification to section 4.3 HTTP POST

hello cody.

On 2013-03-23 11:49 , Cody Burleson wrote:
> I guess that's fair enough. I can accept that there are different "world
> views" or, perhaps, interpretations on this stuff. And perhaps that is
> reason alone to side in favor of leaving it out.

i was just voicing my opinions. i have spent a lot of time trying to 
help people understand that HTTP's methods are not CRUD, so it's a 
touchy topic for me.

> To me, the following statement, which is the first under HTTP POST in
> the HTTP 1.1 spec seems to indicate that, in general, POST is used for
> create.
> "The POST method is used to request that the origin server accept the
> entity enclosed in the request as a new subordinate of the resource
> identified by the Request-URI in the Request-Line. "

this wording is a bit outdated. 
http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-22#section-4.3.3 
is what HTTPbis will say, and has been generalized from the narrower 
uses cases that motivated the early HTTP wording.

> I'm not sure I understand how a CRUD view of HTTP is misguided. Seems
> like just semantics to me.

my biggest problem with this is that people then start thinking that if 
they want to do anything beyond CRUD, they "run out of methods". that 
interpretation often leads to a variety of not so great ways how to 
solve that problem. if, on the other hand, you treat HTTP methods as 
driven by interaction semantics, and not specific operations (such as 
CRUD), you never "run out of methods".

> "GET and HEAD methods SHOULD NOT have the significance of taking an
> action other than retrieval."
> OK, for me, it's hard to see how that can be much other than READ.
> Retrieve / read. Same thing, right?

yes, for GET, i am fine with the read, it basically just means "doesn't 
change anything (relevant) as a result of the operation".

> The spec says PUT is the same as POST except that if the resource
> already exists, it updates it (and URIs are looked at differently). To
> me, that's UPDATE.

yes, but PUT often already gets a bit more tricky than just blind 
"overwrite", because the server often is processing the request, instead 
of just blindly updating the resource.

> "The DELETE method requests that the origin server delete the resource
> identified by the Request-URI."
> The D in CRUD.

yes, that's another easy one.

> PATCH = partial modifications to a resource, which to me is just another
> form of UPDATE.

nope, PATCH is POST, not PUT. strictly speaking, this depends on your 
PATCH media type (if i PATCH the same thing twice, does it change two 
times?), but PATCH does not restrict patch semantics in any way, so it 
is closely related to POST (it is neither safe nor idempotent).

> I guess I am curious to know how this view is misguided. And not to be a
> smart aleck; I accept that I have much to learn. And I have many
> colleagues who look at it this way too. So, maybe if you get time you
> could elaborate on your thoughts a little (or point me to some resource
> that might help broaden my perspective).

i haven't written anything (other than a bunch of tweets), but it is an 
interesting topic (and you can google it and will find many things). it 
requires quite a bit of context, also because of the implicit understand 
of CRUD that many developers have. for example, in REST, you could say 
that you use CRUD when designing transactional stuff, because very often 
you create a transaction as a resource, may add certain things to it, 
and then start it. so there is "CRUD" at work here as well, but for 
resources that are transactions. in my experience, it is better to not 
explain/conceptualize REST as CRUDdy, because you associate it to things 
that for most developers are on a different level (database operations, 
very often).

to summarize, saying whether REST is or isn't CRUD doesn't really make 
all that much sense, because you're comparing apples and oranges. REST 
talks about uniform interfaces in general, CRUD is a specific set of 
operations, often in a specific conceptual world. so my experience is 
that in the end, just comparing these two things can be confusing, so we 
might want to stay clear of making any statements about this.

again, that's just my opinion. cheers,

dret.

Received on Saturday, 23 March 2013 23:59:55 UTC