4 ms·

This just sounds like a repeat of XML and similar debacles, where people tried to address design decisions outside the problem domain. XML is no more interopera

This just sounds like a repeat of XML and similar debacles, where people tried to address design decisions outside the problem domain. XML is no more interoperable than a well-documented binary protocol. I'm sure REST is great for some applications, but this attitude that we can do all our design upfront is bad for the web. I mean, the browser just recently rediscovered interrupt-driven programming with the introduction of websockets. That's pretty embarrassing if you ask me.

noblethrasher 15y ago
REST is the opposite of upfront design. The big idea is that objects can, in an ad-hoc fashion, discover what services another object offers (HATEOAS). If an object chooses to remember the state and list of services it discovers (caching), the remote object can offer advice about how long to store the list (cache control). In fact, REST specifically lets systems grow organically since each object never assumes knowledge about either state or state transitions, all knowledge is contingent and empirically discovered.
- javascriptlol 15y ago
  You just described a bunch of design constraints. The basic OS facilities and the design of the Internet already make some design decisions for you. REST is adding more. That is designing things up front. People said the same thing about XML, and of course it's only advantage is some level of self-documentation (that is going to break down pretty quickly when things get complicated).
  - noblethrasher 15y ago
    I've described object-oriented programming[1] where each object in the system has a URL. [1] The Smalltalk variety of OOP which is about encapsulation, message passing, and extreme late binding.
    - javascriptlol 15y ago
      Using REST over a real network is not equivalent to object-oriented programming. Don't be asinine.
  - noblethrasher 15y ago
    > Using REST over a real network is not equivalent to object-oriented programming. Don't be asinine. Okay. I'll let Alan Kay argue the exact same point then. http://video.google.com/videoplay?docid=-2950949730059754521 http://video.google.com/videoplay?docid=-2950949730059754521 The whole video is worth watching but the relevant part starts at 43:00. This video was made three years before Fielding submitted his dissertation. (note: this isn't an appeal to authority fallacy since he's making an actual argument.)
    - javascriptlol 15y ago
      I am not interested in what Alan Kay has to say. I asserted that you specified a bunch of design constraints. You did. You tried to counter by pointing out that it's just OO design. However, I'm not interested in arguing over what categories things fit into. The point is that the network imposes limitations and you often need a domain-specific design to get around them. For example, HTTP is awful for soft real-time applications.
      - noblethrasher 15y ago
        I was not countering the claim that REST doesn't entail design constraints since at the time I believed OOP itself is a (useful) design constraint (the biggest being no access to state variables, "getters" and "setters" are bad). But now that I think about it, I realize why people have a hard time understanding REST. It's not a "design" constraint any more than OOP is. It's an implementation constraint. In the case of OOP I think people confuse those notions because they conflate designing a system with designing class heirarches. But OOP doesn't have anything to do with classes. A system is object oriented when the state is private, objects communicate by passing messages and methods are late-bound. Similarly, you don't really design a system to be RESTful, you simply commit to the idea that you never know — a priori — what methods will be available on a resource. You determine them by asking the object and those methods are only valid as long as the cache-control header says they are. Just about everything else follows from that. > the point is that the network imposes limitations and you often need a domain-specific design to get around them That's why REST emphasizes caching, stateless communication, the appropriate use of status codes, and the appropriate use of VERBs (idempotent vs non). > for example, HTTP is awful for soft real-time applications. I wouldn't write an OS kernel in Ruby either.
- silverlake 15y ago
  Do you know of a real-world working example of a HATEOAS system? This strikes me as an AI-Complete problem.
  - noblethrasher 15y ago
    The intelligence driving the object doesn't have to be artificial. Usually the local object is acting as an agent for a human user. Common examples are REPLs and browsers.
parasubvert 15y ago
REST's problem domain is the design of a distributed hypermedia system on a global scale. It's pretty general because it needs to be. A "well documented protocol" (binary or not) by definition is interoperable within a certain context. The question is, how big is the scope of that context? The point of the Web protocols is to provide a framework for evolving bits of agreement - not "big design up front", except for the essential bits that have proven themselves, or are essential to bootstrap communication. HTTP, MIME, and URI are those essential bits of agreement at the moment. Witness how HTML isn't as essential as it used to be, given the growth of JSON APIs and mobile native apps.
- javascriptlol 15y ago
  Except HTTP hasn't proven itself, except to a growing set of specialist programmers who don't know any better. The web is hideously unreliable. People have become accustomed to reclicking links and reloading pages. Aside from hyperlinks, the only "innovations" of the web already existed in a more efficient form in operating systems decades ago. As for REST, I'm sure it's nice for some things. However, if you think interoperability is going to magically spring out of it you're ignoring the lessons of XML, which that having an (ostensibly) human-understandable format is not going to magically allow machines to become more interoperable. All it will do is allow people to make bad guesses about the meaning of documents instead of reading the documentation.
  - parasubvert 15y ago
    There's nothing magic about interoperability - its all about the architecture and the documentation. XML isn't an architecture, it's a tagged data format. I cannot understand your line of argument about how the two are related. Similarly, to suggest that HTTP hasn't proven itself (compared to what?) or that "innovations" of the web existed decades ago (really!?) is nonsensical to me. It's the most widely deployed application protocol on Earth. It handles billions of dollars of transactions. You claim the web is unreliable. I think that's a layer error. The issue is that networks are unreliable. That's not something one can paper over.

noblethrasher 15y ago

REST is the opposite of upfront design. The big idea is that objects can, in an ad-hoc fashion, discover what services another object offers (HATEOAS). If an object chooses to remember the state and list of services it discovers (caching), the remote object can offer advice about how long to store the list (cache control). In fact, REST specifically lets systems grow organically since each object never assumes knowledge about either state or state transitions, all knowledge is contingent and empirically discovered.

javascriptlol 15y ago
You just described a bunch of design constraints. The basic OS facilities and the design of the Internet already make some design decisions for you. REST is adding more. That is designing things up front. People said the same thing about XML, and of course it's only advantage is some level of self-documentation (that is going to break down pretty quickly when things get complicated).
- noblethrasher 15y ago
  I've described object-oriented programming[1] where each object in the system has a URL. [1] The Smalltalk variety of OOP which is about encapsulation, message passing, and extreme late binding.
  - javascriptlol 15y ago
    Using REST over a real network is not equivalent to object-oriented programming. Don't be asinine.
- noblethrasher 15y ago
  > Using REST over a real network is not equivalent to object-oriented programming. Don't be asinine. Okay. I'll let Alan Kay argue the exact same point then. http://video.google.com/videoplay?docid=-2950949730059754521 http://video.google.com/videoplay?docid=-2950949730059754521 The whole video is worth watching but the relevant part starts at 43:00. This video was made three years before Fielding submitted his dissertation. (note: this isn't an appeal to authority fallacy since he's making an actual argument.)
  - javascriptlol 15y ago
    I am not interested in what Alan Kay has to say. I asserted that you specified a bunch of design constraints. You did. You tried to counter by pointing out that it's just OO design. However, I'm not interested in arguing over what categories things fit into. The point is that the network imposes limitations and you often need a domain-specific design to get around them. For example, HTTP is awful for soft real-time applications.
    - noblethrasher 15y ago
      I was not countering the claim that REST doesn't entail design constraints since at the time I believed OOP itself is a (useful) design constraint (the biggest being no access to state variables, "getters" and "setters" are bad). But now that I think about it, I realize why people have a hard time understanding REST. It's not a "design" constraint any more than OOP is. It's an implementation constraint. In the case of OOP I think people confuse those notions because they conflate designing a system with designing class heirarches. But OOP doesn't have anything to do with classes. A system is object oriented when the state is private, objects communicate by passing messages and methods are late-bound. Similarly, you don't really design a system to be RESTful, you simply commit to the idea that you never know — a priori — what methods will be available on a resource. You determine them by asking the object and those methods are only valid as long as the cache-control header says they are. Just about everything else follows from that. > the point is that the network imposes limitations and you often need a domain-specific design to get around them That's why REST emphasizes caching, stateless communication, the appropriate use of status codes, and the appropriate use of VERBs (idempotent vs non). > for example, HTTP is awful for soft real-time applications. I wouldn't write an OS kernel in Ruby either.
silverlake 15y ago
Do you know of a real-world working example of a HATEOAS system? This strikes me as an AI-Complete problem.
- noblethrasher 15y ago
  The intelligence driving the object doesn't have to be artificial. Usually the local object is acting as an agent for a human user. Common examples are REPLs and browsers.

parasubvert 15y ago

REST's problem domain is the design of a distributed hypermedia system on a global scale. It's pretty general because it needs to be. A "well documented protocol" (binary or not) by definition is interoperable within a certain context. The question is, how big is the scope of that context? The point of the Web protocols is to provide a framework for evolving bits of agreement - not "big design up front", except for the essential bits that have proven themselves, or are essential to bootstrap communication. HTTP, MIME, and URI are those essential bits of agreement at the moment. Witness how HTML isn't as essential as it used to be, given the growth of JSON APIs and mobile native apps.

javascriptlol 15y ago
Except HTTP hasn't proven itself, except to a growing set of specialist programmers who don't know any better. The web is hideously unreliable. People have become accustomed to reclicking links and reloading pages. Aside from hyperlinks, the only "innovations" of the web already existed in a more efficient form in operating systems decades ago. As for REST, I'm sure it's nice for some things. However, if you think interoperability is going to magically spring out of it you're ignoring the lessons of XML, which that having an (ostensibly) human-understandable format is not going to magically allow machines to become more interoperable. All it will do is allow people to make bad guesses about the meaning of documents instead of reading the documentation.
- parasubvert 15y ago
  There's nothing magic about interoperability - its all about the architecture and the documentation. XML isn't an architecture, it's a tagged data format. I cannot understand your line of argument about how the two are related. Similarly, to suggest that HTTP hasn't proven itself (compared to what?) or that "innovations" of the web existed decades ago (really!?) is nonsensical to me. It's the most widely deployed application protocol on Earth. It handles billions of dollars of transactions. You claim the web is unreliable. I think that's a layer error. The issue is that networks are unreliable. That's not something one can paper over.