SitePoint Sponsor

User Tag List

Page 2 of 5 FirstFirst 12345 LastLast
Results 26 to 50 of 117

Thread: REST opinions

  1. #26
    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.

  2. #27
    SitePoint Zealot
    Join Date
    Mar 2004
    Location
    Netherlands
    Posts
    138
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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.
    You don't need a new URL for that. Just POST the representation of the new article to http://site.com/articles/ .

  3. #28
    SitePoint Zealot
    Join Date
    Mar 2004
    Location
    Netherlands
    Posts
    138
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Question - if a client can support many content types, how does it instruct the server what type it would prefer?
    HTTP has a mechanism for this called content negotiation. It would be a nice browser feature to be able to alter the mimetype preferences (either globally or for a specific resource). Currenty, such a feature isn't available. This means that if you want to provide users with such functionality, you must code it yourself like is done by ZVON...

    There's one problem that keeps coming up:
    There are no browsers that support the powerful features of HTTP. It's the fault of the browser makers that we know have to develop our own solutions... with incompatible implementations.

    This means that REST is better in theory than in practice. Lack of tool support...

  4. #29
    ********* 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
    so maybe i should stick to my orignal plan and send you my results ?
    It is a lot more complicated than that and sadly I haven't had much chance to contribute myself. You should chat to Jason and if you are on the same lines maybe we should sign you up. The decent UI was planned for version 1.1 originally, but the version 1 release has been delayed a bit tying up loose ends.

    Post a note to the support forum as this is a bit off topic even for the original off topic strand .

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

  5. #30
    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...



    It is a lot more complicated than that and sadly I haven't had much chance to contribute myself. You should chat to Jason and if you are on the same lines maybe we should sign you up. The decent UI was planned for version 1.1 originally, but the version 1 release has been delayed a bit tying up loose ends.

    Post a note to the support forum as this is a bit off topic even for the original off topic strand .

    yours, Marcus
    support forum @ sourceforge i guess ?

    Sike

  6. #31
    ********* 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
    support forum @ sourceforge i guess ?
    Sorry, it's actually a mail list. Yes.

    yours, Marcus

    p.s. Sorry Jeff. You can have your thread back now...
    Marcus Baker
    Testing: SimpleTest, Cgreen, Fakemail
    Other: Phemto dependency injector
    Books: PHP in Action, 97 things

  7. #32
    SitePoint Wizard gold trophysilver trophy
    Join Date
    Nov 2000
    Location
    Switzerland
    Posts
    2,479
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by lastcraft
    You could just use the new name like a Wiki.
    Good point, as with posting to http://site.com/articles/.

    The follow up question is where do you place the HTML forms for making the POSTs, without using verbs? REST seems to suggest you have "documents" represented by URLs and "tools" for editing (and perhaps navigating) them.

    Seems to me that REST is a pattern rather than some "one true way".
    Agreed. REST seems more a reflection on what is, rather than anything new, trying to highlight best practice and how to get most "re-use" out of the Internet.

  8. #33
    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

  9. #34
    SitePoint Zealot
    Join Date
    Mar 2004
    Location
    Netherlands
    Posts
    138
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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.
    That's one example of the shortcomings in the HTTP support of common browsers.

    As I see it, the whole world has settled upon using only a subset of the features of HTTP. This won't change soon, if this changes ever. The main reason for this is that GET and POST, combined with sessions and complex URLs is 'good enough' in most cases.

    I'm still hoping that sometime in the near future, an opensource project like mozilla or konquerer will make a browser that fully supports all HTTP 1.1 features, so you could use this as a platform to make advanced REST-based intranets (where you have control over the clients). It wouldn't exclude other browsers ofcourse. They at least would still be able to GET all available resources.

  10. #35
    SitePoint Zealot
    Join Date
    Mar 2004
    Location
    Netherlands
    Posts
    138
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    REST seems to suggest you have "documents" represented by URLs and "tools" for editing (and perhaps navigating) them.
    Yes, I think this is a good interpretation.

    The follow up question is where do you place the HTML forms for making the POSTs, without using verbs?
    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 change the /articles/ resource. The interpretation of a resource can be as broad as you want...

  11. #36
    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

  12. #37
    SitePoint Member
    Join Date
    Oct 2004
    Location
    malaysia
    Posts
    18
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    any real world REST implementation guides?

    hi, i'm newbie in REST.. but really get interested about its idea.

    i've been googling for REST tutorials and implementation guides recently, however i couldn't really find a nice complete article demonstrating a implementation of REST on current web app.

    if anyone already using REST in web app., do share some ideas, thanx.

    -----
    btw, since REST is using HTTP basic methods (PUT, GET, DELETE, POST etc)

    how well does PHP support HTTP /1.1 spec? will it be suitable to use PHP on writing a RESTful server?

    i just get started coding with php. so, pls correct me if i'm wrong. Searching thru' php4 doc, i couldn't find a way to handle HTTP DELETE method.. and PUT is being handle quite 'differently' from GET and POST.

    is there a better solution to handle HTTP methods via php?

  13. #38
    SitePoint Zealot
    Join Date
    Mar 2004
    Location
    Netherlands
    Posts
    138
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    The best example of a widely used RESTful application is the Atom API. It's used in blogging software. It also has a PHP implementation. It can be found at http://www.isolani.co.uk/blog/atom/P...Implementation .

    The HTTP request method is available in $_SERVER['REQUEST_METHOD'].

    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.

    If you have specific questions RESTifying your application, you could best start a new thread I think. I might be able to help. I'll check these forums some more often from now on.

  14. #39
    SitePoint Member
    Join Date
    Oct 2004
    Location
    malaysia
    Posts
    18
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Thanx for the reference link about ATOM.

    i've read about ATOM juz now. tat's really a good start point to learn about REST design.

    i think one thing that most non-CRUD web application developer do concern is the user-session management, which already widely deployed in current web-based business.

    well, i think i'll just start a new thread

  15. #40
    SitePoint Member
    Join Date
    Oct 2004
    Location
    malaysia
    Posts
    18
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    It has been a while, since the last post about REST discussion.

    Yesterday, I made a simple presentation slide, by using Weblog as an
    example of web applications, the slide will introduce to readers the basic
    idea of how a RESTful web application looks like.

    Wish to recieve your comments and suggestions about slide's contents

    Here's the link: http://www.geocities.com/iamstupidio...ple-Weblog.ppt

    (Please pm me if you have any access problem to that file).

  16. #41
    Resident Java Hater
    Join Date
    Jul 2004
    Location
    Gerodieville Central, UK
    Posts
    446
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by stupidiot
    It has been a while, since the last post about REST discussion.

    Yesterday, I made a simple presentation slide, by using Weblog as an
    example of web applications, the slide will introduce to readers the basic
    idea of how a RESTful web application looks like.

    Wish to recieve your comments and suggestions about slide's contents

    Here's the link: http://www.geocities.com/iamstupidio...ple-Weblog.ppt

    (Please pm me if you have any access problem to that file).
    It puts across the idea well. It should maybe mention what Harry said about the use of verbs. The other thing that leaves me unclear is the use of PUT and DELETE http methods. 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). However depending on forms servely limits your user interface.

  17. #42
    SitePoint Wizard DougBTX's Avatar
    Join Date
    Nov 2001
    Location
    Bath, UK
    Posts
    2,498
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    You don't want to have GET requests that modify things serverside, example: Google releases Web Accelerator, which pre-downloads pages that it sees links to. People visit pages with links to delete content, content gets deleted. Bad bad bad.

    I don't believe IE supports PUT and DELETE, which puts a bit of a damper on things. That's why you only ever see GET and POST in the wild. You can simulate PUT and DELETE with POST, so all is cool. Add an <input type="hidden" name="method" value="DELETE" /> to your POST form and be happy.

    You can get near-REST, but it means putting more things in cookies, unless you can argue sessions as a layer between the client and your RESTful app.

    Douglas
    Hello World

  18. #43
    SitePoint Evangelist
    Join Date
    Jun 2003
    Location
    Melbourne, Australia
    Posts
    440
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by DougBTX
    I don't believe IE supports PUT and DELETE, which puts a bit of a damper on things. That's why you only ever see GET and POST in the wild.
    I've never understood how a browser decides which request method is appropriate (other than the method attribute in a form tag, or maybe assuming that anything submit via a form should be a POST rather than a GET).

    Can one force a browser to issue a PUT or a DELETE (by simple markup)?

    Anyway, I found this project, previously mentioned by Harry interesting..
    Zealotry is contingent upon 100 posts and addiction 200?

  19. #44
    SitePoint Member
    Join Date
    Oct 2004
    Location
    malaysia
    Posts
    18
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by MiiJaySung
    It puts across the idea well. It should maybe mention what Harry said about the use of verbs.
    Do you mean Harry's http://www.sitepoint.com/forums/show...2&postcount=21

    I think when we design a system, starting by identify required resources (which are all nouns), will effectively reduce cases, where "verbs" appear in URLs.


    Quote Originally Posted by MiiJaySung
    The other thing that leaves me unclear is the use of PUT and DELETE http methods. 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). However depending on forms servely limits your user interface.
    The main purpose of using a set of standard interfaces, or HTTP methods in this case is, now, we provide meaningful semantic to each request, before sending it out across a network of machines towards the target server.

    Machines across Internet network understand HTTP methods well, and you can tell machines how to handle each type of request:

    Code:
    DELETE /articles/23444  HTTP/1.1
    (we can tell any HTTP machines, maybe gateways/proxies to block all DELETE requests, if we don't want ppl to delete it. They understand that.)

    Code:
    GET /articles/23444?action=delete HTTP/1.1
    GET /delete.php?article=23444 HTTP/1.1
    (machines don't understand "?action=delete" or "delete.php". Further, they assume GET is always safe from changing resource state. However, these URLs actually will kill that resource!)

    Real life truth...
    Current browsers, and HTML specs only help us to send out GET and POST requests. Later browsers support XmlHttpRequest object to allow client scripts send out custom method request.

    If we don't like forms and buttons in page design (me too :P), gmail is an example of using achor links to activate XmlHttpRequest objects using client scripts.

    Some thoughts...
    --------
    I find that there're two ways to send out appropriate method requests using current browsers:

    1. Clientscript - XmlHttpRequest + Forms
    When the end user submits a form, XmlHttpRequest is called to send out the content with desired HTTP methods (GET,PUT,POST,DELETE etc).

    The target URL should be referenced to the target resource itself.


    2. POST + Forms
    The forms act as a Processing Resource (as suggested by Mark Baker[BAKER]). When the end user pushes to submit button, content is POSTed to that form. The form will process and send out requests to target resources with appropriate HTTP methods.

    The target URL should be referenced to that form.


    Of course, GET is always easily available for everybody to retrieve our resources, by just providing a link. Two cases above are when we need to manipulate the resource state (or content).


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

    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.

    When resources grow more, we can migrate some of them to mirror server easily, and the old server will issue "3xx Redirect" response to inform clients.



    [BAKER] An Abstract Model for HTTP Resource State (Section 3.1.4)
    http://www.markbaker.ca/2001/09/draf...e-model-01.txt

  20. #45
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    unless you can argue sessions as a layer between the client and your RESTful app.
    From what I understand of REST, you shouldn't really be using this methodology (the use of SESSIONs) anyways, but I've need felt RESTful at any time anyways so I may be wrong?

  21. #46
    SitePoint Wizard DougBTX's Avatar
    Join Date
    Nov 2001
    Location
    Bath, UK
    Posts
    2,498
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I think the idea behind REST is simply to keep all session data on the client, so keeping session data on the server isn't REST.

    Then there are all the arguments about using HTTP as it was designed, which are all cool, but don't get too hung up on it if you don't have the browser support.

    Douglas
    Hello World

  22. #47
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Thanks for clearing that up for me. I had the suspision but just wasn't all that sure

  23. #48
    SitePoint Evangelist
    Join Date
    Jun 2003
    Location
    Melbourne, Australia
    Posts
    440
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Dr Livingston
    From what I understand of REST, you shouldn't really be using this methodology (the use of SESSIONs) anyways, but I've need felt RESTful at any time anyways so I may be wrong?
    I've been having a look at Roy Thomas Fielding's dissertation on REST (someone posted a link here recently). Thomas claims that
    The problem is that a cookie is defined as being attached to any future requests for a given set of resource identifiers, usually encompassing an entire site, rather than being associated with the particular application state (the set of currently rendered representations) on the browser.
    ...snip...
    Cookies also violate REST because they allow data to be passed without sufficiently identifying its semantics, thus becoming a concern for both security and privacy. The combination of cookies with the Referer [sic] header field makes it possible to track a user as they browse between sites.
    Fielding almost ignores the problem of determining whether the current user is should be able to change the state of the resource...
    Quote Originally Posted by stupidiot
    DELETE /articles/23444 HTTP/1.1
    Fielding continues:
    The same functionality should have been accomplished via anonymous authentication and true client-side state. A state mechanism that involves preferences can be more efficiently implemented using judicious use of context-setting URI rather than cookies, where judicious means one URI per state rather than an unbounded number of URI due to the embedding of a user-id.
    Presumably this means that the use of a query string to hold a session id is incorrect too. But how does one determine the identity of the user making the request? Since each state has one URL and since more than one user may be permitted to access that state, there can be no identification of the user. Now there's a security risk!
    Zealotry is contingent upon 100 posts and addiction 200?

  24. #49
    SitePoint Member
    Join Date
    Oct 2004
    Location
    malaysia
    Posts
    18
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by auricle
    Since each state has one URL and since more than one user may be permitted to access that state, there can be no identification of the user. Now there's a security risk!
    You can always use HTTP Authentication (which is extensible) in your server script to challege incoming requests.

  25. #50
    SitePoint Evangelist
    Join Date
    Jun 2003
    Location
    Melbourne, Australia
    Posts
    440
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by stupidiot
    You can always use HTTP Authentication (which is extensible) in your server script to challege incoming requests.
    For every request? Users would love that!
    Zealotry is contingent upon 100 posts and addiction 200?


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
  •