web nerdz

Subject: web nerdz

• note: originally emailed 06/27/2014 and sanitized for public consumption
• sidenote: posting here so i can lead people here whenever they ask me about this stuff...

---

Many moons ago, I wrote the "http fun with telnet" post.


I think it needs to be revisited due to the renewed interest in 'standardized' REST calls (what web nerds say, "the way it was meant to be done")...


PUT vs POST

First, there's usually been some confusion with how REST calls are used --- in particular PUT vs POST.


Here are examples of what I mean:

• http://stackoverflow.com/questions/4573305/rest-api-why-use-put-delete-post-get

A very simplistic implementation of REST could use the following CRUD mapping:

Create -> Post
Read -> Get
Update -> Put
Delete -> Delete

• http://jcalcote.wordpress.com/2008/10/16/put-or-post-the-rest-of-the-story/

So often, developers will try to correlate these two concepts -- CRUD and REST -- using a one-to-one mapping of verbs from the two spaces, like this:



• Create = PUT
• Retrieve = GET
• Update = POST
• Delete = DELETE

But, really, a create/updating request should be thought of 'same thing'.

• http://en.wikipedia.org/wiki/Create,_read,_update_and_delete



Operation		HTTP
Create		PUT / POST
Read (Retrieve)		GET
Update (Modify)		PUT / PATCH
Delete (Destroy)		DELETE

Note: PUT and DELETE are normally not enabled on all web servers



Server side processing

Because PUT and DELETE are quite dangerous if not controlled, server side processing (PHP, ASP, etc.) handled much of the PUT/DELETE (i.e. create, update, destroy) processes by incorporating them with AJAXy APIs (normally done with GET and POST only).


Let's see an example of the "server side processing" that a lot of people are used to:

• http://webserver/account/?action=update&foo=bar
• http://webserver/account/?action=delete&foo=bar
• http://webserver/account/?action=upload -- POST with binary or text data
• etc.

Here, the action parameter is descriptive, to the point and clear on intention.


I do realize that the URL "parameters" are much more descriptive than 'PUT'...

• But, you'll need to see what is 'implied' when using GET/PUT/POST...

Idempotent Retries

There's a very important concept for web server technologies that needs to be understood before continuing

• http://stackoverflow.com/questions/1077412/what-is-an-idempotent-operation
• In other words, sometimes:
• the web connection breaks
• the browser mis-behaves or
• user likes to hit the reload button
• The web server needs to respond to the request as if it (the request) had been done only once
• Think of this as self-recovery

Pretty URLs

A lot of web nerds want to slim down the URL so that search engines can "crawl" your web site with impunity.


Anyways, back to the implied usage of GET/PUT/POST/DELETE (what they call HTTP verbs). Let's take a look at an example URI:

• http://webserver/account/nick
• GET would return my details
• PUT could update my details
• A first time POST would create my account
• And of course, DELETE would disable or nuke my account
• Note that each of the methods does different things while the URL stays the same

You can still use server side processing to handle this

• For example, in: http://webserver/account/
• The index page has been setup as "app.php"
• E.g. http://webserver/account/.htaccess contains:
• DirectoryIndex app.php


• app.php will process (for example) /account/nick as the ARGs for the script (and any POST or URL parameters) to handle the request


• you can look at (http_fun_with_telnet) and add handlers for PUT and DELETE to complete this homework assignment