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

71–80 of 166 posts

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

#71

Post by qyv »

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…

In a lot of ways I think what you are saying is actually in line with what the article is saying: Most people don't actually understand REST and it is leading to a lot of poorly designed API's. Unfortunately, the zealots are often the worst offenders in propagating the misunderstandings. For instance:

> Surface area and complexity are a big deal. 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?

I disagree, REST does NOT encourage a CRUD interface for every single SERVER SIDE resource. Your rest resources should be modelled after the resources your CLIENT needs. You should not be designing your client resource models based on the underlying server models regardless of using REST, SOAP or some kind of roll-your-own system.

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

#72

Post by harryf »

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…

> I can't see how people think returning 404 for a "this product doesn't exist" is defensible.

To tell Google for example to stop sending traffic to this URL because it's gone.

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

#73

Post by danpalmer »

glifchits wrote: post #69
danpalmer wrote: post #42

Earlier quoted context omitted.

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.

> They claim that HTTP/REST does not scale in large and dynamic projects

This is my point, the blog post has a good HTTP/REST based answer for all or most of the criticisms Facebook has of it, which I think poses a challenge to Facebook.

> Given how strongly Relay/GraphQL is resonating with developers

I'm inclined to avoid appeal to the majority, after all, PHP is very popular.

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

#74

Post by mistermann »

thomasahle wrote: post #4

> 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?

As I was reading this I was trying to figure out how he missed the point so badly, I think your point does a good job of that.

The OP might benefit from adopting the strategy of when you see someone saying something crazy/stupid, stop and think before writing an inflammatory blogpost.

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

#75

Post by wonkaWonka »

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 too, am annoyed by those that harp on about /noun/verb ordering and semantics for RESTful URLs. I bite my thumb at them.

But REST is really dead simple awesomeness, when it fits into the activities you're trying to support. Reading blog articles, forum posts. Sure, why wouldn't you?

Complex analytics joins that converge NOSQL data and cc payment identities over time, for advertisers. No. Not for that.

Abortions for some, tiny flags for others!

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

#76

Post by Mickydtron »

alexmuro wrote: post #41

Jafar Husain does an excellent job of explaining some of the problems netflix has had with REST APIs and why you might want to take a different approach in his introduction to Falcor video. Falcor is tackling some of the same problems as graphql / relay but making trade offs at different points. https://netflix.github.io/falcor/starter/why-falcor.html A REST API may be the best decision for a lot of projects but Grap…

It's interesting to read the article with his presentation in mind. From a technical perspective, you should be able to just swap Netflix/Falcor in for Facebook/Relay in this article and have the arguments make about as much sense (They are both graphQL adjacent approaches to APIs that explicitly abandon RESTful principles). However, it seems to me that the article would be way less persuasive or interesting if you did that, because a lot of the intended force of the article relies on the premise "Facebook is evil", rather than the technology at hand. However, using "Facebook is evil" to prove "This thing that Facebook is doing is evil" is way less interesting than showing the latter just from technical details.

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

#77

Post by glifchits »

These people have been attacking Facebook for a long time now. First React, and now Relay/GraphQL. Their technical arguments were never strong. Claiming that existing technologies eg. DOM, HTTP/REST are good enough is not convincing (disclosure: I very much so buy Facebook's arguments).

But do they have a point in saying that Facebook is trying to control the web stack? I believe that Facebook are working to make the web better as a whole, but is this naïve? A better web for everyone helps big players like Facebook. Hopefully one day Facebook doesn't slowly start to close off these huge OSS projects.

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

#78

Post by s73v3r »

maratd wrote: post #68
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…

"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."

As an engineer working for the same company, I very much want to know, because I want to know if I did something wrong on my end, or if something is broken on your end.

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

#80

Post by jaaron »

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…

The point of the article is that REST, as originally described, DOES NOT encourage creating a CRUD interface for every single resource. That's very typical for the simplistic Rails-style of REST, but that's not the original intent.

And that's just the point and why those of us who care about web-friendly API design get a bit "zealous." Imagine, if you will, that someone's complete argument about the pros and cons of JavaScript were based on pre-node, hell, pre-JQuery use cases. Wouldn't you expect some developers to be a bit upset that you're mischaracterizing an entire programming language?

Keep in mind, a lot of what REST is known for today came to pass as a backlash against XML-deathstar-style architectural designs for web services over 10 years ago. At the time, plenty of folks were simply porting ideas and designs from CORBA-style RPC architectures over to the web. While this is possible, you lose all sorts of advantages of an internet-centric design. And that's really what REST is about: designing applications that work with the web, not against it.

Post reply on HN