SitePoint Sponsor

User Tag List

Page 3 of 5 FirstFirst 12345 LastLast
Results 51 to 75 of 117

Thread: REST opinions

  1. #51
    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 auricle
    For every request? Users would love that!
    Browsers cache the HTTP authentication info and re-supply it every request. Basically equivalent to a session cookie.

    http://httpd.apache.org/docs/1.3/how...tml#basicworks

    Because the HTTP protocol is stateless, each request will be treated in the same way, even though they are from the same client. That is, every resource which is requested from the server will have to supply authentication credentials over again in order to receive the resource.

    Fortunately, the browser takes care of the details here, so that you only have to type in your username and password one time per browser session - that is, you might have to type it in again the next time you open up your browser and visit the same web site.
    Jason Sweat ZCE - jsweat_php@yahoo.com
    Book: PHP Patterns
    Good Stuff: SimpleTest PHPUnit FireFox ADOdb YUI
    Detestable (adjective): software that isn't testable.

  2. #52
    SitePoint Evangelist
    Join Date
    Jun 2003
    Location
    Melbourne, Australia
    Posts
    440
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by sweatje
    Browsers cache the HTTP authentication info and re-supply it every request. Basically equivalent to a session cookie.
    Whoops. Left myself wide open on that one!

    In a way, this reminds me of recent argument about Goodle pre-fetching and the correct and incorrect uses of GET and POST methods. A number of writers in the blogosphere noted that submit buttons are less stylable than links. HTTP authentication strikes me as even more like that. The authentication dialog cannot be styled at all.

    Those who prize security above all else won't care. Those who insist on aesthetic control won't accept this method. For many, the choice would be a hard one.
    Zealotry is contingent upon 100 posts and addiction 200?

  3. #53
    SitePoint Member
    Join Date
    Oct 2004
    Location
    malaysia
    Posts
    18
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by auricle
    Those who prize security above all else won't care. Those who insist on aesthetic control won't accept this method. For many, the choice would be a hard one.
    When we realize the correct semantic usage of HTTP methods and REST can make our life much easier in maintainance, and boost up the system accessbility for all level of users. Maybe the little square auth dialog doesn't really hurts.

  4. #54
    throw me a bone ... now bonefry's Avatar
    Join Date
    Nov 2004
    Location
    Romania
    Posts
    848
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Oh common. When all the world is moving to commponent based programming, you guys are talking about REST. So what the HTTP protocol is stateless ? I still don't get it why we should not tweak that.

    Has anyone here tried ASP.NET ? I know I did. And although I don't use it (being M$'s stuff) it really rings a bell. We are moving towards rich internet applications, were "stateless" cannot remain stateless.

  5. #55
    SitePoint Guru
    Join Date
    Oct 2001
    Posts
    656
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    When all the world is moving to commponent based programming, you guys are talking about REST.
    Sure, when everybody is doing it, it can't possibly be wrong, right....?

  6. #56
    SitePoint Guru 33degrees's Avatar
    Join Date
    May 2005
    Posts
    707
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by auricle
    The authentication dialog cannot be styled at all.
    Which is not an issue from a graphic design perspective, since it's not actually part of the page... it's really those big grey buttons that are problematic, as well as scroll bars (ms specific css styles notwithstanding).

  7. #57
    SitePoint Wizard DougBTX's Avatar
    Join Date
    Nov 2001
    Location
    Bath, UK
    Posts
    2,498
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by 33degrees
    it's really those big grey buttons that are problematic,
    Looks fine on my Mac

    Quote Originally Posted by bonefry
    When all the world is moving to commponent based programming, you guys are talking about REST.
    This thread is about a stateless server, not a stateless client. Rich (thick) clients can keep their own state more easily than thin ones, they are a good fit for REST.

    Douglas
    Hello World

  8. #58
    SitePoint Addict
    Join Date
    May 2003
    Location
    The Netherlands
    Posts
    391
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I like standards and embrace them whenever possible, but I still fail to see the real benefit of REST, so I hope you guys don't mind to shed some light on this one for me.

    Quote Originally Posted by meryn
    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 hange the /articles/ resource. The interpretation of a resource can be as broad as you want...
    Could you explain how does that differ from using verbs in URLS?
    What would be the benefit of using http://somesite.com/articles/?action=add instead of http://somesite.com/articles/add/?

    Quote Originally Posted by meryn
    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.
    How would you handle then any non-CRUD operation? Or does it come down to "any non-CRUD operation relates to a CRUD operation"?

    Quote Originally Posted by MiiJaySung
    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).
    Wouldn't an anchor link always be a GET request??

    Quote Originally Posted by stupidiot
    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).
    How is that "cleaner" than relying only in the server and using the client side only as a mean to support server side functionality?

    Quote Originally Posted by stupidiot
    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.
    Could you elaborate on how a resource is more manageable through one unique URL identifier (for all possible actions on that resource) as opposite to one URL for each action on a cetain resource?
    For example:
    http://somesite.com/article/123/add/
    http://somesite.com/article/123/edit/
    http://somesite.com/article/123/delete/

    Thank you in advance.

  9. #59
    throw me a bone ... now bonefry's Avatar
    Join Date
    Nov 2004
    Location
    Romania
    Posts
    848
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    This whole REST design philosophy seems like having sex without orgasm i.e just for procreation. Afterall that's why sex was invented

    Sure, let's drop all things that made our life easier just to have separation of concerns. And yet, I haven't seen anybody talk about aspect oriented programming.

    Also, what about AJAX ? You definitelly need a session to use ajax components usable.

  10. #60
    SitePoint Guru BerislavLopac's Avatar
    Join Date
    Sep 2004
    Location
    Zagreb, Croatia
    Posts
    830
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by bonefry
    Sure, let's drop all things that made our life easier just to have separation of concerns. And yet, I haven't seen anybody talk about aspect oriented programming.

    Also, what about AJAX ? You definitelly need a session to use ajax components usable.
    You forgot patterns, and refactoring, and blogs.

    Here. Now this thread is fully buzzword-compliant.

  11. #61
    throw me a bone ... now bonefry's Avatar
    Join Date
    Nov 2004
    Location
    Romania
    Posts
    848
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by BerislavLopac
    You forgot patterns, and refactoring, and blogs.

    Here. Now this thread is fully buzzword-compliant.
    No, not yet. Ruby.

    That's better .

  12. #62
    SitePoint Addict
    Join Date
    May 2003
    Location
    The Netherlands
    Posts
    391
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by bonefry
    Also, what about AJAX ? You definitelly need a session to use ajax components usable.
    Sessions could be emulated by using $_SERVER['PHP_AUTH_USER'] as an identifier and map user preferences, or whatever data you'd like to persist, to it, right?

  13. #63
    throw me a bone ... now bonefry's Avatar
    Join Date
    Nov 2004
    Location
    Romania
    Posts
    848
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by nacho
    Sessions could be emulated by using $_SERVER['PHP_AUTH_USER'] as an identifier and map user preferences, or whatever data you'd like to persist, to it, right?
    No, not really. An emulated session it's still a session (I don't know why, but sex comes in my mind again). That's not Resin anymore where the whole ideea is that "http is stateless" and that "persistence is bad". So no, you can't do it. Am I wrong ?

  14. #64
    SitePoint Addict
    Join Date
    May 2003
    Location
    The Netherlands
    Posts
    391
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Certainly, a session is still a session, but I understood that according to the REST philosophy sessions are bad because they "ignore" certain feautures of the HTTP protocol, bypassing it, instead of letting it control access as it was supposed to do, not because of a session being a way of persisting data.

    From the link sweatje had posted (apache docs)

    The client browser caches the username and password that you supplied, and stores it along with the authentication realm, so that if other resources are requested from the same realm, the same username and password can be returned to authenticate that request without requiring the user to type them in again. This caching is usually just for the current browser session, but some browsers allow you to store them permanently, so that you never have to type in your password again.
    So how is this more RESTful than using your own custom sessions??

  15. #65
    throw me a bone ... now bonefry's Avatar
    Join Date
    Nov 2004
    Location
    Romania
    Posts
    848
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by nacho
    Certainly, a session is still a session, but I understood that according to the REST philosophy sessions are bad because they "ignore" certain feautures of the HTTP protocol, bypassing it, instead of letting it control access as it was supposed to do, not because of a session being a way of persisting data.
    If I understood corectly, sessions are bad because it makes pages to have content based on the current session, and not on values submited through GET/POST. That means for example, if you save a link in your bookmarks, and return at a later time, that page may not be available if it depends on the session. And to recreate it, the user must follow certain steps to recreate the session.

    And again, no, I don't think your sollution is correct. A session couldn't be evil because of the way the session ID is passed from one page to another.

  16. #66
    SitePoint Addict
    Join Date
    May 2003
    Location
    The Netherlands
    Posts
    391
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    To me it is still confusing. If REST allows you to make use of the browser cache to store username and password for the current session, what is the difference with using any other means of cache?

  17. #67
    throw me a bone ... now bonefry's Avatar
    Join Date
    Nov 2004
    Location
    Romania
    Posts
    848
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by nacho
    To me it is still confusing. If REST allows you to make use of the browser cache to store username and password for the current session, what is the difference with using any other means of cache?
    I am confused too .

  18. #68
    SitePoint Addict
    Join Date
    May 2003
    Location
    The Netherlands
    Posts
    391
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Shall we give it a REST then?

  19. #69
    SitePoint Zealot
    Join Date
    Mar 2004
    Location
    Netherlands
    Posts
    138
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    "REST is defined by four interface constraints: identification of resources; manipulation of resources through representations; self-descriptive messages; and, hypermedia as the engine of application state." (from Roy Fielding's dissertation on REST)

    Whatever you choose as URL for a resource doens't matter architecture-wise, because URLs are be opaque to the client. This means a client shouldn't be constructing URLs on its own, but only follow links or construct a query string based on the instructions in (for example) <form method="get"></form>.

    The only thing that's important here is to not confuse a verb in a url (be it in the query string or in the path) as an instruction for the server. The only instructions a server should follow (in case of HTTP) are GET, PUT, POST or DELETE. Each of them has specific semantics.

    GET should never change something on the server. It should be side-effect free.
    POST basically means "process the following message", without constraints on side-effects, so POST can be used to add, change or delete something on the server.
    PUT and DELETE (look them up in the HTTP spec if you want to) also alter the state of the server, but are more specific in there semantics then POST. This comes handy if you want to explain API behaviour, because everyone who knows HTTP can have a decent expectation what these verbs do.

    How would you handle then any non-CRUD operation? Or does it come down to "any non-CRUD operation relates to a CRUD operation"?
    POST just means "process this message" so this can be used for any sort of operation. (If the operation doesn't change anything on the server (just returns the result of a calculation or something), you should use GET, because then the client can be confident that he can reissue the request without doing any harm.)

    The disadvantage using POST is that it is completely generic. The client (and the client author) hasn't got the faintest clue of what the effects of the request can be. In browser, this comes forth in the dialog box you see whenever you go back to a page that resulted from a previously issued POST request. The browser warns you that reissuing the request could practically do anything.

    Therefore, to make your API more comprehensible and more predictable, you can try to distill parts of your (generic) POST operations into more specific PUT and DELETE operations. This facilitates interoperation with clients, because they can make assumptions about the effects of requests using those operations. (for example: if a client just issued a DELETE on a url, it can assume that after that, the resource at that URL is gone)

    This whole REST design philosophy seems like having sex without orgasm
    I don't understand this analogue, but if you mean this 'theoretical' discussion doesn't matter, you're wrong. It's very relevant to any web application developer.

    The principles of REST form the architectural basis for the WWW.

    The fact that search engines can crawl the web is made possible by the semantics constraints of GET. A search engine assumes (correctly) that it can follow any link it encounters, so it can add it to it's index. Otherwise a search engine would have to read (and understand!) an API specification for each site/application/url it tries to index. How on earth would a search engine even determine the 'authority' of a domain, to know where to find such API specification? There should then be standards (or a protocol) for that...

    Recently there has been much fuss about the Google Accelerator, because it 'broke' web applications. This wouldn't have happened if the developers of those applications wouldn't have used GET to delete or change stuff. Technically, it was THEIR fault, not Google's. They violated the HTTP protocol on port 80. That's just like violating traffic rules on the public road.

    IMO, knowing 'enough' about HTTP (never use GET for operations that alter the state of the server) should be required knowledge for all web application developers. I would support a Webdeveloper License, just like a Drivers License. You'd have to know the basic rules before you can get one, and you can lose it if you violate the rules too often.
    Last edited by meryn; Jul 25, 2005 at 04:01. Reason: minor

  20. #70
    SitePoint Wizard DougBTX's Avatar
    Join Date
    Nov 2001
    Location
    Bath, UK
    Posts
    2,498
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by nacho
    To me it is still confusing. If REST allows you to make use of the browser cache to store username and password for the current session, what is the difference with using any other means of cache?
    But which server is the session on?

    Some solutions redirect your request so that you always go to the same server, other solutions are to have a shared sessions server which only does sessions.

    REST answers that by not putting the session on the server, you put it on the client instead, because the client always knows who they are.


    Douglas
    Hello World

  21. #71
    throw me a bone ... now bonefry's Avatar
    Join Date
    Nov 2004
    Location
    Romania
    Posts
    848
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by DougBTX
    REST answers that by not putting the session on the server, you put it on the client instead, because the client always knows who they are.
    Isn't that a little dangerous ? Also, we need component based programming for RIAs and until we don't have a standard to that (flex/laszlo/xul/xaml) so the components can be easilly developed and take care for themselfs, how are we going to handle it without a session. Also, from what I understand, cookies too are bad.

    I know it's more about the true purpose of GET and POST. But the affirmation "http is stateless and should stay that way" bothers me.

  22. #72
    throw me a bone ... now bonefry's Avatar
    Join Date
    Nov 2004
    Location
    Romania
    Posts
    848
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by meryn
    I don't understand this analogue, but if you mean this 'theoretical' discussion doesn't matter, you're wrong. It's very relevant to any web application developer.

    The principles of REST form the architectural basis for the WWW.
    You are right about following standards. But I don't think it's fair to say "WWW should stay that way". Like all things, WWW must evolve.

  23. #73
    SitePoint Wizard DougBTX's Avatar
    Join Date
    Nov 2001
    Location
    Bath, UK
    Posts
    2,498
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by bonefry
    Isn't that a little dangerous?
    Much the same as any other cookie based session IDs: ie, not very safe but seems to work for most people. If you want something secure, I think we have to assume SSL anyway.

    Quote Originally Posted by bonefry
    so the components can be easilly developed and take care for themselfs
    If you are talking about Flash interfaces, then it might be possible to treat an open socket as a session. You are getting away from HTTP, XMLSocket won't connect to port 80 for a start. How does Communication Server handle these things?

    Douglas
    Hello World

  24. #74
    SitePoint Evangelist
    Join Date
    Jun 2003
    Location
    Melbourne, Australia
    Posts
    440
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by bonefry
    A session couldn't be evil because of the way the session ID is passed from one page to another.
    Fielding suggests that it is because a particular state (on or of the server) has more than one URL.

    Quote Originally Posted by meryn
    GET should never change something on the server. It should be side-effect free.
    POST basically means "process the following message", without constraints on side-effects, so POST can be used to add, change or delete something on the server.
    PUT and DELETE (look them up in the HTTP spec if you want to) also alter the state of the server, but are more specific in there semantics then POST. This comes handy if you want to explain API behaviour, because everyone who knows HTTP can have a decent expectation what these verbs do.
    I think this presents a problem for web developers (and designers, who know that aesthetics play a large part in the perceptions of the great unwashed). Let's suppose that one can, by whatever means, restrict a page which allows the deleting of resources to a person who has permission to do so. How does one render a link which, when clicked, causes the browser to issue a DELETE? Or, when adding a resource, a PUT? As far as I know, the command line and something like the Mozilla plug-in livehttpheaders are the only ways to issue PUT or DELETE, and are not anything you can place in a web page. Or did I miss something in the last five years?

    It wouldn't surprise me to find that this is a widespread objection to the strict implementation of REST.
    Zealotry is contingent upon 100 posts and addiction 200?

  25. #75
    SitePoint Zealot
    Join Date
    Mar 2004
    Location
    Netherlands
    Posts
    138
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Let's suppose that one can, by whatever means, restrict a page which allows the deleting of resources to a person who has permission to do so.
    That doesn't free you from your 'obligation' to adhere to the HTTP protocol (on port 80). This was the exact problem with Google Accelerator: The application authors never though about an automated agent trying to preload links in their html. Search engines never found those pages, because they're password protected.

    How does one render a link which, when clicked, causes the browser to issue a DELETE? Or, when adding a resource, a PUT?
    GET, PUT, POST and DELETE requests can be issued through xmlhttprequest (which forms the basis for AJAX). If you don't want dependence on xmlhttprequest, you can use a form post as fallback. You can post a form wich contains an update or delete request with javascript. If you don't want dependence on javascript, you can fall back on a the good old submit button.

    This means clients without javascript support get to see a submit button instead of a link. Although you may not want that, this is - technically speaking - by far the best way.

    One could argue wether using links to issue resource altering requests is good practice. In any case, it's good to make a clear distinction in presentation of normal 'navigational' links and links wich trigger such actions.


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
  •