4 ms·

The big problem with using the hypertext Web as an example of REST is that there is a human operator literally driving that "engine of application state". Most

The big problem with using the hypertext Web as an example of REST is that there is a human operator literally driving that "engine of application state". Most API clients cannot afford to compute their state transitions on a network of 80 billion neurons.

Marazan 10y ago
REST is a human driven protocol. That's why resources have a link to a description of what the resource is.
- vfaronov 10y ago
  Are you suggesting that Fielding did not intend REST to be used in automated systems? By "distributed hypermedia systems", did he really mean "alternative browsers for alternative WWWs"?
  - jcrites 10y ago
    I can't adequately convey what I think is Fielding's position on how machines should interact with RESTful systems, but I will convey my understanding of the purpose and intent of his thesis: REST is a characterization of the Web architecture itself. It's not an alternative WWW, it is an abstract description of the principles behind the WWW. You can see this theme in Chapter 4 of the thesis in which Fielding characterizes REST [1]. > This chapter presents the requirements of the World Wide Web architecture and the problems faced in designing and evaluating proposed improvements to its key communication protocols. I use the insights garnered from the survey and classification of architectural styles for network-based hypermedia systems to hypothesize methods for developing an architectural style that would be used to guide the design of improvements for the modern Web architecture. [...] > The early Web architecture was based on solid principles--separation of concerns, simplicity, and generality--but lacked an architectural description and rationale. The design was based on a set of informal hypertext notes, two early papers oriented towards the user community, and archived discussions on the Web developer community mailing list. In reality, however, the only true description of the early Web architecture was found within the implementations of libwww (the CERN protocol library for clients and servers), Mosaic (the NCSA browser client), and an assortment of other implementations that interoperated with them. > An architectural style can be used to define the principles behind the Web architecture such that they are visible to future architects. As discussed in Chapter 1, a style is a named set of constraints on architectural elements that induces the set of properties desired of the architecture. The first step in my approach, therefore, is to identify the constraints placed within the early Web architecture that are responsible for its desirable properties. (internal citations elided) [1] https://www.ics.uci.edu/~fielding/pubs/dissertation/web_arch_domain.htm https://www.ics.uci.edu/~fielding/pubs/dissertation/web_arch...
    - deleted 10y ago
      [deleted]
  - Marazan 10y ago
    Yes, they can be used by automated system but the automated system was developed by humans who explored the RESTful service.
JimDabell 10y ago
No there isn't, a great deal of the web is loaded without direct human requests. For example: * Web crawlers * Archival services * Embedded resources (stylesheets, JavaScript, images) * Newsfeeds
- deleted 10y ago
  [deleted]
- vfaronov 10y ago
  True, and some of these use cases are very interesting. jcrites does not mention them, though. I realize now that his comment does not preclude them, either, but still this example would be more convincing if automated clients were emphasized, because that is what most people are actually building and care about.
- Avernar 10y ago
  All those examples are hard coded algorithms in the bulk copy category. They pretty much just use the GET method to download all or a specific subset of a site. To truly drive a REST API requires a human or an AI. The AI doesn't need to be human equivalent, just smart enough to inteligently interpret the hypermedia. If the API changes the AI would be able to adapt. I'm talking about the complexity of the computer on the Enterprise in ST:TNG. You give it a command and it figures out how to go about solving it.
  - JimDabell 10y ago
    I don't know where you got the idea that REST needs futuristic AI, and you haven't really explained why you think that way. Why does a REST client have to intelligently interpret the hypermedia? Why are hard-coded algorithms a problem? Why does it need to adapt to changes in the API? None of those things are requirements for REST, you've inserted them for seemingly no reason. For instance, consider an unattended webcam you want to use to show off, e.g. the growth of a flower bed remotely. It has the URI for a web service that returns a resource describing actions it can take: { "actions": [ { "rel": "report-problem", "href": "https://example.com/report-problem", "method": "POST", "accept": "application/problem+json" }, { "rel": "update-frame", "href": "https://example.com/update-frame", "method": "POST", "accept": "image/*" } ] } The definition of the report-problem relationship is "This is the action to take when an error occurs." The definition of the update-frame relationship is "This is the action to take when a new frame is available to upload." This API defines one media type and two relationships. It requires no futuristic artificial intelligence or human intervention, it just needs to speak HTTP, parse simple JSON, and trigger the actions based on simple conditions.

Marazan 10y ago

REST is a human driven protocol. That's why resources have a link to a description of what the resource is.

vfaronov 10y ago
Are you suggesting that Fielding did not intend REST to be used in automated systems? By "distributed hypermedia systems", did he really mean "alternative browsers for alternative WWWs"?
- jcrites 10y ago
  I can't adequately convey what I think is Fielding's position on how machines should interact with RESTful systems, but I will convey my understanding of the purpose and intent of his thesis: REST is a characterization of the Web architecture itself. It's not an alternative WWW, it is an abstract description of the principles behind the WWW. You can see this theme in Chapter 4 of the thesis in which Fielding characterizes REST [1]. > This chapter presents the requirements of the World Wide Web architecture and the problems faced in designing and evaluating proposed improvements to its key communication protocols. I use the insights garnered from the survey and classification of architectural styles for network-based hypermedia systems to hypothesize methods for developing an architectural style that would be used to guide the design of improvements for the modern Web architecture. [...] > The early Web architecture was based on solid principles--separation of concerns, simplicity, and generality--but lacked an architectural description and rationale. The design was based on a set of informal hypertext notes, two early papers oriented towards the user community, and archived discussions on the Web developer community mailing list. In reality, however, the only true description of the early Web architecture was found within the implementations of libwww (the CERN protocol library for clients and servers), Mosaic (the NCSA browser client), and an assortment of other implementations that interoperated with them. > An architectural style can be used to define the principles behind the Web architecture such that they are visible to future architects. As discussed in Chapter 1, a style is a named set of constraints on architectural elements that induces the set of properties desired of the architecture. The first step in my approach, therefore, is to identify the constraints placed within the early Web architecture that are responsible for its desirable properties. (internal citations elided) [1] https://www.ics.uci.edu/~fielding/pubs/dissertation/web_arch_domain.htm https://www.ics.uci.edu/~fielding/pubs/dissertation/web_arch...
  - deleted 10y ago
    [deleted]
- Marazan 10y ago
  Yes, they can be used by automated system but the automated system was developed by humans who explored the RESTful service.

JimDabell 10y ago

No there isn't, a great deal of the web is loaded without direct human requests. For example: * Web crawlers * Archival services * Embedded resources (stylesheets, JavaScript, images) * Newsfeeds

deleted 10y ago
[deleted]
vfaronov 10y ago
True, and some of these use cases are very interesting. jcrites does not mention them, though. I realize now that his comment does not preclude them, either, but still this example would be more convincing if automated clients were emphasized, because that is what most people are actually building and care about.
Avernar 10y ago
All those examples are hard coded algorithms in the bulk copy category. They pretty much just use the GET method to download all or a specific subset of a site. To truly drive a REST API requires a human or an AI. The AI doesn't need to be human equivalent, just smart enough to inteligently interpret the hypermedia. If the API changes the AI would be able to adapt. I'm talking about the complexity of the computer on the Enterprise in ST:TNG. You give it a command and it figures out how to go about solving it.
- JimDabell 10y ago
  I don't know where you got the idea that REST needs futuristic AI, and you haven't really explained why you think that way. Why does a REST client have to intelligently interpret the hypermedia? Why are hard-coded algorithms a problem? Why does it need to adapt to changes in the API? None of those things are requirements for REST, you've inserted them for seemingly no reason. For instance, consider an unattended webcam you want to use to show off, e.g. the growth of a flower bed remotely. It has the URI for a web service that returns a resource describing actions it can take: { "actions": [ { "rel": "report-problem", "href": "https://example.com/report-problem", "method": "POST", "accept": "application/problem+json" }, { "rel": "update-frame", "href": "https://example.com/update-frame", "method": "POST", "accept": "image/*" } ] } The definition of the report-problem relationship is "This is the action to take when an error occurs." The definition of the update-frame relationship is "This is the action to take when a new frame is available to upload." This API defines one media type and two relationships. It requires no futuristic artificial intelligence or human intervention, it just needs to speak HTTP, parse simple JSON, and trigger the actions based on simple conditions.