Hi Hugh, Wonderful! You obviously have great writing skills and an ability to share your enthusiasm while keeping a clear eye on the core issues at stake. I won't have time to reply extensively but here are a few comments:
1) References Due to the open source nature of this project, we don't know about all experiences and applications. However here are some public references that should make you a bit more comfortable: http://www.noelios.com/products/references Some of the applications are really big and industrial (see Overstock.com presentations for example). No doubt in my mind that Restlet will be a very powerful, stable and scalable engine for your projects. Of course, as a pioneer, you will have to innovate, especially if your use case is beyond the usual/boring examples. For our upcoming Restlet book, we have chosen to illustrate the usage of the technology by reimplementing email protocols in a RESTful way: http://book.restlet.org/ There has also been lots of talk in the "REST-discuss" mailing list about the best way to apply these REST ideas to real world complex distributed systems. 2) Authorization and authentication Client SSL certificate verification, entity signing, SSO, OpenID and delegation protocols like OAuth can be leveraged to solve advanced cases. In general regular mechanisms like HTTPS + Basic HTTP authentication can be sufficient. Think about how your online banking site works for example... Of course, your small distributed resources will still require a good level of coordination. Even if REST API evolvability is possible, you don't want to deal with constant or chaotic change. I guess, sharing your actual use case would help us more concretely guide you in the right direction. Best regards, Jérôme Louvel -- Restlet ~ Founder and Lead developer ~ http://www.restlet.org Noelios Technologies ~ Co-founder ~ http://www.noelios.com -----Message d'origine----- De : news [mailto:[EMAIL PROTECTED] De la part de Hugh Acland Envoyé : mardi 14 octobre 2008 03:19 À : [email protected] Objet : Authenticating and other thoughts I acknowledge the real potential these little Restlet dudes could have. Roy Fielding is a visionary and I am certainly an enthusiastic follow of the principle of having loads of little RESTful resources, each with his own specific function in life and all mingling out there on the web, just waiting for someone or some client to track them down with a unique, cacheable, addressable, stateless URI. And then know instantly what methods can be used (if not the result) and not forgetting the built-in http response codes. Also, the principles of Safeness and Idempotence are exactly what my project requires. (I don’t like the terms ‘resource’ and ‘web service’ though. To me they sound too gimmicky and widgety. I’d prefer what sits behind a unique URI be referred to as an ‘application component’) I love the idea that an individual Restlet can be thought of as a distributed component of a much larger and complex system and as such the project can really be broken down into manageable parts deployed across different physical locations and making use of the correct language for the task. It is as if something I have been waiting for my entire adult life has come to pass - the ability for true distributed computing. Sun's motto used to be (still is?) "The network is the computer". But I always thought that at the time, knee deep as I was, in J2EE containers and AJP and Apache and God knows how many different bloomin' implementations of "Enterprise Stacks", that Sun was being a wee bit premature. In my book, simplicity is elegance, and elegance is Good. This is no Moral Question but certain Fact! My client code should not care which language the web-service is written in, nor whether the code is running on the same box as the client or in Timbuktu. (Although, in the case of Timbuktu perhaps it should care because the last I heard their electric supply wasn't great!) Further, my client code shouldn't have to wade through swamps of WSDL files to work out what the heck it was going to ask the web- service to do. (although some kind of api-doc would be needed to tell the world what to expect from the web-service and I am still not convinced about WADL) Ah! The joys of Enlightenment! I guess my obvious enthusiasm for this technology is apparent. But still I am hesitant to embrace them fully. And here's why: I feel like a pioneer, like a Frontiersman in the American West of the 1860s. There is no road map for me to follow! I really, REALLY want to build this project as distributed and modular as possible and all ‘with the grain of the Web’ using Restlets/REST. But like the Frontiersman am I pushing my horses too far too fast? All the books and articles I have read talk of web-services as if they were only little widgets which, say, tell you the temperature when asked. Or give you a list of results against a search query. None of these is a true “big old school application” – none of these has a single “main class” entry point (well, I guess they might). Perhaps a better way of putting it is that all the examples of working Restful web-services seem, well, boring! And small. A bit like a Frontiersman who left New York and settled in Virginia. Hardly pioneering! I don’t mean to belittle these web-services but are there any examples of large scale commercial applications (whether open to the world or secured) which are built solidly on a truly distributed, web-based Restful architecture? And here is my main reservation about this wonderful Restful world of distributed computing: how do we authenticate and authorize across the web in a way whereby one web-service (in London), which might be happy dealing with the client’s request, then gets to a point in its logic execution where it needs to enlist the help of another web-service (in Tokyo). If the Tokyo web- service (web-service-san?!) is just providing the temperature then there is probably no need to authenticate but if London (web-service-old-chap?!) wants to ask Tokyo to transfer $100,000 to web-service-cowboy (Texas) then the chances are some how the original security credentials must be parsed around like a children’s party game. And children’s party games always end in tears. Someone always spoils it. So is the current authentication/authorization model - or lack of clarity of purpose – hindering mass take-up of this technology? From a management perspective, the old ways of doing things – thin client, massive load on clustered servers running guargantuan enterprise application server stacks and Berlin-wall style firewall behind which sits all the processing logic and firepower – makes life a lot more secure. Well, initially I was going to ask a very simple question and I have asked in a very long winded way. Sorry, this should probably be better suited to a blog than a mailing list. Anyway, thanks for reading so far and if anyone would like to then please let me have your thoughts.
