8 ms·

REST is the definition of a buzzword. Vague. Useless. Everyone talks about it, but no one ever 'understands' it. You make your API REST not because you think i

by pixie_ 11y ago

REST is the definition of a buzzword. Vague. Useless. Everyone talks about it, but no one ever 'understands' it. You make your API REST not because you think it's good, but because everyone else does it. It's instant karma. Like XML was 10 years ago. Who cares if you have to make a lot of ugly confusing endpoints - at least you can call your API RESTful. I like how Dropbox bucked the trend and went with a simple POST based API. JSON parameters in. JSON response out. No complicated urls, strange headers, verbs, hateoas, etc.. https://www.dropbox.com/developers/documentation/http/documentation https://www.dropbox.com/developers/documentation/http/docume...

krainboltgreene 11y ago
> Everyone talks about it, but no one ever 'understands' it. There are people who understand it to varying degrees. Some who completely understand it and some who don't understand it at all. So no, it's not a buzzword, it's just a concept. PS. Dropbox's API requires a lot of hardcoding because of that very switch. Hardcoding that HATEOAS lets you avoid.
- tie_ 11y ago
  With REST we cannot truly define a degree of understanding. Such a definition would assume that multiple people know and agree on what would be the full extent of that understanding. The problem with REST is not the different amount of knowledge that people possess, but the different ideas that they have about REST. Which is another way to say that REST is not really a well defined protocol. (Have you seen similar vague posts titled "What IMAP4 actually means"?) Because it is not a well defined protocol, you cannot use the same client library to access random REST APIs. You use/write one library to access Twitter's REST and another to access Facebook's REST. You could argue that you use HTTP in both cases, but that's just the underlying transport protocol - not the API "language" itself. Because of that fact I blame REST for the millions of developers hours wasted in re-implementations of hundreds and thousands versions of the same "concept". The REST "idea" sure looks sexy when you put it next to an atrocity like SOAP, but that's one of its very few merits.
  - JimDabell 11y ago
    > Because it is not a well defined protocol, you cannot use the same client library to access random REST APIs. You misunderstand what REST is. It's not a protocol, it's an architectural style. Of course you can't build one client library to access arbitrary REST APIs – that's like complaining that you can't build an object-oriented library that can be used by any object-oriented language. REST does, in fact, have a precise definition that is possible to understand and agree on. It's here: https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arc...
- dllthomas 11y ago
  "So no, it's not a buzzword, it's just a concept." I think REST is quite clearly a buzzword. That doesn't mean it's not also a well defined concept; just that it's fashionable to use the term even when that concept doesn't apply very well.
- xamuel 11y ago
  Compare "quantum". Clearly a buzzword in many contexts, even though quantum physics is a legitimate thing. I've had the "pleasure" of working with big European consortiums where REST is very much a buzzword. I quickly realized that people were using the term as a synonym for "HTTP" for the purpose of making grant proposals and deliverable reports sexier. It's definitely a buzzword!
nbrempel 11y ago
Slack did the same thing which I really like - https://api.slack.com/methods https://api.slack.com/methods. I was just thinking about JSON RPC style APIs vs 'RESTful APIs. REST APIs are nice because they follow the data model so closely but there are so many cases in which I am trying to overload something to bend the pattern to my needs. Then again, Stripe seems to have created a fantastic API that handles many complicated cases so maybe it just requires more upfront thought - https://stripe.com/docs/api https://stripe.com/docs/api. I disagree that REST is a buzzword, though. I think that REST has become so popular because it's a very effective way to construct an API. afterthought: There are plenty of "RESTful" APIs that miss the mark on important concepts in the pattern. In this case, I would say - yes REST is worthy of the term buzzword.
jalfresi 11y ago
REST is one of those things were if you don't implement all of it, you won't really reap the benefits of all those architectural constraints combined. In your Dropbox example, any client will be bound to the Dropbox API. Consequently, Dropbox are now bound to each and everyone of those clients; they cannot make changes on the server side without breaking every client. This is what REST aims to provide - a safe way for the server to change as needed without breaking clients. Imagine if Dropbox registered a set of mime-types for each of the different resource representations. Those mime-type RFCs would describe how clients interpret the representations whilst simutainiously giving Dropbox the ability to change the server as they need without fear of breaking clients. This would be because clients would be foxing on how to process the media-types, not the API. The various interactions a client can make with a representation (regardless of the URL it came from) would be bound to the media-type e.g. rel-types for edit, upload, create etc which the RFC would describe the appropriate HTTP interactions e.g. POST a media-type of x to the url at rel-type "edit". However, I think the real reason that REST hasn't been adopted fully is that service providers like Dropbox have found that there advantages to binding client developers to their hardcoded APIs; the last thing Dropbox wants (and what REST would provide) is a standardised set of media-types and RFCs describing the interactions for a standardised way of interacting with an external cloud-based storage provider. It's just another form of lock-in, and reminded the cynic in me of the bad old days of MS Office document lock-in.
- drrogers 11y ago
  umm, can you cite a RESTful cloud storage API that's consistently implemented between providers? If Dropbox's API was RESTful would that save me any time using Google's competing API? By the way, all these platform provide SDKs for you anyway and that's usually a better way to use them. When you start playing with the APIs from lots of different cloud storage folks (Dropbox, OneDrive, Google Drive) you see that they vary widely in concepts and capabilities. REST or not building a client for one doesn't really make you closer to using another. Also Dropbox's old API was REST and it doesn't seem more portable (https://www.dropbox.com/developers-v1/core/docs https://www.dropbox.com/developers-v1/core/docs)
  - 11y ago
bobfromhuddle 11y ago
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...
cmrdporcupine 11y ago
The chief importance of REST is that for a while it put the emphasis back on the HTTP transport with its associated costs and semantics, and away from the constant attempts to turn everything into an object-oriented remote procedure call. In my experience hiding the existence of a network behind several layers of abstraction is a really bad idea.
ascotan 11y ago
I agree that most people just use REST as a buzzword today but don't really know what it is. As I remember REST was popularized by Rails a few years back. If you go back and look at the railsconf talk by Hansson in 2006 you can see that the Rails people just wanted something that handled CRUD operations. However, one of the drivers behind REST was to provide web services for machine to machine communication - something that was traditionally done by WSDL files in SOAP. The Rails people didn't really have much of a need for HATEOAS, because they were not interested in replacing WSDL files. Primarily they wanted to get away from the 800 pound gorilla that was SOAP services (that back in 2005 was what every Enterprise Java web app was doing). As a result the focus was primarily on PUT/GET/POST/DELETE. I've seen a lot of "REST" API's that are actually HTTP/RPC API's or quasi-REST API's that mix REST for simple things, but then begin exposing RPC calls as the developers ability to manage complexity breaks down. I've never seen anyone actually using HATEOAS yet (maybe i've been isolated??) Usually when your boss says "And it has to have a REST API!!" That means that 1. It must use the internet, 2. It must return JSON, 3. It uses URLs to do things. Basically if the above is true it's a RESTful API. I think that most developers actually believe that are making a REST API even when they are not - simply because they don't really know. Your right about being the new XML buzzword though. 10 years ago if you did web services having WSDL, XSTL, SOAP and XML on a resume meant you were the shiz. Today you have REST and AngularJS on your resume if you do web development. Meh :0
- emsy 11y ago
  > I've never seen anyone actually using HATEOAS yet Github AFAIK
ksikka 11y ago
If you showed Dropbox's RPC API to a REST advocate, they'd probably frown and tell you it's a terrible API because it's not RESTful. You could try to argue that it's not so bad for various reasons, but you still wouldn't be able to win the argument against an ardent REST advocate. But at the end of the day, Dropbox is probably going to be just fine with their RPC API. So what gives? Why should Dropbox care about REST? How would you sell the CEO on it? I'd love to read a follow up blog post called "What does REST buy you anyway". Related: https://xkcd.com/1270/ https://xkcd.com/1270/

by pixie_ 11y ago

krainboltgreene 11y ago

> Everyone talks about it, but no one ever 'understands' it. There are people who understand it to varying degrees. Some who completely understand it and some who don't understand it at all. So no, it's not a buzzword, it's just a concept. PS. Dropbox's API requires a lot of hardcoding because of that very switch. Hardcoding that HATEOAS lets you avoid.

tie_ 11y ago
With REST we cannot truly define a degree of understanding. Such a definition would assume that multiple people know and agree on what would be the full extent of that understanding. The problem with REST is not the different amount of knowledge that people possess, but the different ideas that they have about REST. Which is another way to say that REST is not really a well defined protocol. (Have you seen similar vague posts titled "What IMAP4 actually means"?) Because it is not a well defined protocol, you cannot use the same client library to access random REST APIs. You use/write one library to access Twitter's REST and another to access Facebook's REST. You could argue that you use HTTP in both cases, but that's just the underlying transport protocol - not the API "language" itself. Because of that fact I blame REST for the millions of developers hours wasted in re-implementations of hundreds and thousands versions of the same "concept". The REST "idea" sure looks sexy when you put it next to an atrocity like SOAP, but that's one of its very few merits.
- JimDabell 11y ago
  > Because it is not a well defined protocol, you cannot use the same client library to access random REST APIs. You misunderstand what REST is. It's not a protocol, it's an architectural style. Of course you can't build one client library to access arbitrary REST APIs – that's like complaining that you can't build an object-oriented library that can be used by any object-oriented language. REST does, in fact, have a precise definition that is possible to understand and agree on. It's here: https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arc...
dllthomas 11y ago
"So no, it's not a buzzword, it's just a concept." I think REST is quite clearly a buzzword. That doesn't mean it's not also a well defined concept; just that it's fashionable to use the term even when that concept doesn't apply very well.
xamuel 11y ago
Compare "quantum". Clearly a buzzword in many contexts, even though quantum physics is a legitimate thing. I've had the "pleasure" of working with big European consortiums where REST is very much a buzzword. I quickly realized that people were using the term as a synonym for "HTTP" for the purpose of making grant proposals and deliverable reports sexier. It's definitely a buzzword!

nbrempel 11y ago

Slack did the same thing which I really like - https://api.slack.com/methods https://api.slack.com/methods. I was just thinking about JSON RPC style APIs vs 'RESTful APIs. REST APIs are nice because they follow the data model so closely but there are so many cases in which I am trying to overload something to bend the pattern to my needs. Then again, Stripe seems to have created a fantastic API that handles many complicated cases so maybe it just requires more upfront thought - https://stripe.com/docs/api https://stripe.com/docs/api. I disagree that REST is a buzzword, though. I think that REST has become so popular because it's a very effective way to construct an API. afterthought: There are plenty of "RESTful" APIs that miss the mark on important concepts in the pattern. In this case, I would say - yes REST is worthy of the term buzzword.

jalfresi 11y ago

REST is one of those things were if you don't implement all of it, you won't really reap the benefits of all those architectural constraints combined. In your Dropbox example, any client will be bound to the Dropbox API. Consequently, Dropbox are now bound to each and everyone of those clients; they cannot make changes on the server side without breaking every client. This is what REST aims to provide - a safe way for the server to change as needed without breaking clients. Imagine if Dropbox registered a set of mime-types for each of the different resource representations. Those mime-type RFCs would describe how clients interpret the representations whilst simutainiously giving Dropbox the ability to change the server as they need without fear of breaking clients. This would be because clients would be foxing on how to process the media-types, not the API. The various interactions a client can make with a representation (regardless of the URL it came from) would be bound to the media-type e.g. rel-types for edit, upload, create etc which the RFC would describe the appropriate HTTP interactions e.g. POST a media-type of x to the url at rel-type "edit". However, I think the real reason that REST hasn't been adopted fully is that service providers like Dropbox have found that there advantages to binding client developers to their hardcoded APIs; the last thing Dropbox wants (and what REST would provide) is a standardised set of media-types and RFCs describing the interactions for a standardised way of interacting with an external cloud-based storage provider. It's just another form of lock-in, and reminded the cynic in me of the bad old days of MS Office document lock-in.

drrogers 11y ago
umm, can you cite a RESTful cloud storage API that's consistently implemented between providers? If Dropbox's API was RESTful would that save me any time using Google's competing API? By the way, all these platform provide SDKs for you anyway and that's usually a better way to use them. When you start playing with the APIs from lots of different cloud storage folks (Dropbox, OneDrive, Google Drive) you see that they vary widely in concepts and capabilities. REST or not building a client for one doesn't really make you closer to using another. Also Dropbox's old API was REST and it doesn't seem more portable (https://www.dropbox.com/developers-v1/core/docs https://www.dropbox.com/developers-v1/core/docs)
- 11y ago

bobfromhuddle 11y ago

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

cmrdporcupine 11y ago

The chief importance of REST is that for a while it put the emphasis back on the HTTP transport with its associated costs and semantics, and away from the constant attempts to turn everything into an object-oriented remote procedure call. In my experience hiding the existence of a network behind several layers of abstraction is a really bad idea.

ascotan 11y ago

I agree that most people just use REST as a buzzword today but don't really know what it is. As I remember REST was popularized by Rails a few years back. If you go back and look at the railsconf talk by Hansson in 2006 you can see that the Rails people just wanted something that handled CRUD operations. However, one of the drivers behind REST was to provide web services for machine to machine communication - something that was traditionally done by WSDL files in SOAP. The Rails people didn't really have much of a need for HATEOAS, because they were not interested in replacing WSDL files. Primarily they wanted to get away from the 800 pound gorilla that was SOAP services (that back in 2005 was what every Enterprise Java web app was doing). As a result the focus was primarily on PUT/GET/POST/DELETE. I've seen a lot of "REST" API's that are actually HTTP/RPC API's or quasi-REST API's that mix REST for simple things, but then begin exposing RPC calls as the developers ability to manage complexity breaks down. I've never seen anyone actually using HATEOAS yet (maybe i've been isolated??) Usually when your boss says "And it has to have a REST API!!" That means that 1. It must use the internet, 2. It must return JSON, 3. It uses URLs to do things. Basically if the above is true it's a RESTful API. I think that most developers actually believe that are making a REST API even when they are not - simply because they don't really know. Your right about being the new XML buzzword though. 10 years ago if you did web services having WSDL, XSTL, SOAP and XML on a resume meant you were the shiz. Today you have REST and AngularJS on your resume if you do web development. Meh :0

emsy 11y ago
> I've never seen anyone actually using HATEOAS yet Github AFAIK

ksikka 11y ago

If you showed Dropbox's RPC API to a REST advocate, they'd probably frown and tell you it's a terrible API because it's not RESTful. You could try to argue that it's not so bad for various reasons, but you still wouldn't be able to win the argument against an ardent REST advocate. But at the end of the day, Dropbox is probably going to be just fine with their RPC API. So what gives? Why should Dropbox care about REST? How would you sell the CEO on it? I'd love to read a follow up blog post called "What does REST buy you anyway". Related: https://xkcd.com/1270/ https://xkcd.com/1270/