6 ms·
The article is named Post-REST, but the summary says: "...REST still provides a good clean way to decompose complicated problems, and its extreme simp
by rb808 8y ago
The article is named Post-REST, but the summary says: "...REST still provides a good clean way to decompose complicated problems, and its extreme simplicity and resilience..."
Is there a reason not to use REST then? I didn't quite understand.
- deleted 8y ago[deleted]
- umvi 8y ago> Is there a reason not to use REST then? I didn't quite understand There can be. For example in the world of satellite internet where every byte is precious and every tcp connection is a massive performance penalty (3 way handshake * distance to satellite at speed of light = huge latencies), a REST API can be very wasteful. Something like GraphQL is much more suited to that case where you can get only exactly what you need, nothing more, and on a single connection.
- icebraining 8y agoNothing in REST prevents you from asking and getting only what you need. Assuming you're using HTTP, that's a common use of URL parameters; alternatively, you can pass a more detailed request in the body (yes, even in GET).
- deleted 8y ago[deleted]
- dragonwriter 8y ago> Nothing in REST prevents you from asking and getting only what you need. Assuming you're using HTTP, that's a common use of URL parameters; alternatively, you can pass a more detailed request in the body (yes, even in GET). GET is specified as not having a body and conformant HTTP implementations ignore the body of a GET, so in addition to violating RESTs general proscription on violating the underlying protocol (HTTP, in this example), you break compatibility with standard toolchain components if you do this. What you seem to want is SEARCH pulled out from under the weight of WebDAV, i.e.: https://tools.ietf.org/html/draft-snell-search-method-01 https://tools.ietf.org/html/draft-snell-search-method-01
- umvi 8y agoRight but... you're basically suggesting I implement a query language into my REST backend. Why would I do that if a similar QL already exists in the form of GraphQL?
- ako 8y agoOr use oData which is a REST query language.
- kh_hk 8y agoYes and no. Should you keep using HTTP calls for adding an item to a cart? Possibly. Should you use HTTP calls to communicate between services, let's say, to poll a resource every second and know if a worker has finished, when there are better systems and there's good enough technology available to support a higher throughput? Not so much.
- icebraining 8y agoPolling every second would be wasteful; you can just make an HTTP request and hold the connection open until it's finished. Or just pass an URL, and let the other side call you. (That's assuming HTTP, which btw is not the only protocol which can implement REST constraints)
- kh_hk 8y agoThen you are dealing with client timeouts or the fact that a lot of endpoints do not support url callbacks (for good reasons) or maybe clients that cannot be called back (for good reasons too). Cannot say much about REST constraints outside of HTTP so excuse my ignorance on that. But I think it was clear the parent was referring to HTTP, or most possibly, GET and POST HTTP calls returning JSON.
- icebraining 8y agoYou always have to deal with timeouts and other network issues, regardless of protocol. Rather than retry every second, you retry on timeout.
- kh_hk 8y agoAnd yet most HTTP APIs are going to give you a response with an status instead of holding it. I guess because it's much easier to implement and also assumes less on the consumer part. Then there was Comet and what resulted from that, websockets and server side events.
- bduerst 8y ago
- deleted 8y ago[deleted]
- jimbokun 8y agoAfter reading the article, the combination of REST APIs combined with durable, persistent queues (Kafka), covers most architectural needs. Queues for managing internal low latency and high throughput use cases. REST for external facing APIs with good documentation and well defined semantics.