REST opinions

[meryn]

@meryn -- The reason I kept a timed "login" was to keep it the clients stateless. How does my plan above contradict REST? I am sure it does, but I could not see how. Relying on HTTP authentication is too limiting and I didn't see how it was enforced by REST other than philosophically.

Now I really don't understand . You would need frames or some such to maintain state as otherwise the whole thing will be blown away by the next request.

A frameset is a good example of a client holding it's own state. Frames do have many usability issues when used for normal websites, so I would only use them when I want to simulate a GUI application - like a mail client - inside a browser.

As I said, you can use cookies to maintain client state over multiple requests. The server should't touch the cookie though.

Also I thought REST was about not shipping app. code (like applets) to the browser, just document formats.

REST is about transferring resource representations. A representation can be plain text, an image, a 'static' HTML page, but also an interactive view written in Flash or using 'DHTML'.

Now I know programs are just data, but it seems you are taking the complexity out of the server architecture and just moving the whole lot into a massively complex document.

In a REST based application, server and client are responsible for their own issues. It's seperation of concerns. The server is responsible for keeping state of it's resources. The client is resposible for keeping state of it's user interface. This means that to achieve the same functionality as what you can do with sessions in PHP, you need a heavier client.

I used to think that web applications should be implemented using static HTML and keeping all functionality on the server, so I can understand how you feel. It's quite a mindshift.

And please don't get me wrong: I will never say that it's easy to make such a seperation. It's in some way comparable to OO design; deciding which party does what.

[meryn]

The question is then what URL do you use to create a new article? Perhaps http://site.com/articles/new ? Almost a verb but not quite.

You don't need a new URL for that. Just POST the representation of the new article to http://site.com/articles/ .

[meryn]

Question - if a client can support many content types, how does it instruct the server what type it would prefer?

HTTP has a mechanism for this called content negotiation. It would be a nice browser feature to be able to alter the mimetype preferences (either globally or for a specific resource). Currenty, such a feature isn't available. This means that if you want to provide users with such functionality, you must code it yourself like is done by ZVON...

There's one problem that keeps coming up:
There are no browsers that support the powerful features of HTTP. It's the fault of the browser makers that we know have to develop our own solutions... with incompatible implementations.

This means that REST is better in theory than in practice. Lack of tool support...

[lastcraft]

Hi...

so maybe i should stick to my orignal plan and send you my results ?

It is a lot more complicated than that and sadly I haven't had much chance to contribute myself. You should chat to Jason and if you are on the same lines maybe we should sign you up. The decent UI was planned for version 1.1 originally, but the version 1 release has been delayed a bit tying up loose ends.

Post a note to the support forum as this is a bit off topic even for the original off topic strand .

yours, Marcus

[sike]

Hi...



It is a lot more complicated than that and sadly I haven't had much chance to contribute myself. You should chat to Jason and if you are on the same lines maybe we should sign you up. The decent UI was planned for version 1.1 originally, but the version 1 release has been delayed a bit tying up loose ends.

Post a note to the support forum as this is a bit off topic even for the original off topic strand .

yours, Marcus

support forum @ sourceforge i guess ?

Sike

[lastcraft]

Hi...

support forum @ sourceforge i guess ?

Sorry, it's actually a mail list. Yes.

yours, Marcus

p.s. Sorry Jeff. You can have your thread back now...

[HarryF]

You could just use the new name like a Wiki.

Good point, as with posting to http://site.com/articles/.

The follow up question is where do you place the HTML forms for making the POSTs, without using verbs? REST seems to suggest you have "documents" represented by URLs and "tools" for editing (and perhaps navigating) them.

Seems to me that REST is a pattern rather than some "one true way".

Agreed. REST seems more a reflection on what is, rather than anything new, trying to highlight best practice and how to get most "re-use" out of the Internet.

[dagfinn]

In a REST based application, server and client are responsible for their own issues. It's seperation of concerns. The server is responsible for keeping state of it's resources. The client is resposible for keeping state of it's user interface. This means that to achieve the same functionality as what you can do with sessions in PHP, you need a heavier client.

Doesn't that mean that we will need a client-side programming language that's powerful, cross-browser compatible, stable, reliable and non-proprietary?

[meryn]

For example, say you wanted a PDF for better printing. There is no PDF filter button available on the browser, so it has to be taken as a preference into the server.

That's one example of the shortcomings in the HTTP support of common browsers.

As I see it, the whole world has settled upon using only a subset of the features of HTTP. This won't change soon, if this changes ever. The main reason for this is that GET and POST, combined with sessions and complex URLs is 'good enough' in most cases.

I'm still hoping that sometime in the near future, an opensource project like mozilla or konquerer will make a browser that fully supports all HTTP 1.1 features, so you could use this as a platform to make advanced REST-based intranets (where you have control over the clients). It wouldn't exclude other browsers ofcourse. They at least would still be able to GET all available resources.

[meryn]

REST seems to suggest you have "documents" represented by URLs and "tools" for editing (and perhaps navigating) them.

Yes, I think this is a good interpretation.

The follow up question is where do you place the HTML forms for making the POSTs, without using verbs?

I think that a representation of the 'articles' resource on a server (identified by the URI http://somesite.com/articles/ ) could include instructions on how to add a new article to this collection. This could be implemented using a HTML form. If you don't want to show the form initially, you could make the form initially hidden, and provide 'add article' link which triggers a javascript which shows the forms.

You could also decide to only show the add form when the articles resource is queried with ?action=add.

Another option would be to think of adding an article as a service, which in turn can be seen as a resource. GET /articles/addservice/ would return a form, and posting the form to the addservice would trigger the service to change the /articles/ resource. The interpretation of a resource can be as broad as you want...

[dagfinn]

A frameset is a good example of a client holding it's own state. Frames do have many usability issues when used for normal websites, so I would only use them when I want to simulate a GUI application - like a mail client - inside a browser.

I suppose you could have an invisible (like extremely small) frame that was just for storing state information, and another frame that had all the screen real estate and all the action.

[stupidiot]

hi, i'm newbie in REST.. but really get interested about its idea.

i've been googling for REST tutorials and implementation guides recently, however i couldn't really find a nice complete article demonstrating a implementation of REST on current web app.

if anyone already using REST in web app., do share some ideas, thanx.

-----
btw, since REST is using HTTP basic methods (PUT, GET, DELETE, POST etc)

how well does PHP support HTTP /1.1 spec? will it be suitable to use PHP on writing a RESTful server?

i just get started coding with php. so, pls correct me if i'm wrong. Searching thru' php4 doc, i couldn't find a way to handle HTTP DELETE method.. and PUT is being handle quite 'differently' from GET and POST.

is there a better solution to handle HTTP methods via php?

[meryn]

The best example of a widely used RESTful application is the Atom API. It's used in blogging software. It also has a PHP implementation. It can be found at http://www.isolani.co.uk/blog/atom/P...Implementation .

The HTTP request method is available in $_SERVER['REQUEST_METHOD'].

For non-CRUD oriented applications (i.e. those involving complex business logic and processes) it takes quite a mindshift to explain this in terms of resources which can be read (GET), changed (PUT), DELETEd or POSTed to. I certainly found it a challenge, and it still is.

If you have specific questions RESTifying your application, you could best start a new thread I think. I might be able to help. I'll check these forums some more often from now on.

[stupidiot]

Thanx for the reference link about ATOM.

i've read about ATOM juz now. tat's really a good start point to learn about REST design.

i think one thing that most non-CRUD web application developer do concern is the user-session management, which already widely deployed in current web-based business.

well, i think i'll just start a new thread

[stupidiot]

It has been a while, since the last post about REST discussion.

Yesterday, I made a simple presentation slide, by using Weblog as an
example of web applications, the slide will introduce to readers the basic
idea of how a RESTful web application looks like.

Wish to recieve your comments and suggestions about slide's contents

Here's the link: http://www.geocities.com/iamstupidio...ple-Weblog.ppt

(Please pm me if you have any access problem to that file).

[MiiJaySung]

It has been a while, since the last post about REST discussion.

Yesterday, I made a simple presentation slide, by using Weblog as an
example of web applications, the slide will introduce to readers the basic
idea of how a RESTful web application looks like.

Wish to recieve your comments and suggestions about slide's contents

Here's the link: http://www.geocities.com/iamstupidio...ple-Weblog.ppt

(Please pm me if you have any access problem to that file).

It puts across the idea well. It should maybe mention what Harry said about the use of verbs. The other thing that leaves me unclear is the use of PUT and DELETE http methods. However how do you deal with anchor links that delete resources as you can't set a method for hyperlinks (Not to mention you need to use action verbs in the URL). However depending on forms servely limits your user interface.

[DougBTX]

You don't want to have GET requests that modify things serverside, example: Google releases Web Accelerator, which pre-downloads pages that it sees links to. People visit pages with links to delete content, content gets deleted. Bad bad bad.

I don't believe IE supports PUT and DELETE, which puts a bit of a damper on things. That's why you only ever see GET and POST in the wild. You can simulate PUT and DELETE with POST, so all is cool. Add an <input type="hidden" name="method" value="DELETE" /> to your POST form and be happy.

You can get near-REST, but it means putting more things in cookies, unless you can argue sessions as a layer between the client and your RESTful app.

Douglas

[auricle]

I don't believe IE supports PUT and DELETE, which puts a bit of a damper on things. That's why you only ever see GET and POST in the wild.

I've never understood how a browser decides which request method is appropriate (other than the method attribute in a form tag, or maybe assuming that anything submit via a form should be a POST rather than a GET).

Can one force a browser to issue a PUT or a DELETE (by simple markup)?

Anyway, I found this project, previously mentioned by Harry interesting..

[stupidiot]

It puts across the idea well. It should maybe mention what Harry said about the use of verbs.

Do you mean Harry's http://www.sitepoint.com/forums/show...2&postcount=21

I think when we design a system, starting by identify required resources (which are all nouns), will effectively reduce cases, where "verbs" appear in URLs.

The other thing that leaves me unclear is the use of PUT and DELETE http methods. However how do you deal with anchor links that delete resources as you can't set a method for hyperlinks
(Not to mention you need to use action verbs in the URL). However depending on forms servely limits your user interface.

The main purpose of using a set of standard interfaces, or HTTP methods in this case is, now, we provide meaningful semantic to each request, before sending it out across a network of machines towards the target server.

Machines across Internet network understand HTTP methods well, and you can tell machines how to handle each type of request:

DELETE /articles/23444  HTTP/1.1

(we can tell any HTTP machines, maybe gateways/proxies to block all DELETE requests, if we don't want ppl to delete it. They understand that.)

GET /articles/23444?action=delete HTTP/1.1
GET /delete.php?article=23444 HTTP/1.1

(machines don't understand "?action=delete" or "delete.php". Further, they assume GET is always safe from changing resource state. However, these URLs actually will kill that resource!)

Real life truth...
Current browsers, and HTML specs only help us to send out GET and POST requests. Later browsers support XmlHttpRequest object to allow client scripts send out custom method request.

If we don't like forms and buttons in page design (me too :P), gmail is an example of using achor links to activate XmlHttpRequest objects using client scripts.

Some thoughts...
--------
I find that there're two ways to send out appropriate method requests using current browsers:

1. Clientscript - XmlHttpRequest + Forms
When the end user submits a form, XmlHttpRequest is called to send out the content with desired HTTP methods (GET,PUT,POST,DELETE etc).

The target URL should be referenced to the target resource itself.


2. POST + Forms
The forms act as a Processing Resource (as suggested by Mark Baker[BAKER]). When the end user pushes to submit button, content is POSTed to that form. The form will process and send out requests to target resources with appropriate HTTP methods.

The target URL should be referenced to that form.


Of course, GET is always easily available for everybody to retrieve our resources, by just providing a link. Two cases above are when we need to manipulate the resource state (or content).


Why we do that?
1. Clean separation client software and server software
Now, you can actually put your client software in different machines across Internet network. Changes in entire client codes, doesn't affect server software (which all resources stay).

2. Resources are more manageable
One resource is identified by one URL. If we want to prevent certain resource from being altered, we just block POST,PUT,DELETE requests and allow only GET request.

When resources grow more, we can migrate some of them to mirror server easily, and the old server will issue "3xx Redirect" response to inform clients.



[BAKER] An Abstract Model for HTTP Resource State (Section 3.1.4)
http://www.markbaker.ca/2001/09/draf...e-model-01.txt

[Dr Livingston]

unless you can argue sessions as a layer between the client and your RESTful app.

From what I understand of REST, you shouldn't really be using this methodology (the use of SESSIONs) anyways, but I've need felt RESTful at any time anyways so I may be wrong?

[DougBTX]

I think the idea behind REST is simply to keep all session data on the client, so keeping session data on the server isn't REST.

Then there are all the arguments about using HTTP as it was designed, which are all cool, but don't get too hung up on it if you don't have the browser support.

Douglas

[Dr Livingston]

Thanks for clearing that up for me. I had the suspision but just wasn't all that sure

[auricle]

From what I understand of REST, you shouldn't really be using this methodology (the use of SESSIONs) anyways, but I've need felt RESTful at any time anyways so I may be wrong?

I've been having a look at Roy Thomas Fielding's dissertation on REST (someone posted a link here recently). Thomas claims that

The problem is that a cookie is defined as being attached to any future requests for a given set of resource identifiers, usually encompassing an entire site, rather than being associated with the particular application state (the set of currently rendered representations) on the browser.
...snip...
Cookies also violate REST because they allow data to be passed without sufficiently identifying its semantics, thus becoming a concern for both security and privacy. The combination of cookies with the Referer [sic] header field makes it possible to track a user as they browse between sites.

Fielding almost ignores the problem of determining whether the current user is should be able to change the state of the resource...

DELETE /articles/23444 HTTP/1.1

Fielding continues:

The same functionality should have been accomplished via anonymous authentication and true client-side state. A state mechanism that involves preferences can be more efficiently implemented using judicious use of context-setting URI rather than cookies, where judicious means one URI per state rather than an unbounded number of URI due to the embedding of a user-id.

Presumably this means that the use of a query string to hold a session id is incorrect too. But how does one determine the identity of the user making the request? Since each state has one URL and since more than one user may be permitted to access that state, there can be no identification of the user. Now there's a security risk!

[stupidiot]

Since each state has one URL and since more than one user may be permitted to access that state, there can be no identification of the user. Now there's a security risk!

You can always use HTTP Authentication (which is extensible) in your server script to challege incoming requests.

[auricle]

You can always use HTTP Authentication (which is extensible) in your server script to challege incoming requests.

For every request? Users would love that!