Live data from Hacker News

Ask HN: Nested Resources in REST/HTTP API URLs?

news.ycombinator.com

71–72 of 72 posts

Re: Ask HN: Nested Resources in REST/HTTP API URLs?

#71
post #59
post #18

Earlier quoted context omitted.

I'd do it this way as well for most cases. Complicated URLs are hard to remember and annoying to share. The one benefit of the nested URL is that you get is of being able to "inspect" what organization or section or comment a piece of content belongs to. This is probably a rare edge case and something you should only implement if it makes your system much more usable, for some reason. e.g. I'd probably rather have po…

A cool way of reaping benefits of both approaches is to separate client side and server side URLs. The thing after the '#', which has been called many things in the past (hash fragment, I guess), never goes into the server, so you can play with it using JavaScript to make it meaningful to users, while keeping it simple and flat on the real HTTP requests.

That's a neat idea. It's like a self-contained documentation / "comment" of the URL. `#` is even fairly well-known commenting character.

Re: Ask HN: Nested Resources in REST/HTTP API URLs?

#72
post #3

Just do: - /organizations/:id - /blogs/:id - /sections/:id - /threads/:id - /comments/:id Why? What determines how resources are related are links, not patterns in the URL. It's a graph, the URLs are just nodes, the links are what connect them. If you _want_ to have some sort of hierarchy in the URL, you can redirect: - /organizations/123/blogs/1234 -> /blogs/1234 Then each resource expresses how it is related to oth…

I can think of at least one example where this wouldn't work: when blog ids are not unique across organizations.
Post reply on HN