SitePoint Sponsor |
|
User Tag List
Results 1 to 25 of 117
Thread: REST opinions
-
Apr 29, 2004, 09:33 #1
- Join Date
- Nov 2002
- Posts
- 841
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
REST opinions
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.
-
Apr 29, 2004, 09:52 #2
- Join Date
- Jan 2004
- Location
- Planet Earth
- Posts
- 1,764
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
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
-
Apr 29, 2004, 10:08 #3
- Join Date
- Jun 2003
- Location
- Iowa, USA
- Posts
- 3,749
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
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.
-
Apr 29, 2004, 11:46 #4
- Join Date
- Jan 2004
- Location
- Planet Earth
- Posts
- 1,764
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Ouch
-
Apr 29, 2004, 16:07 #5
- Join Date
- Sep 2003
- Location
- Glasgow
- Posts
- 1,690
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
"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.
-
May 3, 2004, 00:33 #6
- Join Date
- Jan 2004
- Location
- Oslo, Norway
- Posts
- 894
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
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
-
May 3, 2004, 02:47 #7
- Join Date
- Mar 2004
- Location
- Netherlands
- Posts
- 138
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
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.
-
May 3, 2004, 02:58 #8
- Join Date
- Mar 2004
- Location
- Netherlands
- Posts
- 138
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
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.
-
May 3, 2004, 06:03 #9
- Join Date
- Jan 2004
- Location
- Oslo, Norway
- Posts
- 894
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by meryn
http://www.sitepoint.com/forums/show...&postcount=122Dagfinn Reiersøl
PHP in Action / Blog / Twitter
"Making the impossible possible, the possible easy,
and the easy elegant" -- Moshe Feldenkrais
-
May 3, 2004, 06:46 #10
- Join Date
- Jan 2004
- Location
- Oslo, Norway
- Posts
- 894
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by meryn
Originally Posted by meryn
Dagfinn Reiersøl
PHP in Action / Blog / Twitter
"Making the impossible possible, the possible easy,
and the easy elegant" -- Moshe Feldenkrais
-
May 3, 2004, 07:29 #11
- Join Date
- Aug 2003
- Location
- USA
- Posts
- 80
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
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.
-
May 3, 2004, 07:36 #12
- Join Date
- Apr 2003
- Location
- London
- Posts
- 2,423
- Mentioned
- 2 Post(s)
- Tagged
- 0 Thread(s)
Hi.
This is off topic, but I think it deserves a warning...
Originally Posted by NativeMind
yours, MarcusMarcus Baker
Testing: SimpleTest, Cgreen, Fakemail
Other: Phemto dependency injector
Books: PHP in Action, 97 things
-
May 3, 2004, 08:05 #13
- Join Date
- Mar 2004
- Location
- Netherlands
- Posts
- 138
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
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.
-
May 3, 2004, 09:35 #14
- Join Date
- Mar 2004
- Location
- Netherlands
- Posts
- 138
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
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.
-
May 3, 2004, 10:28 #15
- Join Date
- Apr 2003
- Location
- London
- Posts
- 2,423
- Mentioned
- 2 Post(s)
- Tagged
- 0 Thread(s)
Hi.
Seems everything I post lately is off topic, but...
Originally Posted by meryn
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, MarcusMarcus Baker
Testing: SimpleTest, Cgreen, Fakemail
Other: Phemto dependency injector
Books: PHP in Action, 97 things
-
May 3, 2004, 12:33 #16
- Join Date
- Mar 2004
- Location
- Netherlands
- Posts
- 138
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
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.
-
May 4, 2004, 02:01 #17
- Join Date
- Jan 2004
- Location
- Oslo, Norway
- Posts
- 894
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by meryn
Dagfinn Reiersøl
PHP in Action / Blog / Twitter
"Making the impossible possible, the possible easy,
and the easy elegant" -- Moshe Feldenkrais
-
May 4, 2004, 02:54 #18
- Join Date
- Mar 2004
- Location
- Netherlands
- Posts
- 138
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
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.I'm glad to hear that. That post was a little offtopic anyway.
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'.
-
May 4, 2004, 03:41 #19
- Join Date
- Apr 2003
- Location
- London
- Posts
- 2,423
- Mentioned
- 2 Post(s)
- Tagged
- 0 Thread(s)
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.
Originally Posted by meryn
. You would need frames or some such to maintain state as otherwise the whole thing will be blown away by the next request. Also I thought REST was about not shipping app. code (like applets) to the browser, just document formats. 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. Definitely confused now...
Originally Posted by meryn
yours, MarcusMarcus Baker
Testing: SimpleTest, Cgreen, Fakemail
Other: Phemto dependency injector
Books: PHP in Action, 97 things
-
May 4, 2004, 04:03 #20
Originally Posted by lastcraft
Sike
-
May 4, 2004, 04:53 #21
- Join Date
- Nov 2000
- Location
- Switzerland
- Posts
- 2,479
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
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.
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.
-
May 4, 2004, 05:55 #22
- Join Date
- Apr 2003
- Location
- London
- Posts
- 2,423
- Mentioned
- 2 Post(s)
- Tagged
- 0 Thread(s)
Hi...
Originally Posted by sike
yours, MarcusMarcus Baker
Testing: SimpleTest, Cgreen, Fakemail
Other: Phemto dependency injector
Books: PHP in Action, 97 things
-
May 4, 2004, 06:02 #23
Originally Posted by lastcraft
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 ;[
-
May 4, 2004, 06:08 #24
- Join Date
- Jun 2003
- Location
- Iowa, USA
- Posts
- 3,749
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
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
-
May 4, 2004, 06:13 #25
- Join Date
- Apr 2003
- Location
- London
- Posts
- 2,423
- Mentioned
- 2 Post(s)
- Tagged
- 0 Thread(s)
Hi...
Originally Posted by HarryF
Originally Posted by HarryF
Originally Posted by HarryF
Seems to me that REST is a pattern rather than some "one true way".
yours, MarcusMarcus Baker
Testing: SimpleTest, Cgreen, Fakemail
Other: Phemto dependency injector
Books: PHP in Action, 97 things
Bookmarks