5 ms·

This is probably one of the most practical ones to read. REST is so much more than "/noun/id" routes.

sanderjd 5y ago
I'll confess that I've never been able to make heads or tails of the Fielding paper. That is, it's not that I don't think I understand what it's saying, it's that I don't relate to it; it doesn't really seem to be describing solutions to problems that have bugged me during my career. So I'll ask you and others here: what do you think are the most important and applicable insights from that paper?
- specialist 5y ago
  Useful heuristics. Mooted by coworker's incomprehension, poor craftsmanship, and beligerent disregard for received wisdom. In other words, all HTTP APIs devolve into screen scrapping, which is actively thwarted by terrible libraries. So just give up any expectations and do whatever scores the most agile scrum kanban karma on your team.
  - sanderjd 5y ago
    I'll confess that, like the Fielding dissertation, I also can't make heads or tails of this comment.
    - specialist 5y ago
      Too cynical? Distrust any one who claims they do understand. Because they don't. Our study group chewed thru REST in Practice. It's very reasonable, approachable. Good advice for a lot of design choices that you'll likely run into. Sadly, REST is like Agile. It's not possible for any two people to reach consensus on any aspect, big or small. And just like Agile, REST doesn't matter. What ever you do will be wrong. So just smile and play along.
      - sanderjd 5y ago
        Ok this I understand, and agree with, to a decent degree.
- naasking 5y ago
  > So I'll ask you and others here: what do you think are the most important and applicable insights from that paper? * Statelessness for horizontal scaling * Idempotency to handle network partitions * Request state must be inline or addressable by URL * Hypertext As The Engine Of Application State * Media type negotiation * How to exploit pervasive caching I think having these formalized in a coherent framework was very valuable, and I don't see how this couldn't help but influence your career, unless all you write are desktop applications.
  - sanderjd 5y ago
    This is a great list and the conclusion is very fair. I think maybe what it is is that both these concepts and various limitations and tradeoffs had already been broadly socialized by the time I came into the industry. So it's not that I don't see the paper's influence, it's more that I was never able to find anything to latch onto from the primary source which I hadn't already internalized based on its synthesis in various tools and techniques that I learned in different ways.
- amw-zero 5y ago
  Honestly, just HATEOAS. If you can change your client’s behavior without actually re-deploying it, you’re doing yourself and team a huge favor. Even just backwards compatible server changes are worth it.
da39a3ee 5y ago
Is the following at all reasonable? REST is for when you are building an API for broad “public” consumption (where “public” might mean public within your company). But many teams are actually building APIs for a very narrow audience; often just their colleague’s javascript! In that situation it’s often fine to build tailored endpoints. Furthermore, the fact that we see RPC being used by large well respected tech companies is additional backing for this view.

I'll confess that I've never been able to make heads or tails of the Fielding paper. That is, it's not that I don't think I understand what it's saying, it's that I don't relate to it; it doesn't really seem to be describing solutions to problems that have bugged me during my career. So I'll ask you and others here: what do you think are the most important and applicable insights from that paper?

specialist 5y ago
Useful heuristics. Mooted by coworker's incomprehension, poor craftsmanship, and beligerent disregard for received wisdom. In other words, all HTTP APIs devolve into screen scrapping, which is actively thwarted by terrible libraries. So just give up any expectations and do whatever scores the most agile scrum kanban karma on your team.
- sanderjd 5y ago
  I'll confess that, like the Fielding dissertation, I also can't make heads or tails of this comment.
  - specialist 5y ago
    Too cynical? Distrust any one who claims they do understand. Because they don't. Our study group chewed thru REST in Practice. It's very reasonable, approachable. Good advice for a lot of design choices that you'll likely run into. Sadly, REST is like Agile. It's not possible for any two people to reach consensus on any aspect, big or small. And just like Agile, REST doesn't matter. What ever you do will be wrong. So just smile and play along.
    - sanderjd 5y ago
      Ok this I understand, and agree with, to a decent degree.
naasking 5y ago
> So I'll ask you and others here: what do you think are the most important and applicable insights from that paper? * Statelessness for horizontal scaling * Idempotency to handle network partitions * Request state must be inline or addressable by URL * Hypertext As The Engine Of Application State * Media type negotiation * How to exploit pervasive caching I think having these formalized in a coherent framework was very valuable, and I don't see how this couldn't help but influence your career, unless all you write are desktop applications.
- sanderjd 5y ago
  This is a great list and the conclusion is very fair. I think maybe what it is is that both these concepts and various limitations and tradeoffs had already been broadly socialized by the time I came into the industry. So it's not that I don't see the paper's influence, it's more that I was never able to find anything to latch onto from the primary source which I hadn't already internalized based on its synthesis in various tools and techniques that I learned in different ways.
amw-zero 5y ago
Honestly, just HATEOAS. If you can change your client’s behavior without actually re-deploying it, you’re doing yourself and team a huge favor. Even just backwards compatible server changes are worth it.

da39a3ee 5y ago

Is the following at all reasonable? REST is for when you are building an API for broad “public” consumption (where “public” might mean public within your company). But many teams are actually building APIs for a very narrow audience; often just their colleague’s javascript! In that situation it’s often fine to build tailored endpoints. Furthermore, the fact that we see RPC being used by large well respected tech companies is additional backing for this view.