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

111–120 of 166 posts

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

#111

Post by rdeboo »

maratd wrote: post #106
s73v3r wrote: post #78

Earlier quoted context omitted.

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

Even an internal API should be designed with the same principles as an external one, because through security error, it may end up being exposed. When designing an API, certain conditions must return a 404 with no further explanation given. These are purely security concerns. If you try to login with an email and a password, I will return a 404 with no further explanation if the auth request fails. Even if the email…

> If you try to login with an email and a password, I will return a 404 with no further explanation if the auth request fails.

Auth is something different. You should return a 401 with no additional information indeed.

However, the point is that as an API client, you want to be able to distinguish between "this bookshelf does not contain book X" and "what are you talking about, there is no bookshelf here".

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

#112

Post by sergiosgc »

pixie_ wrote: post #102
qyv wrote: post #71

Earlier quoted context omitted.

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'…

It does encourage more endpoints because I can't include data from two different objects in a response. They should be GET separately. With highly relational data where I need to create an endpoint that returns information regarding 50 different object types, how should I do that? My rolled up response is no longer REST. When I need to act on that data and call an API that can do a variety of CRUD operations to 50 di…

Nonsense. A URL is a resource endpoint. If a resource is a composition of other resources, it is perfectly acceptable to return all composed resources.

Let's try an example: A shopping application, with customers, products and orders. An order composes a customer and all products that were ordered. You'd have endpoints for retrieving a customer (/customer//), a product (/product//) and an order (/order//). When retrieving the order, nothing in REST prohibits you from returning full information about the user and about the products.

Now, advancing the discussion, the reverse complaint is that it is wasteful returning a full information complement when GETting an order. Easy peasy. Just use proper mime types and an Accepts header. Pass in "Accepts: application/json+order+deep" or "Accepts: application/json+order+plain" from the client side signaling the kind of response you want from the server.

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

#113

Post by carsongross »

mvdanj wrote: post #105

Interesting how this article was #1 on HN a few hours ago and mysteriously disappeared. Conspiracy?

Flag killed.

The unanimity of the commentary on the article (which was ranty, but had some reasonable points to make) is disturbing as well. No one is willing to take the other side of the argument?

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

#114

Post by bmn_ »

aikah wrote: post #90

While I'm anti Relay/GraphQL/co , I see a problem right here : > Blaming REST For The Non-RESTfulness Of Fake "REST" As I said in another thread here, people don't get what REST is because the original paper has done (IMHO) a poor job as explaining what it is about,masking simple concepts behind complicated sentences (academia style). Instead of being pedantic,arrogant and borderline insulting , which is unnecessary…

> the original paper has done (IMHO) a poor job as explaining what it is about

Please read " rel="nofollow">http://roy.gbiv.com/untangled/2008/specialization>. The paper is for experts. Non-experts can learn from a suitable technology book instead.

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

#115

Post by bmn_ »

carsongross wrote: post #113
mvdanj wrote: post #105

Interesting how this article was #1 on HN a few hours ago and mysteriously disappeared. Conspiracy?

Flag killed. The unanimity of the commentary on the article (which was ranty, but had some reasonable points to make) is disturbing as well. No one is willing to take the other side of the argument?

There was apparently only a 30 minute window to do so. HN moves too fast for nuanced counter-replies to the commentary. If I just made a top-level comment, it would say something along "I agree in broad strokes", which is not that useful.

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

#116

Post by bmn_ »

intrasight wrote: post #79

Author says "they made a series of claims about why REST is broken" - without making "claims" be a hyperlink to those original claims. So this whole piece lacks semantic context and is therefore a fail.

You are mistaken. Near the end there is a hyperlink to the claims document. It is titled "Facebook's terrible post" and points to the URL " rel="nofollow">https://facebook.github.io/react/blog/2015/05/01/graphql-int....

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

#117

Post by carsongross »

bmn_ wrote: post #115
carsongross wrote: post #113

Earlier quoted context omitted.

Flag killed. The unanimity of the commentary on the article (which was ranty, but had some reasonable points to make) is disturbing as well. No one is willing to take the other side of the argument?

There was apparently only a 30 minute window to do so. HN moves too fast for nuanced counter-replies to the commentary. If I just made a top-level comment, it would say something along "I agree in broad strokes", which is not that useful.

And, from the looks of it, you would have been downvoted into oblivion for your trouble.

So there was a zerg rush of negative ad hominem on the article and then it was flag killed despite being a reasonable technical topic to discuss. Good times, good times.

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

#118

Post by mrighele »

sergiosgc wrote: post #112
pixie_ wrote: post #102

Earlier quoted context omitted.

It does encourage more endpoints because I can't include data from two different objects in a response. They should be GET separately. With highly relational data where I need to create an endpoint that returns information regarding 50 different object types, how should I do that? My rolled up response is no longer REST. When I need to act on that data and call an API that can do a variety of CRUD operations to 50 di…

Nonsense. A URL is a resource endpoint. If a resource is a composition of other resources, it is perfectly acceptable to return all composed resources. Let's try an example: A shopping application, with customers, products and orders. An order composes a customer and all products that were ordered. You'd have endpoints for retrieving a customer (/customer/ /), a product (/product/ /) and an order (/order/ /). When re…

> Pass in "Accepts: application/json+order+deep" or "Accepts: application/json+order+plain" from the client side signaling the kind of response you want from the server.

This is an interesting approach, but I'm wondering how this interacts with caching: how does the client properly differentiate between the two calls ? (I guess the 'Vary:' header has something to do with this, but I never used it directly).

Also, why change the content type when one could just add some query string parameters? With many libraries, both client and server side, this is probably easier to do.

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

#119

Post by kisstheblade »

bmn_ wrote: post #109
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…

> 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 Does not follow. People spend so much time debating what is and what isn't REST because there are a great number of people who do not understand the topic, have no actual interest in learning it properly, and then come to wrong conclusions and start making wildly inaccurate arguments. Not…

> ⁇ If the server returned 404, the server returned 404. This means the client application/the user agent made a mistake, indicated by the leading digit 4.

Or the endpoint wasn't configured properly even though the client had the right address. Happens often when developing, maybe another developer changed the endpoint url? Or in production some endpoint hasn't started. (yes this problem is seldom a problem in production or you usually know from other things that the problem is at the server, annoying still)

I've had problems with not knowing if 404 is "person not found" type error or "endpoint address is plain wrong"

"Bad Request" doesn't describe the situation either very well, I've used it myself to eg. signal missing mandatory parameters.

But just using eg. the code 200 as someone suggested and returning your own status message seems a little bit overkill.

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

#120

Post by eggie »

dustingetz wrote: post #64
eggie wrote: post #49

Earlier quoted context omitted.

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 misre…

As someone with a bit more experience with these technologies, would you please describe what GraphQL actually has to do with graphs? I work with very, very large graphs. I looked at GraphQL to see if it could be of use, but as far as I can understand the graph aspect of GraphQL is marketing multiplied by doublespeak. RDF and Sparql seem to be much more apt systems in this space. So I would appreciate if you opined biased to disillusion my confusion.
Post reply on HN