[voiceofunreason]

"REST is just pure bullshit. Avoid it like a plague."

No it isn't. Evidence: I'm reading this in a web browser.

"...REST is intended for long-lived network-based applications that span multiple organizations. If you don’t see a need for the constraints, then don’t use them."

Bikeshedding the spelling of resource identifiers? Or what "verb" should be used to express specialized domain semantics? Yeah, _that_ is certainly plague bullshit.

[cyberax]

> No it isn't. Evidence: I'm reading this in a web browser.

And you might not that this site is _not_ REST-ful. It's certainly HTTP, but not REST.

> Bikeshedding the spelling of resource identifiers? Or what "verb" should be used to express specialized domain semantics?

Or whether we want to use If-Modified-Since header or explicitly specify the condition in the JSON body. And 6 months later, with some people asking for the latter because their homegrown REST client doesn't support easy header customization on a per-request basis.

Or people trying (and failing) to use multipart uploads because the generated Ruby client is not actually correct.

There is _way_ too much flexibility in REST (and HTTP in general). And REST in particular adds to this nonsense by abusing the verbs and the path.

[robertlagrant]

> It's certainly HTTP, but not REST.

How isn't it RESTful? It's a single entrypoint using content types to tell the client how to interpret it, and with exploratory clues to other content in the website.

[cyberax]

The "R" letter means "Representational". It requires a certain style of API. E.g. instead of "/item?id=23984792834" you have "/items/comments/23984792834".

HN doesn't have this.

[robertlagrant]

Representational is to do with being able to deal with different representations of data via a media type[0]. There is stuff about resource identification in ReST, but it's just about being able to address resources directly and permanently rather than the style of the resource identifier:

> Traditional hypertext systems [61], which typically operate in a closed or local environment, use unique node or document identifiers that change every time the information changes, relying on link servers to maintain references separately from the content [135]. Since centralized link servers are an anathema to the immense scale and multi-organizational domain requirements of the Web, REST relies instead on the author choosing a resource identifier that best fits the nature of the concept being identified.

[0] https://ics.uci.edu/~fielding/pubs/dissertation/rest_arch_st...

[mvdtnz]

> "REST is just pure bullshit. Avoid it like a plague."

> No it isn't. Evidence: I'm reading this in a web browser.

REST is not HTTP endpoints and verbs.