SitePoint Sponsor

User Tag List

Page 1 of 5 12345 LastLast
Results 1 to 25 of 117

Thread: REST opinions

Hybrid View

  1. #1
    SitePoint Guru
    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.

  2. #2
    Non-Member
    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

  3. #3
    eschew sesquipedalians silver trophy sweatje's Avatar
    Join Date
    Jun 2003
    Location
    Iowa, USA
    Posts
    3,749
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Selkirk
    • GET requests must have no side effects.
    • No sessions.
    • No cookies.
    Ouch... 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.

  4. #4
    Non-Member
    Join Date
    Jan 2004
    Location
    Planet Earth
    Posts
    1,764
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Ouch
    Hey!! That's my trademark you've gone and nicked

  5. #5
    simple tester McGruff's Avatar
    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.

  6. #6
    SitePoint Guru dagfinn's Avatar
    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

  7. #7
    SitePoint Zealot
    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.

  8. #8
    SitePoint Guru dagfinn's Avatar
    Join Date
    Jan 2004
    Location
    Oslo, Norway
    Posts
    894
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by meryn
    For example, the HTTP verb POST:
    ....
    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

  9. #9
    SitePoint Zealot
    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.

  10. #10
    SitePoint Guru dagfinn's Avatar
    Join Date
    Jan 2004
    Location
    Oslo, Norway
    Posts
    894
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by meryn
    REST is not a religion
    That's important information which is not totally clear from the introductory descriptions.
    Quote Originally Posted by meryn
    On a side node: I'm convinced that you can build advanced websites in a RESTful way, if you can live with HTTP authentication.
    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

  11. #11
    SitePoint Enthusiast NativeMind's Avatar
    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.

  12. #12
    ********* Victim lastcraft's Avatar
    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...

    Quote Originally Posted by NativeMind
    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.
    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

  13. #13
    SitePoint Zealot
    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.
    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).

    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.

  14. #14
    ********* Victim lastcraft's Avatar
    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...

    Quote Originally Posted by meryn
    I don't like to work for clients who are not willing to pay a little extra for quality.
    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

  15. #15
    SitePoint Guru dagfinn's Avatar
    Join Date
    Jan 2004
    Location
    Oslo, Norway
    Posts
    894
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by meryn
    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).

    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.
    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

  16. #16
    SitePoint Zealot
    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.
    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.

    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.

  17. #17
    SitePoint Zealot
    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.
    '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.

    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.

  18. #18
    SitePoint Zealot
    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.
    Allright then. 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?
    More complex internals:
    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'.

  19. #19
    ********* Victim lastcraft's Avatar
    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.

    Quote Originally Posted by meryn
    If you're targetting browsers, your only option for this is javascript.
    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. 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...

    Quote Originally Posted by meryn
    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'.
    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?

    yours, Marcus
    Marcus Baker
    Testing: SimpleTest, Cgreen, Fakemail
    Other: Phemto dependency injector
    Books: PHP in Action, 97 things

  20. #20
    SitePoint Zealot sike's Avatar
    Join Date
    Oct 2002
    Posts
    174
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by lastcraft
    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?

    yours, Marcus
    what do you mean exactly ? a javascript unit tester? or a javascript ui for the unit tester ?

    Sike

  21. #21
    ********* Victim lastcraft's Avatar
    Join Date
    Apr 2003
    Location
    London
    Posts
    2,423
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Hi...

    Quote Originally Posted by sike
    what do you mean exactly ? a javascript unit tester? or a javascript ui for the unit tester ?
    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

  22. #22
    SitePoint Zealot sike's Avatar
    Join Date
    Oct 2002
    Posts
    174
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by lastcraft
    Hi...



    A JavaScript UI. There are already a couple of JSUnits out there (I've not used them).

    yours, Marcus
    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 ;[

  23. #23
    SitePoint Zealot
    Join Date
    Mar 2004
    Location
    Netherlands
    Posts
    138
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by lastcraft
    @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.

  24. #24
    SitePoint Guru dagfinn's Avatar
    Join Date
    Jan 2004
    Location
    Oslo, Norway
    Posts
    894
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by meryn
    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?
    Dagfinn Reiersøl
    PHP in Action / Blog / Twitter
    "Making the impossible possible, the possible easy,
    and the easy elegant"
    -- Moshe Feldenkrais

  25. #25
    SitePoint Guru dagfinn's Avatar
    Join Date
    Jan 2004
    Location
    Oslo, Norway
    Posts
    894
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by meryn
    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.
    Dagfinn Reiersøl
    PHP in Action / Blog / Twitter
    "Making the impossible possible, the possible easy,
    and the easy elegant"
    -- Moshe Feldenkrais


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •