5 ms·

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 add

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.
    - javascriptlol 15y ago
      >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. Your attempt to enforce some dichotomy between design and implementation is hopelessly misguided. >That's why REST emphasizes caching, stateless communication, the appropriate use of status codes, and the appropriate use of VERBs (idempotent vs non). These don't solve the major problems. If I want caching I can trivially implement it myself. It's a useless thing to implement at the architecture level. Similarly for idempotency etc. It's all a huge academic wank. An appropriately designed protocol will solve all these problems without the constraints. >I wouldn't write an OS kernel in Ruby either. What smug yet clueless response. You're begging the question. I'm frankly bored of talking to someone who knows nothing about protocol design, but defends HTTP as a "proven" technology. It clearly isn't, it fails on many levels, and the whole web stack is completely fucked. Good day.

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.
  - javascriptlol 15y ago
    >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. Your attempt to enforce some dichotomy between design and implementation is hopelessly misguided. >That's why REST emphasizes caching, stateless communication, the appropriate use of status codes, and the appropriate use of VERBs (idempotent vs non). These don't solve the major problems. If I want caching I can trivially implement it myself. It's a useless thing to implement at the architecture level. Similarly for idempotency etc. It's all a huge academic wank. An appropriately designed protocol will solve all these problems without the constraints. >I wouldn't write an OS kernel in Ruby either. What smug yet clueless response. You're begging the question. I'm frankly bored of talking to someone who knows nothing about protocol design, but defends HTTP as a "proven" technology. It clearly isn't, it fails on many levels, and the whole web stack is completely fucked. Good day.