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

Most RESTful APIs aren't really RESTful

florian-kraemer.net

Post reply on HN
Print view View original

101–110 of 580 posts

Re: Most RESTful APIs aren't really RESTful

#101

Post by draw_down »

JimDabell wrote: post #24
thom wrote: post #13

I struggle to believe that any API in history has been improved by the developer more faithfully following REST’s strictures. The closest we’ve come to actually decoupled, self describing APIs is MCP, and that required inventing actual AIs to understand them.

The most successful API in history – the World-Wide Web – uses REST principles. That’s where REST came from. It was somebody who was involved in the creation of the early web who looked at it and wrote down a description of what properties of the web made it so successful.

[dead]

Re: Most RESTful APIs aren't really RESTful

#102

Post by k2xl »

cjpearson wrote: post #40

I sympathize with the pedantry here and found Fielding's paper to be interesting, but this is a lost battle. When I see "REST API" I can safely assume the following: - The API returns JSON - CRUD actions are mapped to POST/GET/PUT/DELETE - The team constantly bikesheds over correct status codes and at least a few are used contrary to the HTTP spec - There's a decent chance listing endpoints were changed to POST to su…

This is very true. Over my 15 years of engineering, I have never suffered_that_ much with integrating with an api (assuming it exists). So the lack of "HATEOaS" hasn't even been noticable for me. As long as they get most of the 400 status codes right (specifically 200, 401, 403, 429) I usually have no issuss integrating and don't even notice that they don't have some "discoverable api". As long as I can get the data I need or can make the update I need I am fine.

I think good rest api design is more a service for the engineer than the client.

Re: Most RESTful APIs aren't really RESTful

#103

Post by ohdeargodno »

mixedbit wrote: post #47

When I was working on my first HTTP-based API 13 years ago, based on many comments about true REST, I decided to first study what REST should really be. I've read Fielding's paper cover to cover, I've read RESTful Web Services Cookbook from O'Reilly and then proceeded to workaround Django idioms to provide REST API. This was a bit cargo cult thinking from my end, I didn't truly understand how REST would benefit my se…

[dead]

Re: Most RESTful APIs aren't really RESTful

#104

Post by ohdeargodno »

sublinear wrote: post #18
Scarblac wrote: post #5

UI designers want control over the look of the page in detail. E.g. some actions that can be taken on a resource are a large button and some are hidden in a menu or not rendered in the UI at all. A client application that doesn't have any knowledge about what actions are going to be possible with a resource, instead rendering them dynamically based on the API responses, is going to make them all look the same. So RES…

My experience with "RESTful APIs" rarely has much to do with the UI. Why even have any API if all you care about is the UI? Why not go back to server driven crap like DWR then?

Because UI toolkit independent APIs are more flexible than just returning HTML, and considering only HTML means that you offer subpar experiences on most platforms. Not just mobile software, where web apps are awful, but also desktop, where your software doesn't integrate well with the platform if it's just a webpage.

Returning purely data means being able to transform it in any way you want, no matter where you use it. And depending on your usecase, it also means being able to sell access to it.

Re: Most RESTful APIs aren't really RESTful

#105

Post by osigurdson »

We collectively glazed over Roy Fielding's dissertation, didn't really see the point, liked the sound of the word "REST" and used it to describe whatever we wanted to do with http / json. Sorry, Roy, but you can keep HATEOAS - no one is going to take that from you.

Re: Most RESTful APIs aren't really RESTful

#106

Post by pradn »

> REST isn’t about exposing your internal object model over HTTP — it’s about building distributed systems that behave like the web.

I think I finally understand what Fielding is getting at. His REST principles boil down to allowing dynamic discovery of verbs for entities that are typed only by their media types. There's a level of indirection to allow for dynamic discovery. And there's a level of abstraction in saying entities are generic media objects. These two conceptual leaps allow the REST API to be used in a more dynamic, generic way - with benefits at the API level that the other levels of the web stack has ("client decoupling, evolvability, dynamic interaction").

Re: Most RESTful APIs aren't really RESTful

#107

Post by ohdeargodno »

porridgeraisin wrote: post #64
bravesoul2 wrote: post #20

Drake meme for me: REST = Hell No GQL = Hell No. RPC with status codes = Grin and point. I like to get stuff done. Imagine you are forced to organize your code filed like REST. Folder is a noun. Functions are verbs. One per folder. Etc. Would drive you nuts. Why do this for API unless the API really really fits that style (rare). GQL is expensive to parse and hides information from proxies (200 for everything)

> RPC with status codes Yes. All endpoints POST, JSON in, JSON out (or whatever) and meaningful HTTP status codes. It's a great sweet spot. Of course, this works only for apps that fetch() and createElement() the UI. But that's a lot of apps. If I don't want to use an RPC framework or whatever I just do: { method: "makeBooking", argument: { one: 1, two: "too", }, ... } And have a dictionary in my server mapping metho…

>All endpoints POST

This makes automating things like retrying network calls hell. You can safely assume a GET will be idempotent, and safely retry on failure with delay. A POST might, or might not also empty your bank account.

HTTP verbs are not just for decoration.

Re: Most RESTful APIs aren't really RESTful

#108

Post by eska »

cjpearson wrote: post #40

I sympathize with the pedantry here and found Fielding's paper to be interesting, but this is a lost battle. When I see "REST API" I can safely assume the following: - The API returns JSON - CRUD actions are mapped to POST/GET/PUT/DELETE - The team constantly bikesheds over correct status codes and at least a few are used contrary to the HTTP spec - There's a decent chance listing endpoints were changed to POST to su…

While I ask people whether they actually mean REST according to the paper or not, I am one of the people who refuse to just move on. The reason being that the mainstream use of the term doesn’t actually mean anything, it is not useful, and therefore not pragmatic at all. I basically say “so you actually just mean some web API, ok” and move on with that. The important difference being that I need to figure out the peculiarities of each such web API.

Re: Most RESTful APIs aren't really RESTful

#109

Post by lazyasciiart »

cjpearson wrote: post #40

I sympathize with the pedantry here and found Fielding's paper to be interesting, but this is a lost battle. When I see "REST API" I can safely assume the following: - The API returns JSON - CRUD actions are mapped to POST/GET/PUT/DELETE - The team constantly bikesheds over correct status codes and at least a few are used contrary to the HTTP spec - There's a decent chance listing endpoints were changed to POST to su…

Haha, our API still returns XML. At least, most of the endpoints do. Not the ones written by that guy who thinks predictability in an API is lower priority than modern code, those ones return JSON.

Re: Most RESTful APIs aren't really RESTful

#110

Post by thaumasiotes »

Traubenfuchs wrote: post #68

REST(ful) API issues can all be resolved with one addition: Adding actions to it! POST api/registration / api/signup? All of this sucks. Posting or putting on api/user? Also doesn‘t feel right. POST to api/user:signup Boom! Full REST for entities + actions with custom requests and responses for actions! How do I make a restful filter call? GET request params are not enough… You POST to api/user:search, boom! (I prefe…

What is the problem with posting to /user/signup that posting to /user:signup solves?
Post reply on HN