is restful meant for web services only OR for both web services AND web pages?

Question

I read a lot of Restful tutorials for PHP.

(I don't want to go in depth into why I am not using RoR. It is due to the team being more familiar with PHP)

Because we are planning for future expansion into having APIs i read that it is important to implement Restful web services.

I have looked at tutorials such as

http://www.gen-x-design.com/archives/create-a-rest-api-with-php/

Apparently restful is meant for webservices.

What about for webpages? can they be RESTFUL as well?

if the answer is NO, please do not go beyond this line AND just tell me. Thank you.

i know to make the urls look like RESTFUL urls is to simply use mod_rewrite. However, i am quite sure, restful architecture goes beyond just making the urls look nice.

For eg, i have a list of items on a webpage called list.php . Each item has a delete link next to it. E.g., list.php?id=1&deleteitem

What happens is that when someone clicks on the list.php?id=1&deleteitem link, of course i go back to the same list.php file and check for the param deleteitem in $_GET.

If detected, i will then delete from database based on the param id in $_GET.

After which i will redirect back to list.php WITHOUT any params.

I am wondering, how do i make this whole flow RESTFUL?

I am asking because in REST, to make delete something you need to use HTTP request method (DELETE).

Clearly in my links they are all just simply <a href="list.php?id=1&deleteitem">Delete</a>

Please enlighten me.

My programming is not that strong and it would be good if the advice given can be as layman as possible.

Thank you.

EDIT

I have 2 follow up questions.

question 1) Since this is a list of items with paging, how would the URL look like if i want to make it RESTful?

question 2) Since i am putting DELETE links next to every one of the items in the list, I understand now, i should use

<form method="POST">
<input type=hidden name="_method" value="delete">
<input type="submit" >
</form>

instead.

however the form should be posted to where? the item url? /items/{item-id}

But i want to go back to this listing page displaying a success message AFTER successfully deleting the row in database.

I also want to avoid a popup message when i refresh this listing page with success message.

If i post back to this list.php url, then it is not RESTful yes? because i am told by the answers below that each item is a resource which needs its own url.

Please enlighten me. Thank you.

Answer 1

RESTful is commonly used when referring to web services, but it can very well apply to web pages. In a nutshell, being RESTful is about dealing with resources. A resource can be a person, a book, a movie, a theatre, a ticket, or whatever you fancy.

There are four basic operations you could perform on a resource.

• create (POST)
• read (GET)
• update (PUT)
• delete (DELETE)

Most web browsers do not support the PUT and DELETE actions, so you can only use POST actions for sending data. Rails fakes PUT and DELETE by passing in a hidden parameter named _method that the framework picks up and routes it depending on that value.

Also, you should never use GET for any destructive action. Any action that changes the state of your resource(s), should be called with either POST, PUT, or DELETE depending on the change (fake PUT/DELETE with POST if need be).

I would suggest you checkout the way RESTful routing is handled in Rails just to get an idea, if nothing else. Althought the four actions above are sufficient to modify a resource in any way possible, Rails also introduces three other types of actions that sound useful.

• index (listing view of all items)
• new (usually a form view to add a new resource)
• edit (usually a form view to update an existing resource)

Pretty URL's is definitely on the table when designing RESTful sites, but probably the biggest win is that the quality of code improves automatically. When you're only dealing with resources, and there are only four potential actions that can be applied to a resource, then things start to clean up by themselves.

Edit 1: Self-descriptive URL's are preferred and will make your life easier, but there's nothing stopping from creating cryptic URLs that uniquely identify a resource and manage it using the HTTP verbs. URLs such as the ones below (using md5) to uniquely identify resources are perfectly RESTful.

// represents a person "John Doe"
http://example.com/4c2a904bafba06591225113ad17b5cec

// represents the movie "Lord of the Rings: The Two Towers"
http://example.com/1d9198260dec7bda3fb21e232d60fec3

// represents the "Formula One" sport
http://example.com/fs340as?id=23xa12&type=SP012Ts

That's REpresentational State Transfer right there. The MD5 hash is like the mailing address of the resource that remains constant. The representation could be the movie's details (in html/xml/json/etc.), or maybe the video of the movie itself depending on the capabilities of the client).

Edit 2: Let's say you have a resource which is a collection - countries of the world. It could be represented by a URI and HTTP verb such as:

GET /countries

Since paging is a property of the application rather than the resource itself, you could supply querystring parameters to control it.

GET /countries?page=1

A country is also a resource that is a part of the countries resource. You could identify a country with a URL such as:

/countries/<id>

And operations on this country could be performed with these verbs:

GET    /countries/<id>
POST   /countries  -- the new country has no existing representation
PUT    /countries/<id>
DELETE /countries/<id>

Answer 2

Long answer short: yes. REST is for both. That's because even if you have the simplest of all websites one would still have to GET your page and maybe POST ones personal data to add an entry to the guestbook. In that we all adhere to REST somehow.

In your case poor browser implementation makes it hard to implement a PURE RESTful way. DELETE isn't supported without Javascript and therefore you would have to use GET or POST (which both do have a totally different meaning from DELETE in REST) anyway.