Re: A proposal for clarification to section 4.3 HTTP POST

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.

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. "

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

"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?

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.

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

The D in CRUD.

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

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).

- Cody


On Sat, Mar 23, 2013 at 12:07 PM, Erik Wilde <dret@berkeley.edu> wrote:

> hello cody.
>
>
> On 2013-03-23 9:42 , Cody Burleson wrote:
>
>> I just think we would do well to try to make less assumptions on the
>> reader's knowledge and provide brief hints that give a little
>> confirmation to what the reader is probably already assuming (for
>> comfort).
>> So, in this case, now that I've clarified that we're referring to the
>> HTTP/1.1 spec, I summarize the most salient point(s) from there so that
>> it is not necessary to do a cross-check.
>> "Ah, yup... ok... POST for create... maybe also PUT...".
>>
>
> it's a valid point that many look at HTTP methods in terms of "mapping"
> them to CRUD operations. however, i think it might be good to neither
> confirm nor reject this world view. these are simply two different things
> to talk about. we expose LDP interactions through HTTP interactions. when
> they are idempotent and safe, we use GET. when they are idempotent but not
> safe, we use PUT or DELETE. when they are neither safe nor idempotent, we
> use POST or PATCH (maybe). that's it, that's what HTTP defines, and we
> should stick to that story, and not reinforce the misguided "CRUD
> understanding" of HTTP.
>
> cheers,
>
> dret.
>
> --
> erik wilde | mailto:dret@berkeley.edu  -  tel:+1-510-2061079 |
>            | UC Berkeley  -  School of Information (ISchool) |
>            | http://dret.net/netdret http://twitter.com/dret |
>



-- 
Cody Burleson
Enterprise Web Architect, Base22
Mobile: +1 (214) 702-6338
Skype: codyburleson
Email: cody@base22.com
Blog: codyburleson.com

* <http://base22.com>*
*
*
*Check my free/busy
time.<http://www.google.com/calendar/embed?src=cody.burleson%40base22.com&ctz=America/Chicago%20>
*