12 ms·

> "This would suggest a restful api is not made for system-to-system communication, but requires human mediation at every step of the way" Which is exactly wha

by jaaron 4y ago

> "This would suggest a restful api is not made for system-to-system communication, but requires human mediation at every step of the way" Which is exactly what REST was originally designed to do: provide an architecture for the Internet (not your app or service) that allows for humans using software clients to interact with services developed by programmers other than those which developed the clients. It was about an interoperable, diverse Internet. If the distributed application is not developed across distributed organizations, particularly independent unassociated organizations, then the architectural style of REST is overkill for what you intend and you could have just kept using RPC the whole time. The point of the later RESTful API movement was to create distributed applications that leveraged the underlying architecture principles of the internet within their smaller distributed application. The theory being that this made the application more friendly and native to the broader internet, which I do agree is true, but was never the original point of REST. That said, xcamvber [1] is right: this is me being an old person fighting an old person battle. [1] https://news.ycombinator.com/item?id=32143382 https://news.ycombinator.com/item?id=32143382

mywittyname 4y ago
People took the useful ideas and tossed the rest. The whole idea of embedding links into the data that describe available operations was not seen as useful, because most web pages already do that. That was not a problem that needed to be solved. But the concept of resource-oriented architectures which leveraged HTTP verbs to act on data with descriptive URIs was extremely useful in an era when interactions with web servers would look something like POST /common/backend/doActMgt.pl Books like RESTful Web Services came out in 2007 and focused almost entirely on resource-oriented architecture. There's not really much mention of hypermedia in it. It's mostly about building API endpoints. It also referenced AWS S3 (wow, S3 is old) a lot and treated it as a reference implementation / proof of concept that the idea works and is scalable.
- forty 4y ago
  Did you mean: People took the useful ideas and tossed the REST ? ;)
  - molbioguy 4y ago
    Brilliant!
    - molbioguy 4y ago
      I know you're not supposed to complain about downvotes, but seriously?! A complement about a witty comment gets me downvoted. I give up.
      - pnt12 4y ago
        That's what the upvote button is for.
        theelous3 4y ago
        There is more than one way to give positive feedback. Think of it like metric buckets. Imagine you could only rate movies out of one. Sometimes you really like something and you want to tell the person you really liked it. This obsession people develop about the "right" way to use upvotes and comments is inane.
      - softwarebeware 4y ago
        Did you mean, "...gets me downvoted. I give UP." ;)
- jonhohle 4y ago
  I’m not sure what the infatuation with HTTP verbs is. RPC allows modeling objects and arbitrary verbs. REST gives you a handful of verbs and punts on data modeling. It always seemed like a step back from an API design perspective. Definitely a battle I lost but never really understood the other side to begin with.
  - AtlasBarfed 4y ago
    Standardization and a common language. Limits. Well developed error codes. Rpc is a huge footgun. What's annoying about rest is that it is a religion treated as a universal truth. But really, rest is basically crud.
    - eastbound 4y ago
      However, anyone who has used HTTP error codes in REST knows to avoid that – Receiving a 404-Not-Found causes hours of debugging and blind poking compared to receiving a 200-OK-{“error”:”Entity not found”}…
      - bigDinosaur 4y ago
        Why can't you do a 404 + message?
        charrondev 4y ago
        Yeah that seems the obvious thing. Our 404s say what wasn’t found (a resource; the endpoint, some associated data in the request). Our 403s describe what permissions precisely the user is missing. Our 400s describe what is malformed about the request.
        mappu 4y ago
        HTTP is just a transport for your RPC. It's an implementation detail. At the HTTP layer, the transport was successful, so a 200 is appropriate. A 404 would indicate 'not found' at the transport layer e.g. a bad proxy configuration or you didn't hit the right server at all. You definitely wouldn't confuse it with '${my_widget} not found'.
- vlovich123 4y ago
  As someone who has implemented S3 (TL for Cloudflare R2) I’ll choose to disagree that the RESTfulness of the S3 API is a resounding success. Just go ahead and try to write the code to route requests. So many features are likely excluded just because Amazon couldn’t figure out how to jam it into HTTP verbiage. So sure. S3 is implemented on top of REST but I’d much rather pick a proper RPC protocol. The only reason to stick with REST is that there’s an entire ecosystem around intercepting it as the lowest common denominator (proxies, reverse proxies, caching, browsers etc). If all of those spoke something more modern (gRPC, capnproto, etc) we might be better of. Certainly it would be simpler to maintain and evolve these code bases.
  - afiori 4y ago
    Does R2 also exposes an R2 specific interface or does it only offer the S3 compatible interface?
    - vlovich123 4y ago
      It supports APIv4 (JSON REST API consistent with how all other Cloudflare APIs are managed) and Worker bindings (JavaScript API). The former is how the UI is implemented (not currently documented beyond creating and deleting a bucket because we haven’t taken time to review/stabilize the API for proper REST semantics). The latter doesn’t use REST but instead has a hacked up JSONRPC-like mechanism (which we’ll rip out at some point once the runtime makes certain things easier).
- KronisLV 4y ago
  > People took the useful ideas and tossed the rest. Dylan Beattie actually had a great presentation about REST: "The Rest of ReST" https://youtu.be/g8E1B7rTZBI?t=250 https://youtu.be/g8E1B7rTZBI?t=250 I feel like some of the points in that video are really nice and also sadly some of the nicer possibilities of REST have been left underexplored: HATEOAS and resource expansion sounds great, but I've seen them be used very little in the real world. Nowadays people reach for GraphQL more often and also sometimes shoot themselves in the foot when they need to deal with the more dynamic nature of querying data with it and the added complexity of an entire query language. That said, it's nice that we get more and more stateless APIs (with JWTs for example), and sometimes we get the ability to add middleware (like additional auth, logging/auditing or caching layers) without altering the apps themselves too much, and honestly working with JSON and HTTP is wonderfully easy, even if not all of the APIs are actually "truly" RESTful. I still find myself kind of sad that WADL never got big or that there weren't that many machine oriented API spec solutions that would implement a healthy dose of codegen, a bit more than OpenAPI seems to have built around it. Ideally, you could query a remote API and it would tell you everything that you need to build an API client: api-client-codegen --spec rest --input https://api.some-app.com/v3/api-description.json --implementation apache-http-client --output some-app-client-v3.jar But alas, sadly that's not the world we live in and even while we could programmatically generate clients for APIs that change often, a lot of wisdom was lost from SOAP (and something like SoapUI, where you could feed it a WSDL and get a working client, despite SOAP itself being pretty bad).
thayne 4y ago
In thay case RESTful API is an oxymoron, because if it is REST it isn't an API.
bombcar 4y ago
Sounds very similar to (as far as I understand it) GOPHER.
- mh- 4y ago
  My recollection is that using Gopher just felt more or less like browsing the early web with lynx. Simple text resources with hyperlinks.
sporkland 4y ago
I agree with everything you said. As a fellow old person, I just wish they'd call them HTTP+JSON as calling them ReSTful obscures one of the core principals of ReST, Hateos. It may not matter for a ton of "APIs", but there are a number of places within applications that would benefit from this form of decoupling vs the static client knowing what to do with endpoints, so conflated the makes actual ReST hard for engineers to understand and utilize.

by jaaron 4y ago

mywittyname 4y ago

People took the useful ideas and tossed the rest. The whole idea of embedding links into the data that describe available operations was not seen as useful, because most web pages already do that. That was not a problem that needed to be solved. But the concept of resource-oriented architectures which leveraged HTTP verbs to act on data with descriptive URIs was extremely useful in an era when interactions with web servers would look something like POST /common/backend/doActMgt.pl Books like RESTful Web Services came out in 2007 and focused almost entirely on resource-oriented architecture. There's not really much mention of hypermedia in it. It's mostly about building API endpoints. It also referenced AWS S3 (wow, S3 is old) a lot and treated it as a reference implementation / proof of concept that the idea works and is scalable.

forty 4y ago
Did you mean: People took the useful ideas and tossed the REST ? ;)
- molbioguy 4y ago
  Brilliant!
  - molbioguy 4y ago
    I know you're not supposed to complain about downvotes, but seriously?! A complement about a witty comment gets me downvoted. I give up.
    - pnt12 4y ago
      That's what the upvote button is for.
      - theelous3 4y ago
        There is more than one way to give positive feedback. Think of it like metric buckets. Imagine you could only rate movies out of one. Sometimes you really like something and you want to tell the person you really liked it. This obsession people develop about the "right" way to use upvotes and comments is inane.
    - softwarebeware 4y ago
      Did you mean, "...gets me downvoted. I give UP." ;)
jonhohle 4y ago
I’m not sure what the infatuation with HTTP verbs is. RPC allows modeling objects and arbitrary verbs. REST gives you a handful of verbs and punts on data modeling. It always seemed like a step back from an API design perspective. Definitely a battle I lost but never really understood the other side to begin with.
- AtlasBarfed 4y ago
  Standardization and a common language. Limits. Well developed error codes. Rpc is a huge footgun. What's annoying about rest is that it is a religion treated as a universal truth. But really, rest is basically crud.
  - eastbound 4y ago
    However, anyone who has used HTTP error codes in REST knows to avoid that – Receiving a 404-Not-Found causes hours of debugging and blind poking compared to receiving a 200-OK-{“error”:”Entity not found”}…
    - bigDinosaur 4y ago
      Why can't you do a 404 + message?
      - charrondev 4y ago
        Yeah that seems the obvious thing. Our 404s say what wasn’t found (a resource; the endpoint, some associated data in the request). Our 403s describe what permissions precisely the user is missing. Our 400s describe what is malformed about the request.
      - mappu 4y ago
        HTTP is just a transport for your RPC. It's an implementation detail. At the HTTP layer, the transport was successful, so a 200 is appropriate. A 404 would indicate 'not found' at the transport layer e.g. a bad proxy configuration or you didn't hit the right server at all. You definitely wouldn't confuse it with '${my_widget} not found'.
vlovich123 4y ago
As someone who has implemented S3 (TL for Cloudflare R2) I’ll choose to disagree that the RESTfulness of the S3 API is a resounding success. Just go ahead and try to write the code to route requests. So many features are likely excluded just because Amazon couldn’t figure out how to jam it into HTTP verbiage. So sure. S3 is implemented on top of REST but I’d much rather pick a proper RPC protocol. The only reason to stick with REST is that there’s an entire ecosystem around intercepting it as the lowest common denominator (proxies, reverse proxies, caching, browsers etc). If all of those spoke something more modern (gRPC, capnproto, etc) we might be better of. Certainly it would be simpler to maintain and evolve these code bases.
- afiori 4y ago
  Does R2 also exposes an R2 specific interface or does it only offer the S3 compatible interface?
  - vlovich123 4y ago
    It supports APIv4 (JSON REST API consistent with how all other Cloudflare APIs are managed) and Worker bindings (JavaScript API). The former is how the UI is implemented (not currently documented beyond creating and deleting a bucket because we haven’t taken time to review/stabilize the API for proper REST semantics). The latter doesn’t use REST but instead has a hacked up JSONRPC-like mechanism (which we’ll rip out at some point once the runtime makes certain things easier).
KronisLV 4y ago
> People took the useful ideas and tossed the rest. Dylan Beattie actually had a great presentation about REST: "The Rest of ReST" https://youtu.be/g8E1B7rTZBI?t=250 https://youtu.be/g8E1B7rTZBI?t=250 I feel like some of the points in that video are really nice and also sadly some of the nicer possibilities of REST have been left underexplored: HATEOAS and resource expansion sounds great, but I've seen them be used very little in the real world. Nowadays people reach for GraphQL more often and also sometimes shoot themselves in the foot when they need to deal with the more dynamic nature of querying data with it and the added complexity of an entire query language. That said, it's nice that we get more and more stateless APIs (with JWTs for example), and sometimes we get the ability to add middleware (like additional auth, logging/auditing or caching layers) without altering the apps themselves too much, and honestly working with JSON and HTTP is wonderfully easy, even if not all of the APIs are actually "truly" RESTful. I still find myself kind of sad that WADL never got big or that there weren't that many machine oriented API spec solutions that would implement a healthy dose of codegen, a bit more than OpenAPI seems to have built around it. Ideally, you could query a remote API and it would tell you everything that you need to build an API client: api-client-codegen --spec rest --input https://api.some-app.com/v3/api-description.json --implementation apache-http-client --output some-app-client-v3.jar But alas, sadly that's not the world we live in and even while we could programmatically generate clients for APIs that change often, a lot of wisdom was lost from SOAP (and something like SoapUI, where you could feed it a WSDL and get a working client, despite SOAP itself being pretty bad).

thayne 4y ago

In thay case RESTful API is an oxymoron, because if it is REST it isn't an API.

bombcar 4y ago

Sounds very similar to (as far as I understand it) GOPHER.

mh- 4y ago
My recollection is that using Gopher just felt more or less like browsing the early web with lynx. Simple text resources with hyperlinks.

sporkland 4y ago

I agree with everything you said. As a fellow old person, I just wish they'd call them HTTP+JSON as calling them ReSTful obscures one of the core principals of ReST, Hateos. It may not matter for a ton of "APIs", but there are a number of places within applications that would benefit from this form of decoupling vs the static client knowing what to do with endpoints, so conflated the makes actual ReST hard for engineers to understand and utilize.