Re:API Design Guide
by paulddraper on Wednesday February 22, 2017 @08:01PM
(#13710752)
Yes, but most people aren't making web browsers or similar.
Web browsers are extremely generalized: they display arbitrary HTML, submit arbitrary forms, download arbitrary images, download and run arbitrary JS/CSS.
Most APIs are intended for more specific uses than "all of HTML". Hypermedia is very useful for browsers, but I wouldn't extend that to say, my Imgur clone API.
Re:API Design Guide
by dragonwriter on Wednesday February 22, 2017 @08:46PM
(#13710949)
> Yes, but most people aren't making web browsers or similar.
The question is whether people are making APIs to be consumed by general purpose tools, not whether they are making general purpose tools.
But, yes, there's a quite valid argument that REST isn't always the right architectural style for an API.
Which isn't an excuse to use the term "REST" for things that aren't REST, which just confused the issue.
Re:API Design Guide
by paulddraper on Wednesday February 22, 2017 @09:51PM
(#13711240)
Okay, either way. There aren't a lot of hypermedia-based clients.
Have you ever used a web browser? You know how the browser uses media-type to determine how to handle content referenced by a URI? That's what HATEOAS is supposed to be useful for: links identify and locate resources, resource type information tells you what kind of resource it is. The only out-of-band information you should need for an idealized REST API is information on the protocol used (e.g., HTTP) and information on the resource types (media types for HTTP) of the resources used.
(Really, if you want to understand any component of REST, its probably easiest to ask "what is this used to accomplish in the HTTP-based web", since REST is essentially a generalization of an idealized version of the HTTP-based web.)