Subject: HTTP at a glance

From: Fiona Schmidtke <[email-masked]>
Date: Sun, 26 Feb 2012 21:54:14 +0000

Hi,

I've just put together a simple website [1] that tries to explain HTTP 
at a glance for all the web developers out there that do not care about 
HTTP at the moment. (e.g. that ones who use GET and POST methods 
interchangeably and state something like "POST is safer than GET, 
because it does not append the data to the URL").
It would be nice if someone could have a look and give some feedback, as 
I don't know if I have covered most of the important things that such 
new developers should get to know. Please don't be too harsh to me, as 
I'm new to the topic, but I'd like to give my best to contribute to the 
understanding of HTTP.

Regards,
Fiona

[1] http://semfact.github.com/httpataglance/

---

From: Amos Jeffries <[email-masked]>
Date: Mon, 27 Feb 2012 23:33:33 +1300

On 27/02/2012 10:54 a.m., Fiona Schmidtke wrote:
> at a glance for all the web developers out there that do not care 
> about HTTP at the moment. (e.g. that ones who use GET and POST methods 
> It would be nice if someone could have a look and give some feedback, 
> as I don't know if I have covered most of the important things that 
> such new developers should get to know. Please don't be too harsh to 
> me, as I'm new to the topic, but I'd like to give my best to 
> contribute to the understanding of HTTP.
>
> Regards,
> Fiona
>

Nice.

Three nitpicks though:
  + PUT is replace or create a resource.
  + POST is send some data to a script or service. NOT create, that is 
one of the big mistakes web dev make today which needs fixing.
  + all of the status codes ranges end at *99. There are HTTP status 
flying around the web reserved by other specifications.

HTH

AYJ

---

From: "Roy T. Fielding" <[email-masked]>
Date: Mon, 27 Feb 2012 13:23:15 -0800

On Feb 27, 2012, at 2:33 AM, Amos Jeffries wrote:

>> I've just put together a simple website [1] that tries to explain HTTP at a glance for all the web developers out there that do not care about HTTP at the moment. (e.g. that ones who use GET and POST methods interchangeably and state something like "POST is safer than GET, because it does not append the data to the URL").
>> It would be nice if someone could have a look and give some feedback, as I don't know if I have covered most of the important things that such new developers should get to know. Please don't be too harsh to me, as I'm new to the topic, but I'd like to give my best to contribute to the understanding of HTTP.
>> 
>> Regards,
>> Fiona
>> 
> + POST is send some data to a script or service. NOT create, that is one of the big mistakes web dev make today which needs fixing.

No, POST can create resources.  The only difference is that the client doesn't
know how the resource(s) will be identified after being created.

....Roy

---

From: Amos Jeffries <[email-masked]>
Date: Tue, 28 Feb 2012 12:06:13 +1300

On 28.02.2012 10:23, Roy T. Fielding wrote:
>>> I've just put together a simple website [1] that tries to explain 
>>> HTTP at a glance for all the web developers out there that do not 
>>> care about HTTP at the moment. (e.g. that ones who use GET and POST 
>>> methods interchangeably and state something like "POST is safer than 
>>> GET, because it does not append the data to the URL").
>>> It would be nice if someone could have a look and give some 
>>> feedback, as I don't know if I have covered most of the important 
>>> things that such new developers should get to know. Please don't be 
>>> too harsh to me, as I'm new to the topic, but I'd like to give my 
>>> best to contribute to the understanding of HTTP.
>>>
>>> Regards,
>>> Fiona
>>>

Only in so far as a script being capable of doing anything it likes. 
There is always a processing layer required on the POST. To convert from 
POST data format and location to whatever the created resource format 
and name is an implementation detail.

At the level of simplification that document has it's clearer to say 
simply "send some data", glossing over details of what the 
script/service implementation could potentially do with the data.

AYJ

---

From: Martin Thomson <[email-masked]>
Date: Tue, 28 Feb 2012 10:31:14 -0800

> know how the resource(s) will be identified after being created.

And some of us really like having some control over our own URI space,
preferring this approach over PUT.  I wouldn't characterize that as a
mistake, just a choice.

---

From: Amos Jeffries <[email-masked]>
Date: Wed, 29 Feb 2012 11:16:55 +1300

> preferring this approach over PUT.  I wouldn't characterize that as a

The blessed way to do that is with a 3xx redirect instructing the 
client where you want the resource PUT if they somehow get it wrong. (Or 
just plain denying wrong PUT if you dont want third-party scripts using 
PUT on your site.)

Yes, I too see a bandwidth problem with that blessed way of doing 
things. Perhapse what is needed is a response indicating "okay, but 
change the URI to X" which does not involve a repeated PUT action. The 
plain PUT+200 sequence seems not to do that easily (workable ideas 
welcome. With my web-dev hat on I have an interest in implementing).

AYJ

---

From: Julian Reschke <[email-masked]>
Date: Tue, 28 Feb 2012 23:54:37 +0100

On 2012-02-28 23:16, Amos Jeffries wrote:
> The blessed way to do that is with a 3xx redirect instructing the client
> where you want the resource PUT if they somehow get it wrong. (Or just

I wouldn't call it "the blessed way". In particular, automatically 
following a redirect upon PUT might be dangerous.

> plain denying wrong PUT if you dont want third-party scripts using PUT
> on your site.)

Yes. If you want to control the URI space, simply do not implement 
PUT-for-create.

> welcome. With my web-dev hat on I have an interest in implementing).

So you want PUT semantics with server-chooses-URI? I tried to specify 
this a few years ago 
(http://greenbytes.de/tech/webdav/draft-reschke-http-addmember-latest.html) 
but was "convinced" that POST is sufficient, so defined the 
WebDAV-specific RFC 5995.

Best regards, Julian