4 ms·

If API's are best represented via REST, then why aren't software API's in general RESTful (e.g. I dont POST triangles to my GPU)? The answer: SOME API's are bes

If API's are best represented via REST, then why aren't software API's in general RESTful (e.g. I dont POST triangles to my GPU)? The answer: SOME API's are best represented with REST, but most are not.

favorited 9y ago
Because the concept of REST was specifically designed around HTTP, not to be some abstract interface between any 2 systems.
- yeukhon 9y ago
  I agree but also have counter example, perhaps not yet as an interface for two systems. But let's start with this: What if I can ask my OS to do things I normally do over some protocol like HTTP in a RESTful style? Create user, list directory, find the last login, tell me linux kernel version. ^ has been done as a separate monitoring tool like Osquery, but can't we make such protocol natively? I don't want to parse my command-line output if I can just speak in one human-readble, machine-friendly dialect.
  - coldtea 9y ago
    >What if I can ask my OS to do things I normally do over some protocol like HTTP in a RESTful style? Create user, list directory, find the last login, tell me linux kernel version. The /proc filesystem is somewhat close to that when it comes to GET. >I don't want to parse my command-line output if I can just speak in one human-readble, machine-friendly dialect That's not what REST (the original concept) is about.
    - yeukhon 9y ago
      I understand REST's original motivation, but having a modern protocol to work with resources on a computer doesn't seem too much to ask.
      - deleted 9y ago
        [deleted]
- daliwali 9y ago
  REST actually has nothing to do with HTTP. It happens to map nicely to HTTP, but what it really is, is a set of architectural constraints.
  - niftich 9y ago
    The author of REST, Roy Fielding, feels that they're intertwined [1]: HTTP/1.1 is a specific architecture that, to the extent I succeeded in applying REST-based design, allows people to deploy RESTful network-based applications in a mostly efficient way, within the constraints imposed by legacy implementations. The design principles certainly predated HTTP, most of them were already applied to the HTTP/1.0 family, and I chose which constraints to apply during the pre-proposal process of HTTP/1.1, yet HTTP/1.1 was finished long before I had the available time to write down the entire model in a form that other people could understand. All of my products are developed iteratively, so what you see as a chicken and egg problem is more like a dinosaur-to-chicken evolution than anything so cut and dried as the conceptual form pre-existing the form. HTTP as we know it today is just as dependent on the conceptual notion of REST as the definition of REST is dependent on what I wanted HTTP to be today." [1] https://web.archive.org/web/20091111012314/http://tech.groups.yahoo.com/group/rest-discuss/message/6757 https://web.archive.org/web/20091111012314/http://tech.group...

favorited 9y ago

Because the concept of REST was specifically designed around HTTP, not to be some abstract interface between any 2 systems.

yeukhon 9y ago
I agree but also have counter example, perhaps not yet as an interface for two systems. But let's start with this: What if I can ask my OS to do things I normally do over some protocol like HTTP in a RESTful style? Create user, list directory, find the last login, tell me linux kernel version. ^ has been done as a separate monitoring tool like Osquery, but can't we make such protocol natively? I don't want to parse my command-line output if I can just speak in one human-readble, machine-friendly dialect.
- coldtea 9y ago
  >What if I can ask my OS to do things I normally do over some protocol like HTTP in a RESTful style? Create user, list directory, find the last login, tell me linux kernel version. The /proc filesystem is somewhat close to that when it comes to GET. >I don't want to parse my command-line output if I can just speak in one human-readble, machine-friendly dialect That's not what REST (the original concept) is about.
  - yeukhon 9y ago
    I understand REST's original motivation, but having a modern protocol to work with resources on a computer doesn't seem too much to ask.
    - deleted 9y ago
      [deleted]
daliwali 9y ago
REST actually has nothing to do with HTTP. It happens to map nicely to HTTP, but what it really is, is a set of architectural constraints.
- niftich 9y ago
  The author of REST, Roy Fielding, feels that they're intertwined [1]: HTTP/1.1 is a specific architecture that, to the extent I succeeded in applying REST-based design, allows people to deploy RESTful network-based applications in a mostly efficient way, within the constraints imposed by legacy implementations. The design principles certainly predated HTTP, most of them were already applied to the HTTP/1.0 family, and I chose which constraints to apply during the pre-proposal process of HTTP/1.1, yet HTTP/1.1 was finished long before I had the available time to write down the entire model in a form that other people could understand. All of my products are developed iteratively, so what you see as a chicken and egg problem is more like a dinosaur-to-chicken evolution than anything so cut and dried as the conceptual form pre-existing the form. HTTP as we know it today is just as dependent on the conceptual notion of REST as the definition of REST is dependent on what I wanted HTTP to be today." [1] https://web.archive.org/web/20091111012314/http://tech.groups.yahoo.com/group/rest-discuss/message/6757 https://web.archive.org/web/20091111012314/http://tech.group...