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

111–120 of 141 posts

Re: Nobody Understands REST or HTTP

#111

Post by comex »

Some of this feels like trying too hard to adhere to HTTP. For example,

> Accept: application/vnd.steveklabnik-v2+json

This declaration loses information, because it no longer contains the MIME type for JSON in a standardized format. Assuming the server responds with the same string for Content-Type, any application that does not know specifically about this API can no longer recognize that it's JSON and, e.g., pretty-print it for a user, as I haven't seen done for JSON but is regularly done for XML by browsers.

On the other hand, the original suggestion:

> Accept: application/json

works in theory, but in practice makes it more difficult to test the API in a browser. This is not the end of the world, but there does not seem to be any real benefit in using Accept. I cannot think of any practical situation where a tool can use the standardized header for an advantage...

Re: Nobody Understands REST or HTTP

#112

Post by masklinn »

glenjamin wrote: post #2

Is there any way to make the browser do an Accept: application/csv header on a hyperlink? I'm pretty sure users like their "Download as CSV" links, which I've generally done as /normal/resource/url(.csv) While this post sets out the ideals, I think there are some cases where for usability, you have to do something less than ideal.

> Is there any way to make the browser do an Accept: application/csv header on a hyperlink?

Sadly no. Browsers suck ungodly amounts of dicks in their handling (or absence thereof) of the Accept header. I don't know of any web browser with an even remotely useful behavior on that one.

Re: Nobody Understands REST or HTTP

#113

Post by bad_user »

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…

Pagination is implicitly non-restful as page=X can change anytime a new book is added, depending on the ordering getting done.

Re: Nobody Understands REST or HTTP

#114

Post by _ikke_ »

ericmoritz wrote: post #42
pornel wrote: post #30

Earlier quoted context omitted.

/search/bass/sort/artist/ That doesn't look like a hierarchical resource. You probably don't list sort options under /search/bass/sort/, and even then /search/bass/sort/artist/ wouldn't be logical subset of that. This URL looks more like a different view on /search/bass resource, so /search/bass?sort=artist is IMHO more appropriate.

The standard is to use / for hierarchal data and URL params to alter the resource's content. For instance: /search/ would be an empty search, and for the sake of argument let us say that it returns the entire collection. /search/?query=bass This would restrict the collection to return only records that contain the word "bass". Based on the way that URLs are defined, these are considered separate resources. The same w…

I would say it would be a different (limited) representation of the same resource.

Re: Nobody Understands REST or HTTP

#115

Post by svv »

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…

The RESTful way to solve such problems is not just by better conventions, but by conventions standardized by the appropriate media types. E.g., the REST service may define a

  Content-Type: application/vnd.acme-json-with-paged-hrefs
that means that all "href" properties are URIs that may be paged by appending "?page=NNN" to them. If both server and the client understand this content-type, the representation may omit the "rel:" part from the parent example altogether.

Constructing arbitrary URIs by the client is not RESTful; however in this case it's the server-side that is in control of URI generation mechanism (it could serve a different representation, with a different Content-Type:, if it chooses to) -- thus it's perfectly valid from the REST point of view.

This is the same story as with the HTML element. It also allows client to construct URIs by the specific rules known to both sides -- because the rules are defined by the appropriate standards about text/html.

Re: Nobody Understands REST or HTTP

#116

Post by bradgessler »

bad_user wrote: post #113
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…

Pagination is implicitly non-restful as page=X can change anytime a new book is added, depending on the ordering getting done.

That's like saying that a resource is implicitly non-restful because its state might change.

If a book is added, the page=x resource is simply outdated and should be refreshed.

Re: Nobody Understands REST or HTTP

#117

Post by justincormack »

dreamdu5t wrote: post #86
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…

The biggest problem? I'd say the biggest problem is browsers not fully implementing HTTP's REST support. Instead of having a different API for every freakin' website on the planet, we could use HTTP and actually implement GET, PUT, POST, DELETE. It's sad that it didn't happen in XHTML2, and also removed from HTML5.

It is back in discussion for html5, so may yet happen.

Re: Nobody Understands REST or HTTP

#118

Post by justincormack »

bradgessler wrote: post #116
bad_user wrote: post #113

Earlier quoted context omitted.

Pagination is implicitly non-restful as page=X can change anytime a new book is added, depending on the ordering getting done.

That's like saying that a resource is implicitly non-restful because its state might change. If a book is added, the page=x resource is simply outdated and should be refreshed.

If you need page stability you can refer to the items at the top of the page not the page numbers, the nice thing about rest is they are still just next and prev links.

Re: Nobody Understands REST or HTTP

#119

Post by [deleted] »

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…

[deleted]

Re: Nobody Understands REST or HTTP

#120

Post by pavpanchekha »

config_yml wrote: post #19
glenjamin wrote: post #2

Is there any way to make the browser do an Accept: application/csv header on a hyperlink? I'm pretty sure users like their "Download as CSV" links, which I've generally done as /normal/resource/url(.csv) While this post sets out the ideals, I think there are some cases where for usability, you have to do something less than ideal.

Looking at the newer spec, we should be able to use "hreftype" for content type or "hreflang" for accept language: http://www.w3.org/TR/xhtml2/mod-hyperAttributes.html#s_hyper... I don't know if any browser will implement this or has implemented it, but in real world scenarios we'll probably have to stick with .csv and en/foo or ?locale=en for a couple of years...

XHTML2 is never coming. That train has left its station with HTML5. So long, elegance and ideals! At least I have my ruddy practicality here.
Post reply on HN