7 ms·

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, be

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).

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).