7 ms·

The author suggests that "there's just far too much confusion about what REST means to rescue it" and suggests differentiating APIs in 2 other categories instea

by tuxie_ 5y ago

The author suggests that "there's just far too much confusion about what REST means to rescue it" and suggests differentiating APIs in 2 other categories instead, but in my opinion this not only introduces more confusion, but even there doesn't seem to be any constrain that would prevent the same confusion from arising again. There's no library to enforce a certain standard. It's just another set of well-intentioned guidelines. In a few years we would be reading "should we rebrand Hypermedia APIs?" kind of blog posts.

slver 5y ago
> in my opinion this not only introduces more confusion I don't think that's possible. I've officially banned the word "REST" from being used in technical discussions. Using that word is not just useless, it's harmful. Note that this is not an issue with the original paper, but everything that happened after it.
- goto11 5y ago
  The problem is not REST per se, the problem is people thinking a machine-to-machine API "should" conform to REST. I have not seen a coherent argument for why HATEOAS should be a useful property for API's beside "REST says so". That said, we should not throw the baby out with the bathwater. Some REST principles like statelessness are good design for API's also.
  - pa7x1 5y ago
    100% agree, HATEOAS is rather useless for machine-to-machine. And it shouldn't come as a surprise that most APIs decide to not commit to this design constraint. I prefer to think of real-world APIs as coming in varying degees of RESTfulness depending on the design constraints they have chosen to conform to. Good engineering is about making judicious analysis of the trade-offs involved, if HATEOAS doesn't bring you anything dropping it is the right thing to do.
    - Joker_vD 5y ago
      HATEOAS is somewhat useful even in machine-to-machine: hard-coded URLs in clients are kind of a PITA to support.
      - goto11 5y ago
        What is the problem with hard-coded URLs? It is certainly simpler than having to extract the URLs from some other request. If they don't change (and they shouldn't!) I don't see the problem.
        Joker_vD 5y ago
        Well the problem is exactly that they do change sometimes. And having only one hard-coded URL is easier than having twelve of those. > It is certainly simpler than having to extract the URLs from some other request. It's not extracted from other request, it's extracted from the response to the original request, and using a field from the local struct is not harder than using a global constant.
        goto11 5y ago
        > Well the problem is exactly that they do change sometimes. Well they shouldn't! And if the API arbitrarily changes URLs around without reason, then surely they might also change the URL for the initial request.
        Joker_vD 5y ago
        > Well they shouldn't! If you treat them as public interface, they shouldn't, yes. But if you treat them as internal implementation details, they absolutely could. One can also think about it as static vs dynamic dispatch: you make an initial request, you get a vtable of "method name -> method pointer" as a part of response. Or you can hardcode the method pointers and make it the remote server's job to properly chose the appropriate internal endpoint.
  - slver 5y ago
    You're entirely right. Another problem with REST is that Fielding himself describes it as a "large grain resource approach". It's no surprise we love HTTP and URLs when we have to return, say, images, downloads or entire documents in our APIs. Just put the URL in, serve it on your CDN. But for small grain data items, it's terrible.
  - dragonwriter 5y ago
    > I have not seen a coherent argument for why HATEOAS should be a useful property for API's beside "REST says so". Loose coupling and extensibility, the same reason that its used on the web, which is quite critically a machine-to-machine protocol (while obviously humans consume it via user-agents, automatic crawling and othee machine-to-machine processing is key to the success of the web) and HATEOAS is key to why it works.
- EMM_386 5y ago
  > I don't think that's possible. I've officially banned the word "REST" from being used in technical discussions. I've been a software engineer for decades and I am helping a company move from SOAP-based XML services into a more coherent REST-type architecture. Why would this be a banned technical discussion?
  - deaddodo 5y ago
    I think their point is that REST means nothing beyond “uses HTTP verbs” these days. Most companies/teams can’t even agree on the differences between POST, PUT and PATCH; let alone status codes, payload structure, authentication, etc. So using the term REST will mean something different to every person using it. Similar to how a Ruby, PHP and Python engineer will envision a different architecture if you tell them to build a “backend”.
    - slver 5y ago
      > I think their point is that REST means nothing beyond “uses HTTP verbs” Funny thing is that this means HTML pages also aren't restful, because they stick to GET and POST.
      - deaddodo 5y ago
        HTML (/browsers) have agreed upon payloads, status codes and authentication. The lack of PUT/DELETE/etc is more a function of use cases than the HTTP/HTML standard and there are plenty of example servers that are fully RESTful. That was also the original use case of web browsers (as a document-store/multimedia+hyperlink-enhanced FTP).
    - bewo001 5y ago
      They call REST anything that uses JSON over HTTP nowadays. What I don't get, when they don't know or don't want to do REST, why they are not just calling their API JSON/HTTP?
      - mixmastamyk 5y ago
- dragonwriter 5y ago
  > I've officially banned the word "REST" from being used in technical discussions. So if I want to refer to the architecture of that name described in Fielding’s Architectural Styles and the Design of Network-based Software Architectures, what is the approved circumlocution?
  - Kinrany 5y ago
    I assume they mean REST as applied to APIs. The thesis is just not about APIs, as argued by the article.
Kinrany 5y ago
Unlike REST, HTTP is a well-defined standard. Hypermedia APIs, on the other hand, are an active area of research, so it makes perfect sense for them not to be standardized yet. And once a specific standard does emerge, it will have a different name too, of course.

by tuxie_ 5y ago

slver 5y ago

> in my opinion this not only introduces more confusion I don't think that's possible. I've officially banned the word "REST" from being used in technical discussions. Using that word is not just useless, it's harmful. Note that this is not an issue with the original paper, but everything that happened after it.

goto11 5y ago
The problem is not REST per se, the problem is people thinking a machine-to-machine API "should" conform to REST. I have not seen a coherent argument for why HATEOAS should be a useful property for API's beside "REST says so". That said, we should not throw the baby out with the bathwater. Some REST principles like statelessness are good design for API's also.
- pa7x1 5y ago
  100% agree, HATEOAS is rather useless for machine-to-machine. And it shouldn't come as a surprise that most APIs decide to not commit to this design constraint. I prefer to think of real-world APIs as coming in varying degees of RESTfulness depending on the design constraints they have chosen to conform to. Good engineering is about making judicious analysis of the trade-offs involved, if HATEOAS doesn't bring you anything dropping it is the right thing to do.
  - Joker_vD 5y ago
    HATEOAS is somewhat useful even in machine-to-machine: hard-coded URLs in clients are kind of a PITA to support.
    - goto11 5y ago
      What is the problem with hard-coded URLs? It is certainly simpler than having to extract the URLs from some other request. If they don't change (and they shouldn't!) I don't see the problem.
      - Joker_vD 5y ago
        Well the problem is exactly that they do change sometimes. And having only one hard-coded URL is easier than having twelve of those. > It is certainly simpler than having to extract the URLs from some other request. It's not extracted from other request, it's extracted from the response to the original request, and using a field from the local struct is not harder than using a global constant.
        goto11 5y ago
        > Well the problem is exactly that they do change sometimes. Well they shouldn't! And if the API arbitrarily changes URLs around without reason, then surely they might also change the URL for the initial request.
        Joker_vD 5y ago
        > Well they shouldn't! If you treat them as public interface, they shouldn't, yes. But if you treat them as internal implementation details, they absolutely could. One can also think about it as static vs dynamic dispatch: you make an initial request, you get a vtable of "method name -> method pointer" as a part of response. Or you can hardcode the method pointers and make it the remote server's job to properly chose the appropriate internal endpoint.
- slver 5y ago
  You're entirely right. Another problem with REST is that Fielding himself describes it as a "large grain resource approach". It's no surprise we love HTTP and URLs when we have to return, say, images, downloads or entire documents in our APIs. Just put the URL in, serve it on your CDN. But for small grain data items, it's terrible.
- dragonwriter 5y ago
  > I have not seen a coherent argument for why HATEOAS should be a useful property for API's beside "REST says so". Loose coupling and extensibility, the same reason that its used on the web, which is quite critically a machine-to-machine protocol (while obviously humans consume it via user-agents, automatic crawling and othee machine-to-machine processing is key to the success of the web) and HATEOAS is key to why it works.
EMM_386 5y ago
> I don't think that's possible. I've officially banned the word "REST" from being used in technical discussions. I've been a software engineer for decades and I am helping a company move from SOAP-based XML services into a more coherent REST-type architecture. Why would this be a banned technical discussion?
- deaddodo 5y ago
  I think their point is that REST means nothing beyond “uses HTTP verbs” these days. Most companies/teams can’t even agree on the differences between POST, PUT and PATCH; let alone status codes, payload structure, authentication, etc. So using the term REST will mean something different to every person using it. Similar to how a Ruby, PHP and Python engineer will envision a different architecture if you tell them to build a “backend”.
  - slver 5y ago
    > I think their point is that REST means nothing beyond “uses HTTP verbs” Funny thing is that this means HTML pages also aren't restful, because they stick to GET and POST.
    - deaddodo 5y ago
      HTML (/browsers) have agreed upon payloads, status codes and authentication. The lack of PUT/DELETE/etc is more a function of use cases than the HTTP/HTML standard and there are plenty of example servers that are fully RESTful. That was also the original use case of web browsers (as a document-store/multimedia+hyperlink-enhanced FTP).
  - bewo001 5y ago
    They call REST anything that uses JSON over HTTP nowadays. What I don't get, when they don't know or don't want to do REST, why they are not just calling their API JSON/HTTP?
    - mixmastamyk 5y ago
dragonwriter 5y ago
> I've officially banned the word "REST" from being used in technical discussions. So if I want to refer to the architecture of that name described in Fielding’s Architectural Styles and the Design of Network-based Software Architectures, what is the approved circumlocution?
- Kinrany 5y ago
  I assume they mean REST as applied to APIs. The thesis is just not about APIs, as argued by the article.

Kinrany 5y ago

Unlike REST, HTTP is a well-defined standard. Hypermedia APIs, on the other hand, are an active area of research, so it makes perfect sense for them not to be standardized yet. And once a specific standard does emerge, it will have a different name too, of course.