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

81–90 of 166 posts

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

#81

Post by s73v3r »

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.

For those points to be well reasoned, one would have to assume that no one at Facebook has tried those things, though. If they really are integral to what REST is, then it doesn't really make sense that no one there knew what it was.

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

#82

Post by sbov »

harryf wrote: post #72
sbov wrote: post #60

Earlier quoted context omitted.

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.

Is this a thing? Having Google index your REST api?

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

#83

Post by joshstrange »

neilellis wrote: post #70
sbov wrote: post #60

Earlier quoted context omitted.

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

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 status codes for some things and some JSON errorCodes for others. It needed to be all or nothing and since HTTP codes obviously wouldn't satisfy it was 200's everywhere...

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

#84

Post by vlunkr »

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…

Right, you shouldn't feel like you are "sending a SQL query to the backend" as OP suggests. An API is an abstraction layer, you shouldn't have to know anything about the database to use it.

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

#85

Post by herge »

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…

> REST encourages creating a CRUD interface for every single resource.

But it doesn't enforce it. You can always limit a resource to just GET. The joy of REST is that if you later need to 'crudify' a resource later on, you can add the necessary verbs on whichever resource you want.

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

#86

Post by Fiahil »

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.

I see this as a good thing. In my mind, an API is made to be consumed from several different client, so it should make sense on it's own and not try to follow how objects are mapped onto one UI. However, it's also frequent to include "macro-endpoints" sided with regular routes to simplify a succession of common simple side-effects (like register and then login). That's not "correct" REST, but not a bad thing either.

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

#87

Post by RussianCow »

harryf wrote: post #72
sbov wrote: post #60

Earlier quoted context omitted.

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.

Which isn't relevant with regards to APIs.

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

#88

Post by seagreen »

jaaron wrote: post #80
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…

Your last two sentences are hand to understand since you seem to be conflating the internet with the web. They're not the same thing.

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

#89

Post by danpalmer »

s73v3r wrote: post #81
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.

For those points to be well reasoned, one would have to assume that no one at Facebook has tried those things, though. If they really are integral to what REST is, then it doesn't really make sense that no one there knew what it was.

> For those points to be well reasoned, one would have to assume that no one at Facebook has tried those things, though.

Not quite. These points were well reasoned given the information Facebook has made public. If they have tried those things (which I fully expect them to have done), all that means is that there is an answer to these challenges.

To clarify: I expect that Facebook has a rebuttal to these points, however my guess would be that the rebuttal will be more Facebook specific than the motivation for these technologies that they specify publicly.

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

#90

Post by aikah »

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 to make a point, it would be simpler and more useful to say that it is just about taking advantage of "natural" HTTP features and some web concepts such as hyperlinks. So there is no such thing as "fake REST" if one's intent is exactly that. Me not using content negotiation for API versioning doesn't my API fake REST.

Too bad because the OP makes a few interesting points , but they are drown into some hateful garbage.

Post reply on HN