On 28 Jul 2009, at 11:47 , Alexandru Nedelcu wrote: > On Tue, 2009-07-28 at 11:09 +0200, Masklinn wrote: >> No it doesn't, the only URL there is to discover in a REST service is >> the endpoint (the service's root). Any other URL is extracted from >> the >> content types (which are to be fully documented). There is nothing to >> discover. > >> From ... > http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven > > "A REST API should be entered with no prior knowledge beyond the > initial URI (bookmark) and set of standardized media types that are > appropriate for the intended audience (i.e., expected to be understood > by any client that might use the API). From that point on, all > application state transitions must be driven by client selection of > server-provided choices that are present in the received > representations > or implied by the user’s manipulation of those representations. The > transitions may be determined (or limited by) the client’s knowledge > of > media types and resource communication mechanisms, both of which may > be > improved on-the-fly (e.g., code-on-demand). [Failure here implies that > out-of-band information is driving interaction instead of hypertext.]" > > This is from the same guy that wrote this dissertation: > http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm > > The point being: if you have to document your API for its usage to be > possible, the interaction with it is not restfull anymore. > You might want to read what you just quoted, because it completely and absolutely supports what I said. And absolutely not your point. 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. In other words, what Fielding is explaining here is that a RESTful service should provide a single URI (the service root) and the documentation for the various file formats consumed & produced by the service. Period, end of the story. Which is (oh dear) exactly what I said.
> So yeah, having beautiful URLs that correctly identify a resource is a > big plus. > 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. > 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. > The second choice guides your selection. The user_id is mandatory and > you can also see that from the construction of this URL. > 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. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
