It's time to put REST to rest • Hacker News Board

Re: It's time to put REST to rest

#11

Post by JohnMakin » Thu, Dec 28, 2023, 9:23 PM UTC

> About being able to use a RESTful API directly from a browser: browsers only use the GET and POST HTTP methods, among the ones REST associates meaning to. You cannot use a RESTful API from the browser, because the PUT, PATCH, and DELETE methods are not used by the browser, and even the POST method cannot be used without a UI. Also, even if you could, APIs are for machines, not humans. The user experience would be dreadful if you had to use a RESTful API directly from a browser, without a specific UI for it.

This.. isn't true?

Re: It's time to put REST to rest

#12

Post by TOGoS » Thu, Dec 28, 2023, 9:24 PM UTC

> I even used HATEOAS principles when building HTTP APIs

I found your problem.

> About being able to use any API without understanding it first

That's a HATEOAS thing, as I understand it. REST just means that you have resources and verbs, and the verbs have ~relatively~ consistent meaning. If I see some GETs and PUTs and PATCHes and DELETEs I can get a pretty good idea of what's going on. It doesn't mean I understand all the details of your application logic.

Re: It's time to put REST to rest

#13

Post by munk-a » Thu, Dec 28, 2023, 9:24 PM UTC

One point this article objects to is the (ab?)use of HTTP status codes for indicating object status (i.e. 404 Your student doesn't exist). HTTP status codes are an extremely loose and flexible standard and I think that semantically most of the "RESTful" uses here are perfectly in line with expectations. Shift your thinking for a moment to consider that instead of `/user/12` linking to a script it's actually just a flat file containing some information about the user - the 404 response when the user doesn't exist is perfectly reasonable. The requestor shouldn't really care whether the request was fulfilled by apache checking file existence or some PHP script. In fact, webservers are just another kind of dynamic responder and it's important not to mystify their internal workings.

Re: It's time to put REST to rest

#14

Post by hinkley » Thu, Dec 28, 2023, 9:24 PM UTC

baq wrote: post #2

https://en.wikipedia.org/wiki/XML-RPC (1998)

Are you offering an alternative or inviting gratitude by pointing out that things could be much worse?

Re: It's time to put REST to rest

#15

Post by angilly » Thu, Dec 28, 2023, 9:24 PM UTC

As a REST enthusiast I was excited to read this and learn a new perspective but this section

> The “benefits” REST is supposed to introduce

Is one of the more egregious straw men I’ve seen in a while. Never once in my twenty years have I heard anyone say it’s nice because “you don’t have to read the docs” or “it works in a browser”

REST helps with lots from thinking through clean data models to helping ensure consistency within an API.

Re: It's time to put REST to rest

#16

Post by munk-a » Thu, Dec 28, 2023, 9:25 PM UTC

JohnMakin wrote: post #11

> About being able to use a RESTful API directly from a browser: browsers only use the GET and POST HTTP methods, among the ones REST associates meaning to. You cannot use a RESTful API from the browser, because the PUT, PATCH, and DELETE methods are not used by the browser, and even the POST method cannot be used without a UI. Also, even if you could, APIs are for machines, not humans. The user experience would be d…

It's kinda true if you're thinking purely about submitting requests through `` elements - but even then you can bend browsers to support other verbs.

Re: It's time to put REST to rest

#17

Post by stronglikedan » Thu, Dec 28, 2023, 9:26 PM UTC

JohnMakin wrote: post #11

> About being able to use a RESTful API directly from a browser: browsers only use the GET and POST HTTP methods, among the ones REST associates meaning to. You cannot use a RESTful API from the browser, because the PUT, PATCH, and DELETE methods are not used by the browser, and even the POST method cannot be used without a UI. Also, even if you could, APIs are for machines, not humans. The user experience would be d…

> without a specific UI for it

None of my browsers seem to have PUT, PATCH, and DELETE baked into the standard UI (or even POST really), so maybe it is true?

Re: It's time to put REST to rest

#18

Post by simonw » Thu, Dec 28, 2023, 9:26 PM UTC

I agree with some of this - I've never found value in the different PUT/PATCH/etc verbs, and I think the lack of examples of good "pure" REST APIs indicates that pure REST doesn't work easily for most projects.

I do think this throws away some pieces that are really valuable though:

1. URLs for concepts are a good idea

2. Distinguishing between read-only operations (which can be cached) and write operations using GET and POST verbs is useful

Personally I've found myself settling on "REST-ish" JSON APIs:

- Every domain concept has a URL, and a standard consistent JSON representation that's also returned by list endpoints

- GET for read operations, POST for anything that performs a write

- I don't like content negotiation via the Accept header, so instead if I need to support alternative representations I'll do that using file extensions, .json vs .csv for example

Re: It's time to put REST to rest

#19

Post by dimitrios1 » Thu, Dec 28, 2023, 9:26 PM UTC

anamexis wrote: post #4

If I had to guess, the comments here are going to revolve around "that's not REST" and "where's the hypermedia." I think that ship has sailed. REST in practice just means following HTTP semantics.

Exactly. If you ditch the bikeshedding and no true scot arguments, REST is just a loosely defined naming convention around HTTP verbs, that almost every company I have been apart of agrees on / disagrees on certain minor aspects. That being said, I am thankful that we moved to using some form of "REST" (however you define it) as it was infinitely better than WSDL/SOAP. gRPC is nice in some areas, but these days I find myself doing what the article says more often than not -- just creating business-definition specific resources that utilize GET/POST and JSON.

Re: It's time to put REST to rest

#20

Post by user3939382 » Thu, Dec 28, 2023, 9:26 PM UTC

munk-a wrote: post #16

JohnMakin wrote: post #11

> About being able to use a RESTful API directly from a browser: browsers only use the GET and POST HTTP methods, among the ones REST associates meaning to. You cannot use a RESTful API from the browser, because the PUT, PATCH, and DELETE methods are not used by the browser, and even the POST method cannot be used without a UI. Also, even if you could, APIs are for machines, not humans. The user experience would be d…

It's kinda true if you're thinking purely about submitting requests through ` ` elements - but even then you can bend browsers to support other verbs.

There are multiple RFCs with lists of HTTP verbs and axios only supports the more limited set, which for my particular legacy project meant I couldn't use any of the creative ones.