REST opinions

[auricle]

btw, i found a nice intro to REST http://naeblis.cx/rtomayko/2004/12/12/rest-to-my-wife

This is the fellow behind lesscode.org. It's not about PHP at all, but it's an entertaining and thought-provoking read.

[DougBTX]

Nice link, love this one: http://netgazette.dmv.com/November2004.html

Sums up the perspective nicely.

[BerislavLopac]

Yes, of course it's easy when you use an iterface that hides all the details. But I don't think you know what's under the hood. And if you do, you're the man.

I know pretty thoroughly the syntax of XML-RPC, and the basics of SOAP. And there's no chance in hell I will ever try to write one of those manually without a specialized tool, in any language.

[dreamscape]

Use REST if you don't care about interacting with your users or don't care about their experience... stay back in 1970-whatever.

For those of us that live in 2005 and hopefully on into the future, REST can RIP.

[DougBTX]

Use REST if you are developing for the Web, use whatever you like if you are developing for other parts of the Net.

If you care about your users, use whatever works best for your users, regardless of fashion.

Douglas

[dreamscape]

>> Use REST if you are developing for the Web

Well the problem is that REST states you must stick to the old HTTP specifications. It says you cannot use things like sessions, cookies, etc, which were created entirely in the first place because the HTTP spec had become outdated and severely lacking in certain areas.

But the Web has changed alot, regardless if the HTTP spec has or not. Interacting with your users is just as important as serving them the proper information nowdays. Alot of users want a personalized experience, and you really cannot even hope to accomplish this sticking to REST.

Like I said, stick with REST if you want to stay in 1970.

[DougBTX]

Well the problem is that REST states you must stick to the old HTTP specifications. It says you cannot use things like sessions, cookies, etc, which were created entirely in the first place because the HTTP spec had become outdated and severely lacking in certain areas.

REST is all about keeping the client's state on the client side, what do you think cookies are for?

You seem to have some strange perceptions of REST.

Douglas

[dreamscape]

REST mandates no cookies and no sessions... it dictates that there should be no state at all, period.

This is exactly why cookies and sessions were devised... to create state in an otherwise stateless environment. Cookies and sessions are anti-REST.

If it were up to REST advocates, we'd probably all still be surfing on text browsers. Wake up, the web has grown up.

REST may be alright for a Web Services API, but some of its notions are absolutely outdated and ludicrous in the modern web era.

[DougBTX]

REST mandates no cookies and no sessions... it dictates that there should be no state at all, period.

Wrong, it dictates stateless interaction, not no-state-at-all.

A quick google turned up this example:

My: I would like your phone number, please.

You: Who are you?

Me: I'm you're old buddy Frank, and I would like your phone number please.

You: Oh, well then my number is....

(from here)

The stateless part is that the server doesn't need to remember that Frank wants a phone number, everything goes in one request.

Cookies are resent on each request, so you get stateless interaction.

Douglas

[DougBTX]

Here's a post by Rasmus, a PHP guy you might say, where he mentions REST vs SOAP: http://toys.lerdorf.com/archives/33-...-Services.html

[dreamscape]

I would reckon that probably most people writing real applications, (and not theoretical or hypothetical apps), are not using REST.

[DougBTX]

I would reckon that probably most people writing real applications, (and not theoretical or hypothetical apps), are not using REST.

I would reckon that more people use REST techniques than know what REST stands for, it is based on fundamental questions of scalability, and meeting user's expectations. PHP is great for REST.

Douglas

[dreamscape]

>> it is based on fundamental questions of scalability, and meeting user's expectations

That is where I disagree... it is based on making your life (as a developer) easier. It doesn't really care about a user's experience or expectations, and in fact directly attempts to make their life more difficult. I think if you take a survey of common web users, in alot of situations, they'd expect you to remember certain things about them, which REST says is a no-no (because it makes life more complicated for the developer). REST pushes the burden of complication to the user (client).

Sure you could remember things about users with cookies, but are going to avoid sessions only to store all of their "session" information in cookies? Do you really think that is a good idea? And how is that really any different from sessions, aside from the fact that a users entire session info is now available to anyone who has access to their computer? It just seems like you'd be trying to be anti-REST without technically being anti-REST.

That example is so... not accurate with technology either... it seems to be a telephone analogy, but we have caller-id now, so the entire "who are you?" question is most likely unnecessary, especially considering the caller is an "old buddy"

>> Cookies are resent on each request, so you get stateless interaction.
Only for the purpose of creating state. Cookies are usually then used to gather further user info from the server, which REST says no to.

[arborint]

Dear dreamscape, did REST leave you for another programmer or run over your dog or something? You seem to have a very strong opinion about a useful web architectural style that no one, including you, is forced to use. It is certainly not meant to solve all web problems, yet is a useful style that can create clean architectures. I went back and read a bunch of REST web pages and I certainly do see the strictness that you seem to find regarding REST. No REST Inquisitors screaming, "He used a cookie -- burn him!" So what's the real problem with this harmless and sometimes useful style?

[Dr Livingston]

I would reckon that probably most people writing real applications, (and not theoretical or hypothetical apps), are not using REST.

True. I have not yet applied RESTful methods to my development cycle, and at the moment I have no intentions of doing so.

But in saying that if you were to take into account AJAX methodologies, then you are for most purposes, required to be RESTful. Apparantly this is due to the technology it's self, from what I read briefly a while back...

But personally I am still in doubt as to why REST effects the motivation of AJAX application development, or more to the point, why should REST effect AJAX

but are going to avoid sessions only to store all of their "session" information in cookies?

Not very pratical from our point of view, as developers, and not very pratical as the cookie can only store a limited number of bytes... And then the user can disable cookies as well.

There is a damn good reason as to why we have sessions, and that is to maintain a certain amount of state between requests, and to me REST is not as a solution, quite there yet (why I don't apply it).

[dreamscape]

>> So what's the real problem with this harmless and sometimes useful style?

It seems to me the REST methodology was designed for Web Services APIs, and I said I really don't see a problem with using it as such.

However, many people here seem to be advocating using it in Web Applications (which are different from web services), and I'm saying in an era where most people expect interactive Web Applications, REST isn't a good answer.

Let's just agree to disagree.

[arborint]

>> So what's the real problem with this harmless and sometimes useful style?

It seems to me the REST methodology was designed for Web Services APIs, and I said I really don't see a problem with using it as such.

However, many people here seem to be advocating using it in Web Applications (which are different from web services), and I'm saying in an era where most people expect interactive Web Applications, REST isn't a good answer.

I don't know who the "many people" are, but it really is a matter of style and approach. I really don't know anyone who is a REST purist, but I can see in general how a RESTful approach to the web can be beneficial. The sense I get is that there is a lot of state information that can be maintained in a REST style. And doing those things that work well in the REST style can simplify both the code and the interface. Certainly being aware of when you use cookies and sessions, and making conscious design decisions about what use you makes sense.

Let's just agree to disagree.

Again, I don't think we disagree because we are talking about options. There are certainly programmers who take a more RESTful approach that you might. So there is no disagreement that the options are there, just which choices one chooses to make.