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

Nobody Understands REST or HTTP

blog.steveklabnik.com

Post reply on HN
Print view View original

91–100 of 141 posts

Re: Nobody Understands REST or HTTP

#91

Post by clintjhill »

clintjhill wrote: post #48

Content Negotiation is a critical part of REST APIs and it's my observation that most simply ignore or default to JSON in all cases. Good REST APIs allow the client to "choose" the mime type. Without this part of REST - you have no "representational". On that topic, to rely on an 'Accept' header is pretty risky. That presumes the client will always have control over the headers. It is in my opinion always wiser to ma…

Was there something particularly wrong about my comment(s) here? Seems I was down voted on all 3.

Re: Nobody Understands REST or HTTP

#92

Post by bphogan »

bradgessler wrote: post #51

The biggest problem with today's REST implementations is that they're essentially a database serialization layer. Consider how a RESTful Rails model is typically represented as: { book: { id:1, name:"To Kill a Mocking Bird", author_id:2 } } How do you get more info on the author if you only have this piece of information? Rails/ActiveResource guesses through convention: "/authors/2", but that might not be the case, w…

Upvoted because I like your solution for pagination and for further information via an :href attribute. However, I don't see a real problem with the way Rails does things because it's "by default" and I think a dev ends up causing a lot of unnecessary trouble for himself by using stock to_json. The more I work with Rails building out a JSON API, the more I realize that .to_json is just another way to "scaffold" - it's not useful in production. :)

Re: Nobody Understands REST or HTTP

#93

Post by awj »

bradgessler wrote: post #57
clintjhill wrote: post #53

Earlier quoted context omitted.

You may find that Sling supports you're request here. But to the extent that they are all "lame database serialization" layers, I'd have to say "well - ya". REST is kind of just that. I think that what you're really trying to say is that implementations you have found don't do HATEOAS.

I disagree that "REST is just kinda that [database serialization]"; it is one approach to REST, but its brittle and tends to bias developers towards over-engineering their API into these tiny little pieces that correspond with each database table or model. I'm designing the API for Poll Everywhere right now. Internally a multiple choice poll resource consists of several database tables and Rails models, but I simplif…

I've ended up doing without ActiveRecord's to_xml/to_json to (among other things) accomplish HATEOAS within Rails. Instead I'm using xml builder and a roughly equivalent json-from-ruby-hashes template system. The process is a bit ugly at times, but so far the results have been pretty promising. We've already had api changes break enough internal clients that people are pretty excited about that never being their problem again.

I could wish that Rails had a cleaner path and this regard, though. I've never understood the thought process behind Rails' serialization system. Why use MVC to deal with html and email but almost ditch it entirely for other document formats? Especially when we're dealing with something that could really benefit from embedded hyperlinks.

Re: Nobody Understands REST or HTTP

#94

Post by awj »

bphogan wrote: post #92
bradgessler wrote: post #51

The biggest problem with today's REST implementations is that they're essentially a database serialization layer. Consider how a RESTful Rails model is typically represented as: { book: { id:1, name:"To Kill a Mocking Bird", author_id:2 } } How do you get more info on the author if you only have this piece of information? Rails/ActiveResource guesses through convention: "/authors/2", but that might not be the case, w…

Upvoted because I like your solution for pagination and for further information via an :href attribute. However, I don't see a real problem with the way Rails does things because it's "by default" and I think a dev ends up causing a lot of unnecessary trouble for himself by using stock to_json. The more I work with Rails building out a JSON API, the more I realize that .to_json is just another way to "scaffold" - it'…

I can see that point ... but where's the direction on what to do next? What's the post-scaffold JSON mechanism? Bonus points if it lets me generate/embed urls with the knowledge/techniques I have from making web pages.

If you say "erb", please don't be offended by me laughing.

Re: Nobody Understands REST or HTTP

#95

Post by icebraining »

rubyrescue wrote: post #88
icebraining wrote: post #70

Earlier quoted context omitted.

You're confusing resource with representation. An URL is a resource, but if the representation of that is a JSON document or a picture of him/her, that's up to the server. Just because an header affects the representation of a resource, doesn't mean they're different resources.

actually that's a good example that makes my point. if i said to you - well if you want to retrieve a person's user information, just GET /users/1 with Accept: text/json. If you want their photo, just GET /users/1 with Accept: image/jpeg - philosophically , i'm not violating the 'rules of REST' but it feels wrong to me.

Sure, I would create a "User's photo" resource too and link it from /users/1, but that's because a user's photo can be a new resource, so it can have its own URL.

Re: Nobody Understands REST or HTTP

#97

Post by dedward »

icebraining wrote: post #81
wyuenho wrote: post #72

I read the post and I have to say that he's got a nice flamebait title but totally avoided the thorny issues that people argue about. In fact, I'd like to be pointed to a solution for the following problems: 1. I'm an old Web programmer, and my introduction to the Web started with HTML, not HTTP. I don't just write APIs, I write Web apps. I find it difficult to explain to people what this means: If you are religiousl…

1) HTML isn't English, it just has some similar sounding tokens. You can't assume the semantics are the same. 2) Well, there's HTTP and there's REST, they're related but no the same. HTTP is a full protocol, completely defined; you can't add more verbs, period. REST is an architectural style . It has a series of constraints, and it tells you that if your system architecture complies to them, it'll have some useful pr…

to #4 - that's only true if you designed your app to rely on a single server and have no fault tolerance or distributed sessions. Argh.

Re: Nobody Understands REST or HTTP

#98

Post by glassx »

rubyrescue wrote: post #82
stanleydrew wrote: post #71

Earlier quoted context omitted.

What do you mean by visible? Visible in the URL bar of a browser? The headers are all there in the request, for all to see.

yes i'm thinking more pragmatically. From an API perspective the header is part of the request but given that the human-readability of urls is a feature of http, it just somehow feels wrong to me to modify the response based on a request header.

I think most developers don't see that as a problem.

We modify the response all the time based on headers like User-Agent, Referer, If-Unmodified-Since, Accept-Language and others, so using Accept for versioning isn't really that strange.

Re: Nobody Understands REST or HTTP

#99

Post by dedward »

icebraining wrote: post #76
stanleydrew wrote: post #75

Earlier quoted context omitted.

Ah, fair enough. They are indeed two different resources. Would you have a problem if I returned the actual representation rather than a 302?

I don't have a 'problem' with it, this is just conceptual talk. But I'd still do it for SEO reasons. If Google fetched /blog/current as containing the "Why I love REST" post and showed it to me, and the when I clicked the link I got "Why I think turtles are awesome", I'd be annoyed. A 302 fixes that in a more clean way than entries in robots.txt or similar tricks. EDIT: Apparently Google messes that up and often asso…

Seems like people are mixing up ways of providing web services with overall site design and url friendliness......

Re: Nobody Understands REST or HTTP

#100

Post by icebraining »

iandanforth wrote: post #89
binarymax wrote: post #38

Earlier quoted context omitted.

Did you read the article? No matter nouns or verbs but in your example you are doing an HTTP GET. Does get getallpages sound right to you? I did not downvote you but the REST architecture is well thought out, simple to follow, and very sufficient if you are moving content over HTTP.

First off, thanks for taking the time to reply to my admittedly baiting post. I do have a serious point I'm making though. Lets walk through it. http://www.mywebsite.com/api/getAllPageNames/returnType/JSON In this string 'get' appears once. However, as an experienced dev, you know that this is a GET request. To you it looks redundant. However to someone trying to understand what will happen when they hit enter with t…

But you still have to make a GET request and hence understand what that verb does - so you don't really gain anything - and now you're creating ambiguities for the API users. What if I POST to 'getAllPageNames'? It doesn't make sense, does it?

Personally, I'd say that if a developer can't be bothered to read the whole nine(!) verbs of HTTP, he shouldn't use the API. I mean, GET is described in just 11 lines!

And (s)he doesn't need to read your docs: the smart thing about the Uniform Interface described by REST is that the same verbs work on all services of the same architecture (in this case, HTTP). So that knowledge is generic and transferable.

In any case, it's your prerogative to design your API as you wish, but please don't call it REST if you don't intend to follow its principles.

Post reply on HN