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

121–130 of 166 posts

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

#121

Post by Mickydtron »

qyv wrote: post #51
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…

> 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. Not defending the article here, but I don't see this as a problem at all. Yes, you API objects should not necessarily map directly…

You are exactly correct about the role of the API here. A problem arises once you have multiple clients, each with different views, as well as different versions of those views. You can end up with a proliferation of API endpoints, each serving a custom view object for each different type of view, or you make your endpoints generic enough to serve all views, thus serving more data than any one view will ever use. You'll naturally have a tension between endpoint reusability and specific usefulness. The article actually seemed to have some of that tension itself, saying both "If you only want a subset of that graph, make an endpoint around that subset." and also "[Ad hoc endpoints] aren't REST", without giving any guidance as to how to make endpoints around arbitrary subsets of graph data without descending into being ad hoc. I'm not saying that you can't balance these with a good REST API, just that there is a real tension.

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

#122

Post by LukeB_UK »

carsongross wrote: post #103

How did this article get flag killed? I wanted to say something constructive about the topic: Any time you layer an arbitrary UX over a given data model, expressiveness is absolutely necessary in the protocol in order to minimize round trips. This is why SQL has been so successful on the server side. An alternative to the "moving the whole graph to the client side" approach is the intercooler.js way [ http://intercoo…

You should probably mention that you're the main contributor to intercooler.js. I've noticed quite a few comments from you plugging intercooler.js but with no mention of the fact that it's your project.

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

#123

Post by carsongross »

LukeB_UK wrote: post #122
carsongross wrote: post #103

How did this article get flag killed? I wanted to say something constructive about the topic: Any time you layer an arbitrary UX over a given data model, expressiveness is absolutely necessary in the protocol in order to minimize round trips. This is why SQL has been so successful on the server side. An alternative to the "moving the whole graph to the client side" approach is the intercooler.js way [ http://intercoo…

You should probably mention that you're the main contributor to intercooler.js. I've noticed quite a few comments from you plugging intercooler.js but with no mention of the fact that it's your project.

Sure: I am the main contributor to intercooler.js, I use it every day in production and, when it is relevant to a given article, I mention it.

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

#124

Post by neilellis »

joshstrange wrote: post #83
neilellis wrote: post #70

Earlier quoted context omitted.

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

Agreed, the codes are a crap-shoot. We are working on a redesign of our API and I've pushed for always returning a 200 with a defined JSON structure of something along the lines of: { "status": true "data": { ... } } for success and { "status": false "errorCode": 123, "errorMessage": " ... " //Only shown in dev/debug mode } for failures. We haven't nailed it all down yet but there was no way I was going to do HTTP st…

I think for application status codes it makes sense to always return 200 and do as you have done.

Of course, if your API has received bad data then better to return a 400 and a similar payload.

And if your application has caught an exception which is not part of any form of validation then better to return 500 and the payload.

Got to do the best we can with the hand we're dealt hey!

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

#125

Post by maratd »

rdeboo wrote: post #111
maratd wrote: post #106

Earlier quoted context omitted.

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

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

Yup, that's better.

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

I suppose you can return a 403 if it's something you shouldn't be accessing, but then you're bleeding information. You're letting the client know that it exists, but they don't have permission to access it.

A scheme that checks for permissions first and defaults to 403 when they're insufficient regardless of the existence of the resource would work though.

I guess it depends on how you implement the entire system.

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

#126

Post by thomasahle »

jerf wrote: post #37
thomasahle wrote: post #19

Earlier quoted context omitted.

> No, you use the query in querystring. 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.

I think you have to be careful not to be too cavalier with the word "cache" there. While REST is sort of vaguely concerned with the ability to cache in the general sense, in real life we have to be specific about what is doing the caching. This is the sort of dynamic query you'd normally tell intervening proxies not to cache anyhow, so now we can reduce our concerns to the client and the server specifically. On the c…

I was thinking of a large graph, where everybody wanted different parts. Then a cache somewhere in the middle could work, even if nobody wanted exactly the same parts.

However I guess you could achieve the same by sending many parallel requests.

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

#127

Post by steinnes »

devtique wrote: post #100

REST is one of the worst tech religions ever created yielding the most blinkered zealots. It's treated like a Bible where every word is taken as the Gospel truth that can't be tested, validated, compared or improved upon. Any alternative technology that reduces latency, improves performance and end user experience is considered an evil intrusion invalidating the purity of REST and must be vanquished. In the name of R…

Well said. My blood boils thinking back to all the times I've heard "Yeah, but that's not REST." as a response to a perfectly reasonable and sane idea/suggestion.

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

#128

Post by tyrion »

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…

> HATEOAS is just superfluous. I've met zealots who will defend it to the death. I just haven't found a practical use for it.

This is really funny. Are you sure you could not spot a practical use of HATEOAS? Like for example every website that lets you navigate through it using web links, without having you to edit the url by hand!

Not talking about APIs here, as most of the JSON APIs are indeed not HATEOAS, because JSON has no built in support for hypermedia. But most of the internet's web sites that use HTML also use HATEOAS, so IMHO it seems a little bit pretentious to say that HATEOAS is "just superfluous :)

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

#129

Post by s73v3r »

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

There's already HTTP Status Codes for failed auth. Use those.

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

#130

Post by tiglionabbit »

rdeboo wrote: post #111
maratd wrote: post #106

Earlier quoted context omitted.

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

In one of my projects I started returning 409 Conflict for the former case here. Its description seems to match this use case:

> The request could not be completed due to a conflict with the current state of the resource. This code is only allowed in situations where it is expected that the user might be able to resolve the conflict and resubmit the request. The response body SHOULD include enough information for the user to recognize the source of the conflict. Ideally, the response entity would include enough information for the user or user agent to fix the problem; however, that might not be possible and is not required.

If you consider the "current state of the resource" to be "it doesn't exist yet, but you could create it".

It seems useful to distinguish between requests that could be fulfilled if the database contained different things, and requests that couldn't.

Post reply on HN