6 ms·

Have we considered that these REST "anti-patterns" exist because REST is fundamentally inappropriate for what most people are trying to use it for? What if you

Have we considered that these REST "anti-patterns" exist because REST is fundamentally inappropriate for what most people are trying to use it for? What if you can't shoehorn your functionality into the handful of REST verbs? What if none of the status codes make sense? What ever happened to plain old RPC? Have we stopped to consider that people tunnel things through POST or GET requests because it's easier and more flexible than trying to cram your functionality into GET, POST, PUT, PATCH, or DELETE? If you find yourself using a lot of these anti-patterns, maybe you should consider switching to something a little less "REST-ful".

RandomOpinion 9y ago
Much as I would like to agree with you, that war was already fought and lost in the early '00s. Port 80/443 were the two ports that couldn't ever be firewalled because web browsing depended on them, so everybody rushed to cram their RPC requests into some kind of HTTP-based protocol.
- xg15 9y ago
  HTTP != REST though, as the article notes. There are other ways to use port 80/443 that neither violate HTTP nor go full REST - websocket being an (extreme) example. Even the HTTP monopoly is changing. There are lots of new protocols (HTTP2, QUIC, WebRTC) that work besides firewalls and things like ALPN gives a standardized way to tunnel new protocols over an encrypted connection.
  - coldtea 9y ago
    >HTTP != REST though, as the article notes. The article might note it, and Roy might insist on it, but nobody cares. For all intents and purposes, what people call REST in practical use is RPC over HTTP with JSON responses.
    - boubiyeah 9y ago
      But then these people are just very wrong. No point encouraging them either :)
      - shados 9y ago
        The entire industry is just people who are very wrong hitting critical mass until no one remembers what was right.
  - dragonwriter 9y ago
    > HTTP != REST though, as the article notes. Well, HTTP itself is the archetypical REST API, though.
emeraldd 9y ago
There's nothing really wrong with RPC in my book, just don't call it REST when it's not. I'd say the bigger issue is that a large number of people implement an RPC variant and call it REST because it's on HTTP and not SOAPy.
- Scarbutt 9y ago
  Is RPC just ad hoc endpoints? The info on REST is overwhelming, to many different opinions, for a simple SPA do programmers really need a formalized client-server contract? Can one just access server capabilities through ad hoc endpoints and write custom code to fetch the data they need? servers define procedures, and they return data. I ask because I'm going to start writing my first http api for a small SPA.
  - ben_jones 9y ago
    It just causes so much busy work. Then busy work leads to bugs, which leads to framework abstractions, which leads to implicit nuance in almost every part of web development. RPC and client-server contracts, as well as static-typing, is a bloody god send and the whole world will be in a better place once we formalize and accept it (I didn't say standardize I said formalize).
    - michaelchisari 9y ago
      I'll defend REST's utility for simple data retrieval. If I just need a paginated list of comments on a video, being able to quickly hit /video/1093/comments and get that list back is really nice. More complex use cases, and specifically non-idempotent operations, is where I find REST doesn't hold up as well as RPC.
      - naasking 9y ago
        > If I just need a paginated list of comments on a video, being able to quickly hit /video/1093/comments and get that list back is really nice. REST isn't about human-readable URLs. The link to the comments should have been part of the representation returned for /video/1093 (typically JSON these days, so a "comments" property of the object).
gshulegaard 9y ago
For a public facing interface, I haven't really found REST to be lacking. Adherence to REST buys you simplicity and (if kept to the standards) some implicit understandability. That said, REST is not the right fit for _every_ use case. The same simplicity mentioned as a strength also limits its flexibility. I think this is no more abundantly clear than microservice oriented architectures. More and more these architectures are moving towards different patterns/protocols for various reasons (gRPC comes to mind).
TYPE_FASTER 9y ago
A combination of REST and Web Sockets works pretty well.
niftich 9y ago
Most things on the web are half-assed, and half-assed HTTP APIs enable rapid results (before the problems start). REST is not fundamentally inappropriate, it just needs a lot of careful design about domain objects, link relations, and media types. Generally, people are not very good at thoughtful design. It didn't help that REST began to trend as an idea right around the same time that intentionally schemaless JSON was replacing schema'd XML documents as the preferred way of over-web information interchange. For consumers, schemaless JSON snippets were attractive for partial processing; for developers, they were attractive for rapid iteration. For makers of "Web 2.0 Mashups", JSON-returning APIs were attractive because processing XML with circa-2006 "cross-browser" nightmare-mode Javascript was about as pleasurable as pulling teeth. People saw these APIs being called REST, they tried to understand REST, got overwhelmed halfway through, called it REST-like or RESTful instead, and that's how we arrived at where we are. During this time, RPC wasn't cool or buzzword-compliant, so the people who still RPC did it for good reasons and didn't really blog about it. The quip to consider RPC is nonetheless valid; stuff like gRPC or Thrift are at least proper RPC frameworks, and a much better idea than someone trying to ducktape something with GET and POST for the millionth time. Luckily, soon, GraphQL will be the newest entrant in this space, and will have to contend an influx of superficially-informed people enticed by its promise. It may have a better track record than REST, because a partial implementation of GraphQL will better resemble GraphQL than a partial implementation of REST will resemble REST.
- coldtea 9y ago
  >REST is not fundamentally inappropriate, it just needs a lot of careful design about domain objects, link relations, and media types. Generally, people are not very good at thoughtful design. Especially if it's not worth the effort.
  - wtbob 9y ago
    Generally, people are not very good at determining if thoughtful design is worth the effort. Yes, waterfall was a mistake, but design-nothing is mistaken too. Thinking before doing helps avoid waste & rework.
  - 9y ago
maxxxxx 9y ago
Totally agree. REST is a good idea for some use cases but now people want to force it into everything. But this seems to be the case for a lot web stuff.
tracker1 9y ago
Maybe it's time to add an EXEC action? Where the input arguments are either query-string and/or body parameters... Most use POST for that now, but there is room, or should be room for RPC-style endpoints in a mostly REST service, and vice-versa.
dragonwriter 9y ago
> What if you can't shoehorn your functionality into the handful of REST verbs? REST doesn't have a handful of verbs, HTTP has a handful of predefined verbs (but supports extensions). REST is an architectural style that does not specify the underlying protocol. > What if none of the status codes make sense? Again, that's an HTTP issue not a REST issue. And it's not likely to be a real issue (HTTP status codes may be insufficiently precise—but already support additional data for disambiguation—but I can't imagine a situation where none of them make sense.)
naasking 9y ago
> Have we considered that these REST "anti-patterns" exist because REST is fundamentally inappropriate for what most people are trying to use it for? Or perhaps people actually don't understand REST, but think they do, thus leading to endless blog articles about "REST levels" and other nonsense. > What if you can't shoehorn your functionality into the handful of REST verbs? GET and POST can represent any arbitrary program (they map to the lambda calculus after all). You don't need any more than that, in principle. The other verbs are merely optimizations. > What ever happened to plain old RPC? The inescapable failure modes of RPC are exactly what REST addresses.
paulddraper 9y ago
> What ever happened to plain old RPC? IDK. Whatever happened to plain old REST HTTP?

RandomOpinion 9y ago

Much as I would like to agree with you, that war was already fought and lost in the early '00s. Port 80/443 were the two ports that couldn't ever be firewalled because web browsing depended on them, so everybody rushed to cram their RPC requests into some kind of HTTP-based protocol.

xg15 9y ago
HTTP != REST though, as the article notes. There are other ways to use port 80/443 that neither violate HTTP nor go full REST - websocket being an (extreme) example. Even the HTTP monopoly is changing. There are lots of new protocols (HTTP2, QUIC, WebRTC) that work besides firewalls and things like ALPN gives a standardized way to tunnel new protocols over an encrypted connection.
- coldtea 9y ago
  >HTTP != REST though, as the article notes. The article might note it, and Roy might insist on it, but nobody cares. For all intents and purposes, what people call REST in practical use is RPC over HTTP with JSON responses.
  - boubiyeah 9y ago
    But then these people are just very wrong. No point encouraging them either :)
    - shados 9y ago
      The entire industry is just people who are very wrong hitting critical mass until no one remembers what was right.
- dragonwriter 9y ago
  > HTTP != REST though, as the article notes. Well, HTTP itself is the archetypical REST API, though.

emeraldd 9y ago

There's nothing really wrong with RPC in my book, just don't call it REST when it's not. I'd say the bigger issue is that a large number of people implement an RPC variant and call it REST because it's on HTTP and not SOAPy.

Scarbutt 9y ago
Is RPC just ad hoc endpoints? The info on REST is overwhelming, to many different opinions, for a simple SPA do programmers really need a formalized client-server contract? Can one just access server capabilities through ad hoc endpoints and write custom code to fetch the data they need? servers define procedures, and they return data. I ask because I'm going to start writing my first http api for a small SPA.
- ben_jones 9y ago
  It just causes so much busy work. Then busy work leads to bugs, which leads to framework abstractions, which leads to implicit nuance in almost every part of web development. RPC and client-server contracts, as well as static-typing, is a bloody god send and the whole world will be in a better place once we formalize and accept it (I didn't say standardize I said formalize).
  - michaelchisari 9y ago
    I'll defend REST's utility for simple data retrieval. If I just need a paginated list of comments on a video, being able to quickly hit /video/1093/comments and get that list back is really nice. More complex use cases, and specifically non-idempotent operations, is where I find REST doesn't hold up as well as RPC.
    - naasking 9y ago
      > If I just need a paginated list of comments on a video, being able to quickly hit /video/1093/comments and get that list back is really nice. REST isn't about human-readable URLs. The link to the comments should have been part of the representation returned for /video/1093 (typically JSON these days, so a "comments" property of the object).

gshulegaard 9y ago

For a public facing interface, I haven't really found REST to be lacking. Adherence to REST buys you simplicity and (if kept to the standards) some implicit understandability. That said, REST is not the right fit for _every_ use case. The same simplicity mentioned as a strength also limits its flexibility. I think this is no more abundantly clear than microservice oriented architectures. More and more these architectures are moving towards different patterns/protocols for various reasons (gRPC comes to mind).

TYPE_FASTER 9y ago

A combination of REST and Web Sockets works pretty well.

niftich 9y ago

Most things on the web are half-assed, and half-assed HTTP APIs enable rapid results (before the problems start). REST is not fundamentally inappropriate, it just needs a lot of careful design about domain objects, link relations, and media types. Generally, people are not very good at thoughtful design. It didn't help that REST began to trend as an idea right around the same time that intentionally schemaless JSON was replacing schema'd XML documents as the preferred way of over-web information interchange. For consumers, schemaless JSON snippets were attractive for partial processing; for developers, they were attractive for rapid iteration. For makers of "Web 2.0 Mashups", JSON-returning APIs were attractive because processing XML with circa-2006 "cross-browser" nightmare-mode Javascript was about as pleasurable as pulling teeth. People saw these APIs being called REST, they tried to understand REST, got overwhelmed halfway through, called it REST-like or RESTful instead, and that's how we arrived at where we are. During this time, RPC wasn't cool or buzzword-compliant, so the people who still RPC did it for good reasons and didn't really blog about it. The quip to consider RPC is nonetheless valid; stuff like gRPC or Thrift are at least proper RPC frameworks, and a much better idea than someone trying to ducktape something with GET and POST for the millionth time. Luckily, soon, GraphQL will be the newest entrant in this space, and will have to contend an influx of superficially-informed people enticed by its promise. It may have a better track record than REST, because a partial implementation of GraphQL will better resemble GraphQL than a partial implementation of REST will resemble REST.

coldtea 9y ago
>REST is not fundamentally inappropriate, it just needs a lot of careful design about domain objects, link relations, and media types. Generally, people are not very good at thoughtful design. Especially if it's not worth the effort.
- wtbob 9y ago
  Generally, people are not very good at determining if thoughtful design is worth the effort. Yes, waterfall was a mistake, but design-nothing is mistaken too. Thinking before doing helps avoid waste & rework.
- 9y ago

maxxxxx 9y ago

Totally agree. REST is a good idea for some use cases but now people want to force it into everything. But this seems to be the case for a lot web stuff.

tracker1 9y ago

Maybe it's time to add an EXEC action? Where the input arguments are either query-string and/or body parameters... Most use POST for that now, but there is room, or should be room for RPC-style endpoints in a mostly REST service, and vice-versa.

dragonwriter 9y ago

> What if you can't shoehorn your functionality into the handful of REST verbs? REST doesn't have a handful of verbs, HTTP has a handful of predefined verbs (but supports extensions). REST is an architectural style that does not specify the underlying protocol. > What if none of the status codes make sense? Again, that's an HTTP issue not a REST issue. And it's not likely to be a real issue (HTTP status codes may be insufficiently precise—but already support additional data for disambiguation—but I can't imagine a situation where none of them make sense.)

naasking 9y ago

> Have we considered that these REST "anti-patterns" exist because REST is fundamentally inappropriate for what most people are trying to use it for? Or perhaps people actually don't understand REST, but think they do, thus leading to endless blog articles about "REST levels" and other nonsense. > What if you can't shoehorn your functionality into the handful of REST verbs? GET and POST can represent any arbitrary program (they map to the lambda calculus after all). You don't need any more than that, in principle. The other verbs are merely optimizations. > What ever happened to plain old RPC? The inescapable failure modes of RPC are exactly what REST addresses.

paulddraper 9y ago

> What ever happened to plain old RPC? IDK. Whatever happened to plain old REST HTTP?