4 ms·

I am a designer so I never really got REST, but now I do. Definitely a must read.

grandalf 17y ago
As a designer you might enjoy the way I explain REST to people: Think of the URL as part of the User Interface. REST offers conventions that make it easy to guess the URL of what you are looking for, just as you would guess where to click/navigate to get it. I realize this only covers one aspect of REST, but I like it because I think the idea of an address as a resource which has a certain appearance (its URL) is quite powerful. edit: I realize that rest could just as easily use meaningless identifiers, but it is often the case that meaningful identifiers are used such that the user can GET desired items by guessing the URL.
- blasdel 17y ago
  NO. NO. REST is absolutely not about being able to guess URLs -- it's about never having to guess a URL. Repeat after me: Hypertext. As. The. Engine. Of. Application. State. Clean, meaningful, organized / structured URLs are unrelated to REST, and their presence tends to lead to the predominant anti-pattern of 'API Specifications'. Leave that bullshit in SOAP's failure pile.
  - grandalf 17y ago
    Uh ... I didn't say guessing state, I said guessing what is behind the URL. as in /users/greg vs /users/davis rather than /u.exe?23q4234q34q34234234asdfa&query=true&xml=false&screen=home The point I was trying to make is that with REST, URLs have meaning in and of themselves, not dependent on the presence/absence of a variety of other aspects of state embodied in the URL... The protocol (and REST verbs) is how you add that additional meaning... and a different URL thus means something different. Hence, for some universe of items, if one has an obvious meaning, the rest should. If you are using the protocol in the right way then your resource will not change depending on which verb you are using.
    - kragen 17y ago
      It sounds like you're commenting on what REST is without ever having read Roy's dissertation. You can fix that, you know.
      - grandalf 17y ago
        What was inaccurate about my statement?
        carpo 17y ago
        I think the point that the previous posters were making is that pure REST should not rely on out-of-band information. The client should not have to guess or create URLs from knowledge they may have to look up in some other place. A pure REST API should be discoverable and subsequently navigable without having to rely on any other information not contained inside the request. In practice this can increase the amount of requests required to get at the information you want, and also the size of each request, as it must then include information about the actions that can be taken on the resource. It could be argued that this constraint is more for the benefit of systems or programs that need to interact with the API without knowing anything but the initial URL, and not necessarily a programmer who can work these things out. owever, if a REST API uses this constraint, and application developers follow it, deep changes can be made to the URL structure of the API without breaking the applications that use it.
        grandalf 17y ago
        thanks for clarifying
        kragen 17y ago
        It's not so much that it was inaccurate (although it was) as that it was missing the point.
        grandalf 17y ago
        fair enough... I guess the reason I have though of the idea is b/c of the resource focus of REST... where a URL means something... I realize that isn't the point of REST, but it's nice.

As a designer you might enjoy the way I explain REST to people: Think of the URL as part of the User Interface. REST offers conventions that make it easy to guess the URL of what you are looking for, just as you would guess where to click/navigate to get it. I realize this only covers one aspect of REST, but I like it because I think the idea of an address as a resource which has a certain appearance (its URL) is quite powerful. edit: I realize that rest could just as easily use meaningless identifiers, but it is often the case that meaningful identifiers are used such that the user can GET desired items by guessing the URL.

blasdel 17y ago
NO. NO. REST is absolutely not about being able to guess URLs -- it's about never having to guess a URL. Repeat after me: Hypertext. As. The. Engine. Of. Application. State. Clean, meaningful, organized / structured URLs are unrelated to REST, and their presence tends to lead to the predominant anti-pattern of 'API Specifications'. Leave that bullshit in SOAP's failure pile.
- grandalf 17y ago
  Uh ... I didn't say guessing state, I said guessing what is behind the URL. as in /users/greg vs /users/davis rather than /u.exe?23q4234q34q34234234asdfa&query=true&xml=false&screen=home The point I was trying to make is that with REST, URLs have meaning in and of themselves, not dependent on the presence/absence of a variety of other aspects of state embodied in the URL... The protocol (and REST verbs) is how you add that additional meaning... and a different URL thus means something different. Hence, for some universe of items, if one has an obvious meaning, the rest should. If you are using the protocol in the right way then your resource will not change depending on which verb you are using.
  - kragen 17y ago
    It sounds like you're commenting on what REST is without ever having read Roy's dissertation. You can fix that, you know.
    - grandalf 17y ago
      What was inaccurate about my statement?
      - carpo 17y ago
        I think the point that the previous posters were making is that pure REST should not rely on out-of-band information. The client should not have to guess or create URLs from knowledge they may have to look up in some other place. A pure REST API should be discoverable and subsequently navigable without having to rely on any other information not contained inside the request. In practice this can increase the amount of requests required to get at the information you want, and also the size of each request, as it must then include information about the actions that can be taken on the resource. It could be argued that this constraint is more for the benefit of systems or programs that need to interact with the API without knowing anything but the initial URL, and not necessarily a programmer who can work these things out. owever, if a REST API uses this constraint, and application developers follow it, deep changes can be made to the URL structure of the API without breaking the applications that use it.
        grandalf 17y ago
        thanks for clarifying
      - kragen 17y ago
        It's not so much that it was inaccurate (although it was) as that it was missing the point.
        grandalf 17y ago
        fair enough... I guess the reason I have though of the idea is b/c of the resource focus of REST... where a URL means something... I realize that isn't the point of REST, but it's nice.