Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Should we rebrand REST?

kieranpotts.com

Post reply on HN
Print view View original

141–150 of 154 posts

Re: Should we rebrand REST?

#141

Post by shrimpx »

andrewmcwatters wrote: post #104

This is all pedantry. I don't think I've ever talked to a developer who cares. All people care about is whether or not you have a sane API to work with over HTTP. It uses appropriate verbs, maybe, and has meaningful endpoints and request and response objects you work with, hopefully. You can make up a new acronym for it like "WNI" or Web Negotiation Interface, but it doesn't change anything that people care about. Th…

You and the article author basically agree but you insist that you can just say “hey let’s just get over it, guys!” instead of deconstructing it. But the root of the problem is a fundamental misunderstanding. It doesn’t work to just get over it when you don’t understand what “it” is.

Re: Should we rebrand REST?

#142

Post by shrimpx »

datavirtue wrote: post #131

Reminds me of OOP. "Misrepresentation of the REST architecture has spread so far and wide that "REST" has come to be informally understood as a synonym for "HTTP"." Misrepresentation of OOP has spread so far and wide that "OOP" has come to be informally understood as a synonym for using class based languages.

This is what happens to every umbrella term that covers a hodge podge of broad ideas and patterns. Nobody knows what OOP is because it’s a bullet list of a dozen concepts that varies with which OOP guru you ask. Similarly, REST is a long list of loose ideas and broad guidance.

Re: Should we rebrand REST?

#143

Post by goto11 »

aaron-santos wrote: post #64
goto11 wrote: post #43

Earlier quoted context omitted.

What is the problem with hard-coded URLs? It is certainly simpler than having to extract the URLs from some other request. If they don't change (and they shouldn't!) I don't see the problem.

Harded-coded URLs represent a larger API surface area. Hypermedia-driven APIs eg: HATEOAS permit the server to view URLs as an implementation detail. Some people and some problems benefit from APIs with large surface area. Some people and problems benefit from APIs with small surface area. I tend to like APIs with small surface areas because it means I don't have to drag along outdated endpoints across minor versions…

URLs are not supposed to change since a URL identifies a resource. It is weird arguing for HATEOS as a mitigation for breaking a more fundamental constraint of REST.

Re: Should we rebrand REST?

#144

Post by [deleted] »

Joker_vD wrote: post #52
goto11 wrote: post #51

Earlier quoted context omitted.

> Well the problem is exactly that they do change sometimes. Well they shouldn't! And if the API arbitrarily changes URLs around without reason, then surely they might also change the URL for the initial request.

> Well they shouldn't! If you treat them as public interface, they shouldn't, yes. But if you treat them as internal implementation details, they absolutely could. One can also think about it as static vs dynamic dispatch: you make an initial request, you get a vtable of "method name -> method pointer" as a part of response. Or you can hardcode the method pointers and make it the remote server's job to properly chose…

[deleted]

Re: Should we rebrand REST?

#145

Post by Joker_vD »

goto11 wrote: post #143
aaron-santos wrote: post #64

Earlier quoted context omitted.

Harded-coded URLs represent a larger API surface area. Hypermedia-driven APIs eg: HATEOAS permit the server to view URLs as an implementation detail. Some people and some problems benefit from APIs with large surface area. Some people and problems benefit from APIs with small surface area. I tend to like APIs with small surface areas because it means I don't have to drag along outdated endpoints across minor versions…

URLs are not supposed to change since a URL identifies a resource. It is weird arguing for HATEOS as a mitigation for breaking a more fundamental constraint of REST.

> URLs are not supposed to change since a URL identifies a resource

Strictly speaking, you're wrong: a URL specifies a location of the resource, and a mechanism for retrieving it. If the location of the resource changes, so would a URL.

Even without this philosophical argument, there is an actual practical issue that URLs do change all the time. Both HATEOAS and Persistent URLs are mechanisms to cope with that: HATEOAS proposes to write clients that instead of using hardcoded URLs would use late-bound URLs supplied by the origin server; PURL proposes to hide the origin server behind a proxy that would translate hardcoded URLs used by the clients to the current scheme and either proxy or redirect the requests.

The main problem with either solution is that URLs use domain names as their "authority" part, so whenever you lose control of the old domain, the "entry point" URL has to change and there is nothing much you can do about it.

Yes, I know that URLs (URNs, actually, IIRC) were supposed to be immutable and eternal, with redirects set up (and maintained somehow, by someone, forever) to point to the current locations, but that didn't work out for obvious reasons.

Re: Should we rebrand REST?

#146

Post by coldcoldground »

This gets my vote!

I've always felt a little silly to have "REST" included in my resume because too many job descriptions mentioned it as a requirement. Once during an interview, I couldn't resist to challenge the interviewer asking me about "RESTful APIs" that I had built in the past, and I explained pretty much the same thing to him. Thankfully, he was quite open to admit that what most people are doing is not REST.

Re: Should we rebrand REST?

#147

Post by spentu »

For years I have called my APIs "HTTP API" as they usually do not follow the abstract definition of the REST. And because I've seen so many APIs being called REST that barely follow any definition of a sane API.

The whole term is used by people as synonym for an API by management and by developers who never took closer look of the definition/paper.

I think that the situation is bit like in OOP, TDD and many other things that cause flame wars. When something good ideas come up, people tend to be religious about it. Instead of taking good ideas and utilize them for better solutions, we take things to extreme and fight about tiniest things.

Re: Should we rebrand REST?

#148

Post by slver »

unscaled wrote: post #107
slver wrote: post #55

Earlier quoted context omitted.

> What HATEOAS ostensibly gives you is not the ability to painlessly switch domains, but rather to change your entire URL path structure and even the entire schema represented by your REST endpoints. Which would be utterly pointless, because the fact this schema is opaque to the clients means that it's meaningless to the clients. So you have no reason to change it. > I've always worked all my API up to level 2 (HTTP…

While Level 3, as currently implemented by some APIs, is a cargo-culted version of Fielding's idea of HATEOAS, Level 1 and 2 of the model have some usefulness for some types of APIs. What you get by implementing what is called a "RESTful API" nowadays is something that is very different from the original concept of REST, but is still useful to some applications, over plain RPC. Let's unpack it. Fielding RESTful syste…

You keep calling it the system, as if rest gives scale and benefits to any system. No. It’s for large grained mostly static resources directly navigated by a user. I.e. the web.

Fielding never claimed this architectural style works for machine apis. And it doesn’t.

Re: Should we rebrand REST?

#149

Post by slver »

aaron-santos wrote: post #64
goto11 wrote: post #43

Earlier quoted context omitted.

What is the problem with hard-coded URLs? It is certainly simpler than having to extract the URLs from some other request. If they don't change (and they shouldn't!) I don't see the problem.

Harded-coded URLs represent a larger API surface area. Hypermedia-driven APIs eg: HATEOAS permit the server to view URLs as an implementation detail. Some people and some problems benefit from APIs with large surface area. Some people and problems benefit from APIs with small surface area. I tend to like APIs with small surface areas because it means I don't have to drag along outdated endpoints across minor versions…

Do you realize that without “constructing a url” you need to go through few roundtrips just to find the resource url you actually need?

You force your users through garbage you get support tickets like that. Instead of blaming the users, think why your great approach is actually problematic for them.

The single entry point has no benefits unless the api is multi-company, no one specifically hosts it. Is this the case? If no, your hateoas and single url approach is pure cargo cult.

Re: Should we rebrand REST?

#150

Post by goto11 »

Joker_vD wrote: post #145
goto11 wrote: post #143

Earlier quoted context omitted.

URLs are not supposed to change since a URL identifies a resource. It is weird arguing for HATEOS as a mitigation for breaking a more fundamental constraint of REST.

> URLs are not supposed to change since a URL identifies a resource Strictly speaking, you're wrong: a URL specifies a location of the resource, and a mechanism for retrieving it. If the location of the resource changes, so would a URL. Even without this philosophical argument, there is an actual practical issue that URLs do change all the time. Both HATEOAS and Persistent URLs are mechanisms to cope with that: HATEO…

Well if the API moves to a different domain name, HATEOAS will not help you one wit. You still need to hardcode the entry point.

I still don't see any reasonable scenario where an API would change the (site-relative) URL's without also changing the semantics of the API. And if the semantics change you would have to rewrite the client anyway.

In any case, if you change the URL's without changing the semantics you should respond 301 on the old URL, so even a client with hardcoded URL's would work correctly without the need for HATEOAS.

Post reply on HN