Ask HN: What is RESTful development?

It's hard to get what ReST is because, like AJAX, it is not a standard, language, or library, it is just a set of best practices. Typically, APIs and other web services are loosley described as ReSTful if they use HTTP and XML.

Here is a good example: http://www.peej.co.uk/articles/restfully-delicious.html

Forget about the Wikipedia article, you should first read this: http://tomayko.com/writings/rest-to-my-wife. Other explanations I found good are: http://www.reddit.com/r/programming/comments/91ups/ask_progg... and http://jcalcote.wordpress.com/2009/08/06/restful-transaction...

Unfortunately, REST and RESTful have become buzzwords, roughly take to mean "good" way of doing things. Selecting an approach just because it is the buzz de jour is dangerous. I've had managers ask me about an API, "But is it RESTful?" without an iota of understanding why they need it.

If you have the patience for it, start at the source:

http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch...

I was finally able to understand REST by learning ruby on rails, specifically going through this tutorial here: http://guides.rubyonrails.org/getting_started.html

So REST is a "standard and accepted" way of structuring your URL paths to make them make intuitive sense. Of course thats not the literal definition. You'll see the term "Resource" thrown around. At a basic level, "things" on the internet like a single static web page article, or a single user signed up for a service would known as a "resource".

Let's use a blog as an example. A blog has "authors", "posts", and "comments". These can all be identified as resources of a website. Now think of the interactions you are likely to do with a resource. CRUD comes to mind: Create, Read, Update, Delete.

So a RESTful implementation of a simple blog would have an intuitive URL structure that allowed you to Cread, Read, Update, and Delete "resources".

Consider these urls:

  myblog.com/posts/1
  myblog.com/posts/1/edit

This url structure is the start of a RESTful application. A "post" resource can be identified by its unique id here.

One thing that I was unclear about was that you can send different types of "commands" over http right in the header. For example even though

  myblog.com/posts/1 

is just one url, you can actually do multiple things with it: GET, POST, PUT, DELETE

So depending on the headers you send, your application can do different things. REST recommends that you GET when you want to "read" a blog post, you PUT when you want to update a resource, and DELETE, when you need to delete the resource.

The myblog.com/1/edit is not actually sending the editing commands, its simply GETting the edit "view". The form then should issue a PUT command to update the resource.

Hope this makes sense, I've go to go now but I can clarify if you have any more questions.