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

Facebook Relay: An Evil And/Or Incompetent Attack on REST

pandastrike.com

Post reply on HN
Print view View original

61–70 of 166 posts

Re: Facebook Relay: An Evil And/Or Incompetent Attack on REST

#61

Post by danpalmer »

Does anyone know of really good REST APIs?

I feel like a lot of people talk about REST being better or worse than other technologies, but I haven't seen a single 'perfect example' of a REST API. If that's because it's impossible to make one, then that clearly tells us something, but I can't see any reason why we couldn't make one, it just seems that no one does.

By "really good", I mean something that includes HATEOAS, versioning, uses content types correctly, utilises caching properly (probably HTTP 2 only with server-push, but still), etc etc.

Re: Facebook Relay: An Evil And/Or Incompetent Attack on REST

#62

Post by TheCoelacanth »

Complete strawman. Facebook is quite clear that GraphQL is designed to address weaknesses in REST as it is typically implemented, not weaknesses in the actual concept of REST.

> We are interested in the typical attributes of systems that self-identify as REST, rather than systems which are formally REST.

Re: Facebook Relay: An Evil And/Or Incompetent Attack on REST

#63

Post by forrestthewoods »

Sometimes an API can do something, but doesn't it make it easy. An alternative that makes it easy isn't just a little valuable, it's a lot a valuable.

This also applies to correctness. An API that can do something may be a bit of smashing a square peg through a round hole. An alternative that is round peg through a round hole is much better.

I don't know enough to say what this situation looks like.

Re: Facebook Relay: An Evil And/Or Incompetent Attack on REST

#64

Post by dustingetz »

eggie wrote: post #49
dustingetz wrote: post #13

Here's a quote which I think well describes Facebook's stance on REST, before GraphQL and Relay were public. This is the idea that motivated GraphQL and Relay. "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…

A query on a graph or a tree can both be RESTful. You can describe traversals of the graph or tree in a query embedded in an HTTP endpoint. You don't need to make repeated round trip queries to do the traversal unless you are unwilling to use a suitable query description. Metaphorically this is all pretty funny becuase the web is already a graph at a fundamental level.

The problem is that traversing a HATEOAS graph (like the www) requires a request at each edge. (The query is only the entry point to the graph, it doesn't help you traverse the graph. Relational joins make it so you don't need to traverse the graph, but this requires a lot of custom endpoints that bake in up-front knowledge about which nodes of the graph will need to be pre-fetched)

edit: Either you edited or I misread, but "You can describe traversals of the graph or tree in a query embedded in an HTTP endpoint" - this is basically what GraphQL/Relay is: an easy way to do arbitrarily nested or recursive queries, like those you find in real complex applications.

(Plug: I am a React consultant, hire me!)

Re: Facebook Relay: An Evil And/Or Incompetent Attack on REST

#66

Post by catshirt »

in 6 years here this is the first post i felt compelled to comment on without even reading the article. the comments here reinforce my decision...

if you have read the GraphQL docs, and built a sufficiently complex REST API, there is literally, technically speaking, no way to support this claim.

still i skimmed the article... it must be satire.

Re: Facebook Relay: An Evil And/Or Incompetent Attack on REST

#67

Post by _delirium »

usaar333 wrote: post #29

Why is this upvoted so much? It's a complete strawman. Facebook's own intro at https://facebook.github.io/react/blog/2015/05/01/graphql-int... states: "There is actually much debate about what exactly REST is and is not. We wish to avoid such debates. We are interested in the typical attributes of systems that self-identify as REST, rather than systems which are formally REST." "We believe there are a number of weakn…

To me that's a weaker point of page. I'd rather read about why Facebook couldn't design a REST API that meets their needs, not why some sampling of "typical" REST APIs in the wild doesn't have the characteristics they want. Sure, they might not, but can FB build a REST API that does have the characteristics they want? The answer could still be no, of course.

Re: Facebook Relay: An Evil And/Or Incompetent Attack on REST

#68

Post by maratd »

pixie_ wrote: post #45

I deal with REST zealots like this everyday :( just the fact that people spend so much time debating what is and what isn't REST should be a red flag that maybe it isn't the answer to everything. All the simple REST examples make it look like it is the perfect solution for CRUD tasks. But in reality API endpoints are not a straight pass through to the database. An endpoint may do any combination of CRUD tasks, it can…

> Overloading HTTP error codes is another interesting problem. If the server returns 404 for a resource, what actually happened?

I, the dude who made the API, sent you a 404. I sent you a 404 because that's all I wanted you to know. What actually happened is none of your business.

If I wanted you to know, I would have sent a 400 with an explanation attached. But I didn't. Because in this particular case, it was none of your business. 404.

> REST encourages creating a CRUD interface for every single resource. I've met people who have created literally 100 endpoints upfront for a small application - how is that maintainable?

Why are you making your endpoints by hand? Use a framework where you can define models for your resources and have the framework create everything automatically.

If you do need unique code for each of those models ... you don't have a small application on your hands.

> I like that Facebook is standing up to the zealots.

Are they, though? Or are they baking something that is uniquely suited to their own needs?

Re: Facebook Relay: An Evil And/Or Incompetent Attack on REST

#69

Post by glifchits »

danpalmer wrote: post #42
jtchang wrote: post #16

This article is a load of bullshit. When Facebook announced Relay it made immediate sense to me. The problem of fetching the right data from the backend is a pain in the ass for anyone that has built more than a simple todo app. 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…

Actually, they mention using content type negotiation for versioning, content types as a type system, HTTP caching for speed and reducing the number of requests, and lots more solutions. The article actually makes some well reasoned points, and I think poses a very good challenge to what Facebook are doing.

I don't think Facebook ever claimed that HTTP was insufficient. They claim that HTTP/REST does not scale in large and dynamic projects, and Relay/GraphQL solves some of those scaling concerns. Given how strongly Relay/GraphQL is resonating with developers, I would tend to agree that the raw HTTP way of solving these things (as you note above) are not good enough for the needs of most projects.

Re: Facebook Relay: An Evil And/Or Incompetent Attack on REST

#70

Post by neilellis »

sbov wrote: post #60
pixie_ wrote: post #45

I deal with REST zealots like this everyday :( just the fact that people spend so much time debating what is and what isn't REST should be a red flag that maybe it isn't the answer to everything. All the simple REST examples make it look like it is the perfect solution for CRUD tasks. But in reality API endpoints are not a straight pass through to the database. An endpoint may do any combination of CRUD tasks, it can…

I agree with pretty much all of this. We developed an API because we had desktop/mobile/website. They all use the same API. I call it REST-ish. I can't see how people think returning 404 for a "this product doesn't exist" is defensible. You now have two different things intertwined: this product doesn't exist (generally not a huge deal - what if an end user manually edits the url on your storefront?), and this url ma…

HTTP error codes are something of an embarrassment to the web.

We have more codes for April Fools jokes than some of our most common situations we deal with. We have some bizarrely specific codes like Payment Required and Requested Range Not Satisfiable yet almost all real world application responses get dumped into 400, 500 and a few other codes.

How about more specific and useful codes like:

Parameter not Supplied, Parameter Name Invalid, Parameter Value Invalid, Url Path Invalid Format, Could Not Parse Data etc. etc.

This would also allow client libraries to decide better on how to process errors (i.e. as application or systemic errors).

I'm sure folk have better suggestions than I but I can't imagine many folk genuinely feel these existing codes are expressive for the modern (API centric) web.

Post reply on HN