| SitePoint Sponsor |
Just curious what everyone thinks of REST:
Architectural Styles and the Design of Network-based Software Architectures
REST wiki
REST seems to have found a home in the web services domain. Is there anything there that we can apply to user interface oriented web applications?
REST mandates that are particularly troubling for end user oriented web applications:
- GET requests must have no side effects.
- No sessions.
- No cookies.
I'll be the first to admit my understanding of REST is limited.
Likewise
Though not the time, nor the inclination to learn more about it just now. Too much information all at once is not good for the brain cells as I see it
Ouch...Originally Posted by Selkirk
Was planning to look into this more, but that kind of puts a crimp on things.
Jason Sweat ZCE - jsweat_php@yahoo.com
Book: PHP Patterns
Good Stuff: SimpleTest PHPUnit FireFox ADOdb YUI
Detestable (adjective): software that isn't testable.
Hey!! That's my trademark you've gone and nickedOuch
"GET can have no side effects" etc..
Does that mean read-only requests via GET (ie no data source manipulating)? That & sessions & coolies makes life very difficult for dynamic websites. We'll need a new protocol - carrier pigeons?
It's tempting to say Rest in Peace - the artice opener "Since 1994.." is perhaps significant.
However, it deserves more than this flippant response.
My understanding of REST is limited, but this is what I've got right now: REST is a way of making sure the resources you create on the Web are easily available and re-usable to anyone, anywhere. If and when that's the problem you're trying to solve, or your highest priority, then REST may be a good idea, but I have a feeling you may only need part of it anyway.
Dagfinn Reiersøl
PHP in Action / Blog / Twitter
"Making the impossible possible, the possible easy,
and the easy elegant" -- Moshe Feldenkrais
I've read a lot about REST, and I really like the REST philosophy. Basically, it's a detailed description how the web works (or should work).
Because HTTP is an open protocol, and no central organisatisation controls the web, one can use HTTP however he/she likes. But to get the most out of the web architecture, you need to understand how the designers intended the web to be.
For example, the HTTP verb POST:
POST was *intended* for use by data processing applications (for example: posting a forum post using a form). Browsers keep this in mind, and warn you before resubmitting a POST request.
Some people use POST for search forms. This has two disadvantages:
- when browsing, and going back afterwards, the user is asked wether he wants to resubmit the form data or not... A little annoying, because the search results won't change anyway.
- the user can not bookmark the search result.
Using POST for search forms unRESTful by REST-guru's, which means they think it violates the principles of the web.
The same can be said for using GET for a request that changes something on the server. For example: an unsubscribe link. The HTTP specification dictates that GET requests should have no side-effects. A RESTful way to make an unsubcribe option is to make the GET request display a confirmation message, containing a form that that the user can POST to the server to confirm his action.
If you care about good software design you should pay attention to your HTTP interface as well, and for this you need to learn the HTTP specs and REST.
REST is not a religion, so no one says that you're a sinner if you use sessions or cookies. REST advocates say that using cookies and sessions hurts application interoperability, and I think that most experienced PHP developers agree to this.
Cookies and sessions are unRESTful, so you should avoid them as much as possible. However, if your application requirements can only be met using these techniques, it won't hurt to try to stick to the other recommendations.
On a side node: I'm convinced that you can build advanced websites in a RESTful way, if you can live with HTTP authentication.
Yes, that's a valid point, and it seems to be the same point that i arrived at independently (or at least without thinking of the connection to REST) in the MVCP thread:
http://www.sitepoint.com/forums/show...&postcount=122
Dagfinn Reiersøl
PHP in Action / Blog / Twitter
"Making the impossible possible, the possible easy,
and the easy elegant" -- Moshe Feldenkrais
That's important information which is not totally clear from the introductory descriptions.
If it is possible, the next question is does it cost more and is it worth the cost.
Dagfinn Reiersøl
PHP in Action / Blog / Twitter
"Making the impossible possible, the possible easy,
and the easy elegant" -- Moshe Feldenkrais
REST is the poor man's SOAP. If you ask any REST person why they use REST over SOAP and 9 times out of 10 they'll say because it's easy, or because it has less overhead.
Now I assert that SOAP is easy [with toolkits], and any overhead you take from parsing the extra XML in SOAP you save in maintainability and extensability. Now to break down those two buzzwords:
REST doesn't enjoy the same automatic properties that SOAP does with WSDL. With WSDL you know exactly where a service is, and how it operates. Also WSDL is often used to generate stub code in multiple languages (java/c++/php, etc).
REST does not enjoy the extensibility of SOAP... what if you want to cut out the middle man (HTTP) and run over pure TLS or TCP? What if you want to start doing multi-mime attachments or add things like xml headers that specify cookie/session information.
Now, I know I make it out like anyone using REST is a fool for not using SOAP, but the reality is that the use cases for a good portion of web development is in favor of REST. If you are a small business, or have a small set of use cases, and you don't care about buzzwords, REST is probably just fine for providing a very simple service. Arguably you could do the same thing with SOAP, but you know HTTP and you know enough XML to exchange a couple messages and that is fine with you.
At work, we build enterprise application servers with multiple end points. Our app servers run a SOAP web service (usually Apache axis), and the end points range in operating systems and programming languages so we have SOAP to ensure interoperability and rapid development between all components.
There are a ton of SOAP(+WSDL) tools/development environments/toolkits/testing suites available that really makes it a lot easier than everyone first asumed.
Hi.
This is off topic, but I think it deserves a warning...
If you control the system (intranet/extranet) then fine. You are opening a huge can of support worms if you make your service public.
yours, Marcus
Marcus Baker
Testing: SimpleTest, Cgreen, Fakemail
Other: Phemto dependency injector
Books: PHP in Action, 97 things
I believe that there's more to software development than just cost relative to the (personal) profit it generates. I want to develop software that not only meets the specifications, but it must also behave nicely (conforming to standards, not breaking ethics and sometimes aesthetically pleasing).the next question is does it cost more and is it worth the cost.
Personally, I'm convinced that extra attention given to an architecture pays of in the long run. That doesn't mean that I will profit from it, but someone will profit from it. It could be my client, their employees or maybe their clients. I'm proud of delivering quality; or at least, trying the best I can.
I don't like to work for clients who are not willing to pay a little extra for quality.
SOAP is essentially a messaging protocol which can be tunnled over HTTP. By using SOAP, you throw away almost all the functionality provided by HTTP. For example, SOAP only uses POST, so you throw away the other verbs.REST is the poor man's SOAP. If you ask any REST person why they use REST over SOAP and 9 times out of 10 they'll say because it's easy, or because it has less overhead.
There's nothing bad with tunneling perse, but it does mean that in the future there'll be two different webs. One with SOAP webservices (tunneled over HTTP) and one with pure HTTP services (basically the whole web (as indexed by google, etc)).
I think that the name 'web services' for SOAP services is misleading, because they can't be accessed like the rest of the web. I believe they call it web services only for marketing purposes... just like Netscape called ECMA-script JavaScript to ride the Java wave in that time.
Last edited by meryn; May 3, 2004 at 12:18.
Hi.
Seems everything I post lately is off topic, but...
Check out the Poppendeick book (Lean Software Development) regarding the "value chain". In fact you are going to profit from it as long as your clients do and they have a relation with you. It is an excellent book in any case.
Regarding the statelessness of GET requests I take it REST still allows some form of POST request (from what little I read of the thesis - good link BTW). If so then if the client makes a successful log in POST they could be delivered to a resource that has "secret" links, say with an access key added. As each subsequent request from within this "realm" would contain this unique key they would be separate GET requests. The timeout on the key would not be due to any side effects of the GET requests. The resource could be cached, etc, as there is still a one to one map from request to unique resource. Security would be an issue if the requests were sniffed. I guess that is what the tunnelling is for.
yours, Marcus
Marcus Baker
Testing: SimpleTest, Cgreen, Fakemail
Other: Phemto dependency injector
Books: PHP in Action, 97 things
'Logging in' doesn't really exist in the REST world. REST is based on stateless client server interaction, so there is no such thing as a session. Each request is authenticated independently of others.If so then if the client makes a successful log in POST they could be delivered to a resource that has "secret" links, say with an access key added. As each subsequent request from within this "realm" would contain this unique key they would be separate GET requests.
POST is only used to trigger a change/action on the resource specified in the URL. (for example: posting a form to a form handler)
Browsers have built in support for HTTP authentication, and allow a user to 'log in' to a site by saving the username and password they entered for them. At the server side, it makes no difference.
As for security: You could use HTTP Digest Authentication or HTTPS.
What you're saying is perfectly justified from my use of the word "cost", but that wasn't actually what I meant. I was thinking of cost in a much broader sense than short-term financial. Satisfying the demands of REST may lead to a better architecture seen from outside the application, but if it leads to a more cumbersome and complex, less maintainable architecture internally (or worse, a less satisfactory experience for the user), is it worth it? It's a tradeoff depending on what your requirements are.
Dagfinn Reiersøl
PHP in Action / Blog / Twitter
"Making the impossible possible, the possible easy,
and the easy elegant" -- Moshe Feldenkrais
Allright then.What you're saying is perfectly justified from my use of the word "cost", but that wasn't actually what I meant. I was thinking of cost in a much broader sense than short-term financial.
More complex internals:Satisfying the demands of REST may lead to a better architecture seen from outside the application, but if it leads to a more cumbersome and complex, less maintainable architecture internally (or worse, a less satisfactory experience for the user), is it worth it?
Implementing a HTTP interface is quite easy. If you use the standard URL to filesystem mapping of apache (or most other webservers) the only thing you need to do is write a script that handles each HTTP method or return http statuscode 405 (method not allowed) if your script doesn't support a certain method.
I think that most complexity in web application has to do with keeping session state. In a REST based application, all client state must be kept on the client. If you're targetting browsers, your only option for this is javascript. You can keep set some session information in a cookie, and use javascript to change the user interface based on the contents of the cookie. The server should ignore the cookie.
I think it's a shame that there are so few advanced developers who know JavaScript well. Personally, I have a preference to keep everything in PHP, just because I know the language and features much better.
I think a better cooperation between JavaScript developers and PHP developers would be very healthy, and will create much better applications than can be achieved with PHP alone.
It's easy to find someone who can do some copy-paste javascripting, but it's very hard to find someone who can think in terms of a 'system' or an 'architecture'.
Hi...
Judging by the way everyone keeps going off topic I can assume that we all know next to nothing about REST, yes
@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
Agree totally. The only PHP developer I know with a strong JavaScript affinity, writing applications, is Wolfram Kreisling (PEAR tree stuff). I am going to have to tackle it with Jason when I finally get around to the SimpleTest GUI. Anyone know of a JavaScript guru who wants to help write a unit tester?It's easy to find someone who can do some copy-paste javascripting, but it's very hard to find someone who can think in terms of a 'system' or an 'architecture'.
yours, Marcus
Marcus Baker
Testing: SimpleTest, Cgreen, Fakemail
Other: Phemto dependency injector
Books: PHP in Action, 97 things
what do you mean exactly ? a javascript unit tester? or a javascript ui for the unit tester ?
Sike
My take of REST, which is not based on a full understanding, is it's significant for PHP particuraily when it comes to URL design. Some random thoughts;
One caveat, I believe, is avoiding the use of verbs in the URL, using nouns instead e.g.;
http://site.com/articles/1 << (nouns only)
http://site.com/articles/my_article << (nouns only)
http://site.com/articles/view/my_article << ("bad" - contains a verb)
Now if you want to edit / delete article 1, you would POST to the same URL e.g. http://site.com/articles/1
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.
As to avoiding sessions / cookies - if you use HTTP authentication I guess you don't really need them. Guess the message there is "use what HTTP already does" (or whichever protocol you are working with) as opposed to implementing new layers which reproduce what's already there. Of course HTTP authentication can be ugly from an end use point of view but is easy to manage when you're writing an HTTP client.
What are the benefits of applying REST to PHP apps; (some guesses)
1. A single URL could deliver many content types (HTML,XHTML,PDF,XML,SOAP etc.) and using Mime "negotiation" a server could choose the best format for the client. Question - if a client can support many content types, how does it instruct the server what type it would prefer? ZVON do this using the GET variable "mime" (e.g. this vs this).
2. Indexing a site could become easier - because every URL is a noun only, you should be able to index everything. From there the index can be published in a form that's easy for a program (rather than just a human) to explore.
3. Caching dynamic content could become easier. The URL becomes a cache indentifier and also, to some extent, indentifies dependancies e.g. if I update "http://site.com/articles/1#comments" then the caches for "http://site.com/articles/1" and "http://site.com/articles" probably need updating as well.
I think that's a simplistic view. In fact the SOAP specs had to be revised as a result of REST, after they realised they'd made a major oversight, hence "document-style" SOAP, vs the RPC-style where a single URL could be used to perform multiple procedures.REST is the poor man's SOAP. If you ask any REST person why they use REST over SOAP and 9 times out of 10 they'll say because it's easy, or because it has less overhead.
Hi...
A JavaScript UI. There are already a couple of JSUnits out there (I've not used them).
yours, Marcus
Marcus Baker
Testing: SimpleTest, Cgreen, Fakemail
Other: Phemto dependency injector
Books: PHP in Action, 97 things
hey,
i am already using SimpleTest and thought about implementing a tree like result view but then read a news on your page that you were about doing it yourself and decided to wait and see if your solution works for me.
so maybe i should stick to my orignal plan and send you my results ?
may take a few days...
Sike
now im off to my dentist ;[
I have not worked with it for a couple of months, but everyone could take a look at the webunit_reporter.php in the simpletest/ui directory. The issue I had not yet resolved was how to make sure ui subdirectory was available in the webroot somewhere. You could override this by specifying a path as a parameter to the webunit_reporter when instanciating it, otherwise it assumes that simpletest is the parrent directory and uses the relative path of ../ui/ to get there.
Jason
Hi...
You could just use the new name like a Wiki.
Somer other problems: HTTP authentication is still rather poorly specified with respect to realms and does not carry from host to host (single sign on). It is also poorly implemented in browsers which usually only have basic authentication. This requires HTTPS to be secure.
I am intrigued to know why they didn't just take this from the accepts header a'la Apache. Is it because it places too much burden on the client? 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.
Seems to me that REST is a pattern rather than some "one true way".
yours, Marcus
Marcus Baker
Testing: SimpleTest, Cgreen, Fakemail
Other: Phemto dependency injector
Books: PHP in Action, 97 things
Posting Permissions
Bookmarks