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

51–60 of 141 posts

Re: Nobody Understands REST or HTTP

#51

Post by bradgessler »

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, which makes this approach very brittle.

A better more "RESTful" approach might be:

  {
     book: {
        href:"/books/1",
        name:"To Kill a Mocking Bird",
        author: {
           href:"/authors/2"
        }
     }
  }
The REST client would then be able to traverse the representation without making guesses at the URL, and if the end-point of '/authors:id' changes for whatever reason, the href would be updated accordingly.

Pagination/large data-sets could be solved as well:

  {
     books: [
        href:"/books/1",
        name:"To Kill a Mocking Bird",
        author: {
           href:"/authors/2"
        }
     }
    ],
    rel: {
       prev: "/books?page=1",
       next:"/books?page=3"
    }
  }
... and a bajillion other common RESTful API problems through better convention.

I'd agree with the author that REST is misunderstood, but my opinion is that its misunderstood on the grounds that today's "REST" implementations are lame database serializations. The web has been doing this since the tag was conceived, but for some reason, modern REST implementations left this out.

Re: Nobody Understands REST or HTTP

#52

Post by stanleydrew »

mberning wrote: post #49

I really dislike creating resources to represent transient actions. Not a big deal in the case of a bank transaction as that is something you could easily imagine needing to be stored for later retrieval. A different example is relating one social network friend to another or searching for specific people on the site. Those are things that, to me, are much more borderline and I would err on the side of not representi…

You haven't really explained why you don't like creating resources to represent transient actions. What's wrong with POSTing to /friend-requests with requestor=stanleydrew&requestee=mberning? There's no need to keep a log around if you don't have use for it.

Re: Nobody Understands REST or HTTP

#53

Post by clintjhill »

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…

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.

Re: Nobody Understands REST or HTTP

#54

Post by rubyrescue »

good article but...he says version numbers in the url are bad but doesn't say why. using accept headers for versioning is a hassle for every client and makes browser based testing much more difficult. also a v1 user really might not be the same as a v2 user so they shouldn't be the same resource.

Re: Nobody Understands REST or HTTP

#55

Post by gnaritas »

Sidnicious wrote: post #15

I had a really interesting conversation about this with a coworker a few weeks ago. We were talking about URL design. I argued for URLs like this: /networks/ /networks/girl_talk/ /networks/girl_talk/tracks/ /search?term=bass&sort=artist He argued for URLs like this (note the pluralization): /networks/ /network/girl_talk/ /network/girl_talk/tracks/ /search/bass/sort/artist/ My case boiled down to, “A URL represents th…

I'd say your friend has bad taste and shouldn't be allowed to design the URL structure of your site. Your style is better, but neither is more or less RESTful because REST doesn't say anything about pretty URL. URL's don't have to be hackable to be RESTful, but it's nice. URL's don't have to be pretty to be RESTful, but it's nice. You have better taste than your friend. Your search however, is more RESTful than his as all of your searches use the same URL. You understand what a resource is, he doesn't.

Re: Nobody Understands REST or HTTP

#56

Post by stanleydrew »

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…

Yes. Hypermedia references are a requirement for something to be considered RESTful: http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hyperte....

Re: Nobody Understands REST or HTTP

#57

Post by bradgessler »

clintjhill wrote: post #53
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…

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 simplified the externally facing JSON representation down to:

  {
    multiple_choice_poll: {
      title: "Fav color?", 
      options: ["Red", "Blue", "Green"],
      sms_enabled: true
    }
  }
Had I followed Rails REST conventions, I'd have an overly complicated chunk of JSON.

I'd love to implement a full HATEOAS stack on Ruby/Rails; we'll see if I get around to it.

---

BTW In case anybody needs to Google HATEOAS (like I did): http://en.wikipedia.org/wiki/HATEOAS

Re: Nobody Understands REST or HTTP

#58

Post by binarymax »

lazylland wrote: post #45
binarymax wrote: post #34

This is a great article. One challenge I am facing now is both building a RESTful API, along with a UI that uses the API. The biggest question I have is the use of shebangs in urls with the ajaxy app. We must support IE so pushState is out, but shebang just seems like a hack. I think at this point I have no choice but to implement shebang but I wonder if there are any viable alternatives?

Try this : https://github.com/balupton/History.js

Looking good at first glance, thanks!

Re: Nobody Understands REST or HTTP

#59

Post by icebraining »

ericmoritz wrote: post #36
jballanc wrote: post #11

Very good read, and thorough. I particularly like the transaction example. It seems like a common idiom that trips people up with REST. However, I do have a problem with REST that I've been dealing with lately. Specifically, the question of web-hooks. Many services today allow you to pass a URL that they will hit with a POST request whenever something happens. A good example is the GitHub post-receive hook ( http://h…

What I've seen in the past (mainly from Pylons) is to have an extension on the end of the URL so: /updates/ has a default format say XML and then there's a JSON resource called /updates.json, /updates.txt, etc. Keep in mind what the R in REST stands for. Each resource is a representation of internal data. You can have multiple representations under different URLs even though they're powered by the same internal data…

I disagree. A resource is a concept, not a representation of it. A resource in a car dealership is a 'car', not an ' XML document about a car'. One of the examples given by Fielding are "today's weather in LA"; that's not the representation, it's the actual concept.

The concept of internal data structure doesn't enter the picture at all; for all the client knows, the response might even be generated by a monkey typing on a keyboard.

So if you're using different URLs, you're saying that those are different resources, not multiple representations of the same resource.

Sure, it may be useful and 'practicality beats purity', but it's bending the concept.

Re: Nobody Understands REST or HTTP

#60

Post by icebraining »

kenjackson wrote: post #39
smiler wrote: post #17

Earlier quoted context omitted.

Either way I don't think it matters. Just get it done. Clients do not care about URL structure, they just want their problem solved. I redid an app and prettified the urls (yes I know this is slightly off topic) and no one has commented on it. Developers will use either, just do it and provide documentation and be done with it

Exactly. REST is interesting, but understand why its interesting. If you're doing it because its a popular buzzword, that's just cargo cult. It's good to know about REST so you can use it where it makes sense. But at the end of the day, doing what is right for your app trumps following any given methodology.

But then it's important to document when you're breaking the constraints. Nowadays it's impossible to know if a web service is actually following REST or not because everything remotely similar gets the same label.
Post reply on HN