5 ms·
> 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 a
by 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.