On Tue, 2009-07-28 at 12:22 +0200, Masklinn wrote: > You might want to read what you just quoted, because it completely and > absolutely supports what I said.
No it doesn't support your argument. You're just arguing semantics. > The important part here is the following: "set of standardized media types > that are appropriate for the intended audience". Media Types are > content types, and they're "standardized" because they're documented. HTML is a media type and it is well standardized and documented. This doesn't make your service restfull if on the page for a certain resource (like a user), you're not given links to related resources (like the user's articles). This brings us right back to discoverability ... any extra documentation that's not based on hypertext, while useful, shouldn't be required for its usage ... and that was my point. A service isn't any less restfull if you're giving cryptic URLS, but there are certain practices that make your job easier (like, duh, a self documenting API). > It's a "big plus" for humans reading the URLs (maybe), but it's > completely irrelevant to the restfullness (or lack thereof) of the > service. Human-readability implies extra-documentation. And you're forgetting one point ... the whole purpose of REST (and HTTP for that matter) is to provide more predictability. Having clear conventions in your self-documenting API helps a lot. > > Not to mention there's quite a difference between: > > /articles?user_id=30&state=new > > and > > /user/30/articles/new > > > There isn't. And neither are URLs to a restful service given both > encode action informations in the URL. That's rich :) Are you saying those URLs aren't identifying a resource, but an action? The list of articles of a certain user that have a certain state, is an action? What action? Every time you're requesting newer articles God kills a kitten or something? > Given you should never have to manually construct URLs in a restful > system (unless you're given patterns with holes to fill, and that's > the most of it, and defined/documented for the content types providing > the patterns and data to fill them) this is irrelevant. Both URLs are > functionally the same. > The requirement of the user_id is know from the > basic facts that the URL is provided with a user_id filled (or > demanded in the case of holed patterns) in the first place. No, they are not the same. Semantically, one is identifying a resource. The other one makes a query on a resource. Since we are talking about HTTP here, from the protocol's point of view, parameters are optional. It would be kind of inappropriate to throw a "404 Not Found" message if the "&user_id=30" is missing from the query ... but let's bend the rules a little :) That's not to say that making queries with GET parameters isn't restfull, but again ... we are talking about tools and practices that make our life easier. Maybe you don't see a problem to not having human-readability and self-documenting APIs in a RESTfull scenario, since you've been arguing all morning with everything I said. I'm also a bit disappointed by your tone. Again, chill, drink some coffee, relax a little ;) -- Alexandru Nedelcu --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---
