11–20 of 166 posts
If I were FB, I'd only feel compelled to use REST for a public API. Otherwise, I'd use the best tool for the job.
On the other hand I've never seen an API in the wild that I felt would really satisfy a REST purist. In theory, it'd be great to be able to stick a dumb HTTP cache in front of your app and have that solve all your performance and scalability problems. In practice, you have to sacrifice too much.
"REST does a shitty job of efficiently expressing relational data. ... I mean REST has its place. For example, it has very predictable performance and well-known cache characteristics. The problem is when you want to fetch data in repeated rounds, or when you want to fetch data that isn't expressed well as a hierarchy (think a graph with cycles -- not uncommon). That's where it breaks down. I think you can get pretty far with batched REST, but I'd like to see some way to query graphs in an easier way."
-- Pete Hunt in 2013, when he worked at Facebook on React: https://news.ycombinator.com/item?id=7600565
I have a problem taking seriously any article that spreads FUD by accusing their targets of spreading FUD. The people who build React and the related ecosystem are incredibly smart people trying to make the web better. I'm certain there's no ill-intent in their motives. Regardless, they open source pretty aggressively. If an open technology from Facebook displaces another open technology from another source, I don't…
To me it is like sending a SQL query to the backend and instead of getting rows back you get objects nested in a way you specify.
The problem when using REST "correctly" is that the way your objects interrelate is not necessarily the same way on the backend as it is on the UI. So you end up creating custom REST endpoints for complicated UI that does not map directly to how your objects are related in the database.
This article has no substance in how they want to solve it besides just spouting "use REST correctly".
fwiw, pandastrike seems to be on a crusade against all things Facebook/React so take this with a grain of salt. https://twitter.com/vjeux/status/655128064754499588
> a REST endpoint can return whatever you want. If you only want a subset of that graph, make an endpoint around that subset. So we have to make endpoints around every possible subset? > You want to avoid large object graphs anyway, for two reasons. Returning coarse-gained chunks of data tends to work against effective caching strategies, whether you're using REST, Relay, or anything else. You have to cache the whole…
"So we have to make endpoints around every possible subset?" No, you use the query in querystring. One way or another you're offering a query interface. A lot of REST is just about how you offer the same interfaces you were planning on offering anyhow. Which is probably a source of a lot of the frustration REST advocates experience. If you're genuinely doing something that REST can't do very well, OK then, but if you…
Ok, but doing that straight on top of HTTP, will only cache queries that are exactly equal to previous ones. Not queries that are a subset of previous queries.
> a REST endpoint can return whatever you want. If you only want a subset of that graph, make an endpoint around that subset. So we have to make endpoints around every possible subset? > You want to avoid large object graphs anyway, for two reasons. Returning coarse-gained chunks of data tends to work against effective caching strategies, whether you're using REST, Relay, or anything else. You have to cache the whole…
s/catch/cache/ ?