Hi Piyush, [...]
> 2. A form with enctype="multipart/form-data" isn't parsed properly. > Attached restlet shows it. Everything works fine if you remove the > enctype. Ah, I see! There is an existing issue for this. I've updated it with your test code and comments: http://restlet.tigris.org/issues/show_bug.cgi?id=71 The current solution is to use the NRE extension which integrates with Apache FileUpload: http://www.restlet.org/docs/ext/com/noelios/restlet/ext/fileupload/package-s ummary.html > 3. Reference.getQueryAsForm() declares throwing an IOException while > call.getInputAsForm() doesn't and I'd expect the other way around. Good remark. I've refactored the code to never throw an IO exception, for getInputAsForm() as well a getQueryAsForm() : see in SVN. In case an error occurs during the parsing, the faulty parameter is just skipped. In addition, log traces where added for all IO errors. > 4. This way of handling login requires a lot of redirects (okay 2 to > be more specific). So I use code like > > RedirectRestlet redirect = new RedirectRestlet(this.getContext(), > redirectReference, RedirectRestlet.MODE_CLIENT_FOUND); > try { > redirect.start(); > } catch (Exception ex) { > //log it! > } > redirect.handle(call); > try { > redirect.stop(); > } catch (Exception ex) { > //log it! > } > > In my authentication filter I use > RedirectRestlet.MODE_CLIENT_TEMPORARY to redirect to the > login restlet > and in the login restlet I use RedirectRestlet.MODE_CLIENT_FOUND to > reach the expected reference. I hope that is fine. For simple cases you can also use "manual" redirects: call.setRedirectRef(redirectReference); call.setStatus(Status.REDIRECTION_FOUND); For the meaning of TEMPORARY vs FOUND, see org.restlet.data.Status or HTTP error codes 302 and 307. > Can't that exception (Exception ex) be a little more specific as it > also encompasses all runtime exceptions. Introduce a checked > RestletException? I've just tried again to change this, but there is a problem with server connectors such as Jetty or AsyncWeb which either throw non-IO exceptions or declare specific exceptions in the start() method of an interface to implement: see org.safehaus.asyncweb.container.ServiceContainer. Rather than wrapping everything into a RestletException, I prefer to keep the current approach. You can always catch RuntimeException to ignore them. > 5. What about session support? I had to create my own. Memory-based sessions, as implemented by the Servlet API, are bringing many issues. Anyway, in a more RESTful design, there should be less need for the concept of session. If HTTP authentication is not an option, you can always place a cookie (session-bound) in the user agent that will help you re-authenticate the user at each request. If you build your own session mechanism, I recommend to base it on a persistent storage in order to be able to load-balance between/fail-over multiple Restlet container instances. Another option is to use a distributed/synchronized memory-based cache like JBoss Cache. Best, Jerome
