6 ms·

It's really not, I'm sorry. State is carried by the client, the client traverses links to find out what it can do, the responses are described by a published c

It's really not, I'm sorry. State is carried by the client, the client traverses links to find out what it can do, the responses are described by a published content type, and the content type defines the semantics of the protocol. It's not hard, but people like to pretend that it is. Nothing says you can't stick to GET and POST, nothing requires weird headers. "ReST in Practice" is a great introduction for engineers.

jcrites 11y ago
A person looking to understand "What is REST? What is a RESTful application?" would be well-served by considering websites rather than web services. Facebook, Amazon, and Hacker News are good examples of RESTful applications. You can enter them through their website roots with no prior knowledge beyond standard web media types like HTML/CSS. The site roots display some information, expose some functionality like search, and link to pages with more capabilities like to create an account. The search function is expressed as an HTML form, and when the user submits their search, the HTML spec tells the browser to navigate to a new URL composed from the search form fields. The search result page displays a list of hyperlinks to other resources, such as products on Amazon or people on Facebook. Navigating to those pages lets you discover information and hyperlinks to other resources such as a person's photos, related products, etc. The way a browser navigates through a website by following links is the classic example of a RESTful application, and is the meaning of "hypermedia as the engine of application state". Fielding also wrote a blog post clarifying REST and its constraints: http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hyperte... > A REST API should be entered with no prior knowledge beyond the initial URI and set of standardized media types that are appropriate for the intended audience. A REST API must not define fixed resource names or hierarchies (an obvious coupling of client and server). A REST API should never have “typed” resources that are significant to the client. Any effort spent describing what methods to use on what URIs of interest should be entirely defined within the scope of the processing rules for a media type Some confusion about REST seems to stem from misguided attempts to apply REST to scenarios for which it's not a good fit - scenarios where there is by necessity tight coupling in the form of mutual knowledge of specific data types and operations. Other confusion about the term "REST" comes from applying subset of its principles, resulting in a popular label that refers to a large spectrum of architectural styles. The Richardson Maturity Model helps organize these functionality subsets into levels that can be named and considered separately - services termed REST are sometimes level 1 or 2 in the Richardson model. http://martinfowler.com/articles/richardsonMaturityModel.html http://martinfowler.com/articles/richardsonMaturityModel.htm...
- deleted 11y ago
  [deleted]
- stanleydrew 11y ago
  Exactly. The problem is that, for some reason, people decided that an "API" should be "RESTful". Ruby on Rails put this idea into a lot of developers' heads. An API is probably the worst thing to try to make truly RESTful, in the full HATEOAS sense. Further confusion comes from the fact that some of the REST constraints are actually very useful in machine-to-machine API design. Thinking about a system in terms of a large number of resources operated on by a standard set of verbs is nice. Caching is nice. The un-bloating of HTTP bodies from the SOAP days is nice. I think there is some consensus that we can call that thing an "HTTP API" rather than a "REST API", which might start to clear up some of the confusion.
- wstrange 11y ago
  Sorry - the whole "REST is just like websites" thing drives me nuts. With the web, it is not the browser doing the navigation; It is very advanced AI wetware. It is hard to find widespread examples of machine to machine interaction based purely on RESTful discovery. I think REST is interesting - but at the end of the day, is it really all that different from other communication mechanisms?
  - stanleydrew 11y ago
    But REST is just like websites. It's a term that was literally coined to describe the web, including websites and browsers. Why does it drive you nuts?
    - sopooneo 11y ago
      For me, it drives me nuts because zealots do a lot of handwaving to get from "the web itself is RESTful!" to "and it's the best possible way to build an API".
      - jcrites 11y ago
swax 11y ago
Even if REST was a standard and no one ever argued about it, I still wouldn't use it. It is needless overhead designed by a PhD to solve problems I haven't encountered for 15 years. API traversal sounds nice, but who uses it? Has the benefit been realized or is it still just theory? With a simple JSON RPC API I can still transmit objects representing state. Like you said it's not complicated. Has it crossed your mind that REST is maybe more trouble than it's worth?
- bobfromhuddle 11y ago
  The same arguments were made about object orientation: I've never needed it, it's useless baggage with no real world benefits, it sounds great in theory but has no practical use... I've built hypertext APIs, and they worked really well. We had a(n overly) complex domain model where most of the complexity was around managing a permissions model for access to resources. We tried a whole bunch of ways to represent the actions available to end users, but the only one that worked really well was to advertise a URI when you could do something, and to omit it when you couldn't. All the nightmarish logic was safely hidden behind the uniform interface. Clients only needed to know that they should follow links, and that the absence of a link meant that a resource wasn't available to them because reasons. It was a beautifully natural mapping of a difficult problem domain into a simple consumption model. As a bonus, we could change URI structures around when we felt like it, and our clients never missed a beat, because they always followed links from a well-known entry point. It's not always the right choice, there is plenty of room for simple RPC, but for workflows, and dynamic discovery of resources ReST works a treat.
  - picozeta 11y ago
    > The same arguments were made about object orientation: I've never needed it, it's useless baggage with no real world benefits, it sounds great in theory but has no practical use... And haven't this people been right? :) It was (and still is, but people are fortunately more skeptic) completely oversold like REST now.
    - isolate 11y ago

jcrites 11y ago

A person looking to understand "What is REST? What is a RESTful application?" would be well-served by considering websites rather than web services. Facebook, Amazon, and Hacker News are good examples of RESTful applications. You can enter them through their website roots with no prior knowledge beyond standard web media types like HTML/CSS. The site roots display some information, expose some functionality like search, and link to pages with more capabilities like to create an account. The search function is expressed as an HTML form, and when the user submits their search, the HTML spec tells the browser to navigate to a new URL composed from the search form fields. The search result page displays a list of hyperlinks to other resources, such as products on Amazon or people on Facebook. Navigating to those pages lets you discover information and hyperlinks to other resources such as a person's photos, related products, etc. The way a browser navigates through a website by following links is the classic example of a RESTful application, and is the meaning of "hypermedia as the engine of application state". Fielding also wrote a blog post clarifying REST and its constraints: http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hyperte... > A REST API should be entered with no prior knowledge beyond the initial URI and set of standardized media types that are appropriate for the intended audience. A REST API must not define fixed resource names or hierarchies (an obvious coupling of client and server). A REST API should never have “typed” resources that are significant to the client. Any effort spent describing what methods to use on what URIs of interest should be entirely defined within the scope of the processing rules for a media type Some confusion about REST seems to stem from misguided attempts to apply REST to scenarios for which it's not a good fit - scenarios where there is by necessity tight coupling in the form of mutual knowledge of specific data types and operations. Other confusion about the term "REST" comes from applying subset of its principles, resulting in a popular label that refers to a large spectrum of architectural styles. The Richardson Maturity Model helps organize these functionality subsets into levels that can be named and considered separately - services termed REST are sometimes level 1 or 2 in the Richardson model. http://martinfowler.com/articles/richardsonMaturityModel.html http://martinfowler.com/articles/richardsonMaturityModel.htm...

deleted 11y ago
[deleted]
stanleydrew 11y ago
Exactly. The problem is that, for some reason, people decided that an "API" should be "RESTful". Ruby on Rails put this idea into a lot of developers' heads. An API is probably the worst thing to try to make truly RESTful, in the full HATEOAS sense. Further confusion comes from the fact that some of the REST constraints are actually very useful in machine-to-machine API design. Thinking about a system in terms of a large number of resources operated on by a standard set of verbs is nice. Caching is nice. The un-bloating of HTTP bodies from the SOAP days is nice. I think there is some consensus that we can call that thing an "HTTP API" rather than a "REST API", which might start to clear up some of the confusion.
wstrange 11y ago
Sorry - the whole "REST is just like websites" thing drives me nuts. With the web, it is not the browser doing the navigation; It is very advanced AI wetware. It is hard to find widespread examples of machine to machine interaction based purely on RESTful discovery. I think REST is interesting - but at the end of the day, is it really all that different from other communication mechanisms?
- stanleydrew 11y ago
  But REST is just like websites. It's a term that was literally coined to describe the web, including websites and browsers. Why does it drive you nuts?
  - sopooneo 11y ago
    For me, it drives me nuts because zealots do a lot of handwaving to get from "the web itself is RESTful!" to "and it's the best possible way to build an API".
    - jcrites 11y ago

swax 11y ago

Even if REST was a standard and no one ever argued about it, I still wouldn't use it. It is needless overhead designed by a PhD to solve problems I haven't encountered for 15 years. API traversal sounds nice, but who uses it? Has the benefit been realized or is it still just theory? With a simple JSON RPC API I can still transmit objects representing state. Like you said it's not complicated. Has it crossed your mind that REST is maybe more trouble than it's worth?

bobfromhuddle 11y ago
The same arguments were made about object orientation: I've never needed it, it's useless baggage with no real world benefits, it sounds great in theory but has no practical use... I've built hypertext APIs, and they worked really well. We had a(n overly) complex domain model where most of the complexity was around managing a permissions model for access to resources. We tried a whole bunch of ways to represent the actions available to end users, but the only one that worked really well was to advertise a URI when you could do something, and to omit it when you couldn't. All the nightmarish logic was safely hidden behind the uniform interface. Clients only needed to know that they should follow links, and that the absence of a link meant that a resource wasn't available to them because reasons. It was a beautifully natural mapping of a difficult problem domain into a simple consumption model. As a bonus, we could change URI structures around when we felt like it, and our clients never missed a beat, because they always followed links from a well-known entry point. It's not always the right choice, there is plenty of room for simple RPC, but for workflows, and dynamic discovery of resources ReST works a treat.
- picozeta 11y ago
  > The same arguments were made about object orientation: I've never needed it, it's useless baggage with no real world benefits, it sounds great in theory but has no practical use... And haven't this people been right? :) It was (and still is, but people are fortunately more skeptic) completely oversold like REST now.
  - isolate 11y ago