5 ms·

You should throw in CORBA from the 90s for completeness. My view mostly it was a confluence of poor dev experience and over-engineering that killed them. Some

You should throw in CORBA from the 90s for completeness. My view mostly it was a confluence of poor dev experience and over-engineering that killed them. Some of those protocols were well designed. Some were secure, all were pretty awful to implement. It’s worthwhile calling out REST as a long term success. Mainly because it was simple and flexible. Whether MCP will have that staying power I dunno, personally I think it still has some flaws, and the implementation quality is all over the shop. Some of the things that make it easy (studio) also create its biggest flaws.

jen20 1y ago
> It’s worthwhile calling out REST as a long term success. Mainly because it was simple and flexible. To be fair, REST as described in the Fielding paper is rare to come across - the success is JSON via HTTP
- cowsandmilk 1y ago
  This so much, I don’t think I’ve ever seen an API that matches Fielding’s paper.
  - taffer 1y ago
    You are using one right now! > REST [...] is a software architectural style that was created to describe the design [...] of the architecture for the World Wide Web. [1] People forget that the Web is the original REST. You have - resources (https://news.ycombinator.com/item?id=45468477 https://news.ycombinator.com/item?id=45468477) - HTTP verbs (GET, POST) - and hypermedia controls (<a href="item?id=45468365">parent</a>) This is all you need to meet Fielding's definition, and it has become so ubiquitous that we don't even notice it anymore. [1] https://en.wikipedia.org/wiki/REST https://en.wikipedia.org/wiki/REST
    - fzzzy 1y ago
      Maybe we would be talking about hypermedia as the engine of application state more if somebody took the time to work on the acronym.
- mianos 1y ago
  This another reason why COM and CORBA failed. A whole lot of people telling everyone else the way they are doing it is all wrong and their 'proper' way is the only way. Maybe proto became popular because google didn't actually care that much. I remember the ACE/Tao people who did a lot of work around CORBA. They did good stuff but such painful religious fervor vibed everyone out.
- smj-edison 1y ago
  I haven't read the original paper yet--looking at it now. But I am curious, what are some of the biggest differences you see between REST according to Fielding and REST according to convention?
  - craftkiller 1y ago
    My understanding is the big difference is REST must have URLs returned in the API responses to access additional data / actions. So in a REST API you'd have a single URL entrypoint that I'll call "/root". "/root" might then return to you something like: { "links": { "users": "/root/users", "posts": "/root/posts", "mail": "/root/mail" } } So then the client could make a request for "/root/users" which would return a list of users along with URLs for how to access individual users. So then the client could make a request for "/root/users/alice" and the server would return the information on alice along with URLs for actions like sending her a message or deleting her. But all of that interaction is driven from information returned from the server. All the client needed to begin was just the root URL. Most non-REST JSON APIs today communicate their endpoints via an out-of-band API documentation like swagger. Quoting the Fielding: > A REST API must not define fixed resource names or hierarchies (an obvious coupling of client and server). Servers must have the freedom to control their own namespace. Instead, allow servers to instruct clients on how to construct appropriate URIs > [...] > A REST API should be entered with no prior knowledge beyond the initial URI (bookmark) and set of standardized media types that are appropriate for the intended audience (i.e., expected to be understood by any client that might use the API). From that point on, all application state transitions must be driven by client selection of server-provided choices that are present in the received representations or implied by the user’s manipulation of those representations. https://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven https://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypert...
    - jkrejcha 1y ago
      One of the big things too is the encoding of type information using the mechanisms the standard interfaces provide. In HTTP, this is accomplished using media types (through the Accept and Content-Type headers as well as a few related ones). These media types can be standard but they can be vendored too[1]. With something like Content-Type: application/json { "name": "", ... } you don't really know much. With something like example/vnd.mycoolapp.user+json, you get typing information (i.e. you know that the representation of /users/me that the server has given you is a JSON variant of a mycoolapp User. (How the types are known is a priori knowledge of the client (but there are standard link relations you can use to reference API documentation, both human-readable and machine-readable)). A good example of this is your web browser: it knows how to display text/html documents of various character sets, probably knows text/plain, might know application/json. The best part is? HTTP has a standard mechanism for defining these link relations even if what you have isn't necessarily amenable to link relations[2] (the Link header). You can use that to navigate through a collection (previous, item, collection, etc), get documentation about the API (service-doc, service-desc), find things that are related (related), get STUN and TURN information (ice-server), etc. I doubt very much of this is used in practice, but there are a very rich set of standardized relationships that could be used here. (A lot of people admittedly assume "using PUT in a couple of places" is doing REST or that not calling all of your method endpoints doAction.pl or whatever is "RESTful" and I think that definition has become so widespread that talking about something that approaches actually doing something that resembles the architectural style tends to require reduplication.) [1]: https://www.iana.org/assignments/media-types/media-types.xhtml https://www.iana.org/assignments/media-types/media-types.xht... [2]: https://www.iana.org/assignments/link-relations/link-relations.xhtml https://www.iana.org/assignments/link-relations/link-relatio...
pointlessone 1y ago
SOAP is not that bad. WSDL is terrible though.

jen20 1y ago

> It’s worthwhile calling out REST as a long term success. Mainly because it was simple and flexible. To be fair, REST as described in the Fielding paper is rare to come across - the success is JSON via HTTP

cowsandmilk 1y ago
This so much, I don’t think I’ve ever seen an API that matches Fielding’s paper.
- taffer 1y ago
  You are using one right now! > REST [...] is a software architectural style that was created to describe the design [...] of the architecture for the World Wide Web. [1] People forget that the Web is the original REST. You have - resources (https://news.ycombinator.com/item?id=45468477 https://news.ycombinator.com/item?id=45468477) - HTTP verbs (GET, POST) - and hypermedia controls (<a href="item?id=45468365">parent</a>) This is all you need to meet Fielding's definition, and it has become so ubiquitous that we don't even notice it anymore. [1] https://en.wikipedia.org/wiki/REST https://en.wikipedia.org/wiki/REST
  - fzzzy 1y ago
    Maybe we would be talking about hypermedia as the engine of application state more if somebody took the time to work on the acronym.
mianos 1y ago
This another reason why COM and CORBA failed. A whole lot of people telling everyone else the way they are doing it is all wrong and their 'proper' way is the only way. Maybe proto became popular because google didn't actually care that much. I remember the ACE/Tao people who did a lot of work around CORBA. They did good stuff but such painful religious fervor vibed everyone out.
smj-edison 1y ago
I haven't read the original paper yet--looking at it now. But I am curious, what are some of the biggest differences you see between REST according to Fielding and REST according to convention?
- craftkiller 1y ago
  My understanding is the big difference is REST must have URLs returned in the API responses to access additional data / actions. So in a REST API you'd have a single URL entrypoint that I'll call "/root". "/root" might then return to you something like: { "links": { "users": "/root/users", "posts": "/root/posts", "mail": "/root/mail" } } So then the client could make a request for "/root/users" which would return a list of users along with URLs for how to access individual users. So then the client could make a request for "/root/users/alice" and the server would return the information on alice along with URLs for actions like sending her a message or deleting her. But all of that interaction is driven from information returned from the server. All the client needed to begin was just the root URL. Most non-REST JSON APIs today communicate their endpoints via an out-of-band API documentation like swagger. Quoting the Fielding: > A REST API must not define fixed resource names or hierarchies (an obvious coupling of client and server). Servers must have the freedom to control their own namespace. Instead, allow servers to instruct clients on how to construct appropriate URIs > [...] > A REST API should be entered with no prior knowledge beyond the initial URI (bookmark) and set of standardized media types that are appropriate for the intended audience (i.e., expected to be understood by any client that might use the API). From that point on, all application state transitions must be driven by client selection of server-provided choices that are present in the received representations or implied by the user’s manipulation of those representations. https://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven https://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypert...
  - jkrejcha 1y ago
    One of the big things too is the encoding of type information using the mechanisms the standard interfaces provide. In HTTP, this is accomplished using media types (through the Accept and Content-Type headers as well as a few related ones). These media types can be standard but they can be vendored too[1]. With something like Content-Type: application/json { "name": "", ... } you don't really know much. With something like example/vnd.mycoolapp.user+json, you get typing information (i.e. you know that the representation of /users/me that the server has given you is a JSON variant of a mycoolapp User. (How the types are known is a priori knowledge of the client (but there are standard link relations you can use to reference API documentation, both human-readable and machine-readable)). A good example of this is your web browser: it knows how to display text/html documents of various character sets, probably knows text/plain, might know application/json. The best part is? HTTP has a standard mechanism for defining these link relations even if what you have isn't necessarily amenable to link relations[2] (the Link header). You can use that to navigate through a collection (previous, item, collection, etc), get documentation about the API (service-doc, service-desc), find things that are related (related), get STUN and TURN information (ice-server), etc. I doubt very much of this is used in practice, but there are a very rich set of standardized relationships that could be used here. (A lot of people admittedly assume "using PUT in a couple of places" is doing REST or that not calling all of your method endpoints doAction.pl or whatever is "RESTful" and I think that definition has become so widespread that talking about something that approaches actually doing something that resembles the architectural style tends to require reduplication.) [1]: https://www.iana.org/assignments/media-types/media-types.xhtml https://www.iana.org/assignments/media-types/media-types.xht... [2]: https://www.iana.org/assignments/link-relations/link-relations.xhtml https://www.iana.org/assignments/link-relations/link-relatio...

pointlessone 1y ago

SOAP is not that bad. WSDL is terrible though.