On 28 Jul 2009, at 14:01 , Alexandru Nedelcu wrote: > 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. > No. I'm arguing sense and meaning.
>> 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. Yes and? > 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). Yes, and? > 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. > I absolutely don't get what you try to say here. But hey, if you're arguing against documenting content types, you're going heads-up against Roy Fielding here: > Of course the client has prior knowledge. Every protocol, every media type definition, every URI scheme, and every link relationship type constitutes prior knowledge that the client must know (or learn) in order to make use of that knowledge. REST doesn’t eliminate the need for a clue. What REST does is concentrate that need for prior knowledge into readily standardizable forms. That is the essential distinction between data-oriented and control-oriented integration. http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven#comment-742 > A service isn't any less restfull if you're giving cryptic URLS Thanks for finally recognizing the one and only point I was trying to make: the form of URLs is irrelevant to the restfulness (or lack thereof) of a service, and URLs are not "restful" or "not restful". > but there are certain practices that make your job easier (like, > duh, a self > documenting API). > APIs are never magically self-documenting. But as far as RESTful APIs go, the only part of them that can be self-documenting are the content types. I utterly fail to see the relevance of URLs there. And once again, a rest service doesn't "give URLs". A restful service has a single root URL. Beyond that bookmark, all URLs are opaque and irrelevant implementation details of the service. > the whole purpose of REST (and HTTP for that matter) is to > provide more predictability. > No (predictability of what, to start with?). The whole purpose of REST is clearly specified in Dr Fielding's thesis -- which you linked to yourself: > REST [...] emphasizes scalability of component interactions, generality of interfaces, independent deployment of components, and intermediary components to reduce interaction latency, enforce security, and encapsulate legacy systems None of "predictable", "predictability" or "prediction" are present anywhere in Dr Fielding's chapter 5. >>> 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? It seems your APIs are nowhere as self-documenting as you think, because yes following your google code examples I read your URL as creating a new resource. > Since we are talking about HTTP here, from the protocol's > point of view, parameters are optional. They aren't. > 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 :) Why would it be? > 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 not saying I don't see a problem, I'm saying it's irrelevant to the restfulness of the service. It's perfectly possible to have absolutely RESTful services with completely opaque and unreadable URLs (though I've yet to see one) and it's just as possible to see RPC- based services with perfectly readable URLs (and there are many of those). Reducing RESTfulness to the nicety of the URLs (as most clearly do) is a disease of modern API architecture. > I'm also a bit disappointed by your tone. Again, chill, drink some > coffee, relax a little ;) Pot, kettle, etc… --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
