Re: Annotations and Restlet's future
Jerome was on the JSR 311 expert group but Restlet doesn't support it? --Erik 2009/4/8 Rémi Dewitte r...@gide.net I can see that Jérôme has already answered a great deal of my questions in this thread :) http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1596334 Rémi 2009/4/8 Rémi Dewitte r...@gide.net Hello, I struggle to get convinced to the use of annotations for resources from all I can read from various threads. I have the feeling to lose most of the reasons to use Java. MediaTypes are strings, I find the implementation a bit tricky with reflection forced to be cached to be fast, classloaders issues. I guess there is a rule to handle annotations with class hierarchies, etc. I totally understand that some people like annotations and the work it has triggered was a good way to get the resource API even better. What are the benefits of using annotations with Restlet ? Restlet annotations are a competitor of JAXRS, right ? To what extend is it better ? Will annotations in restlet the advertised way of creating restlet application ? What are the other planned uses of annotations ? Regards, Rémi -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1604346
Re: POST redirect to GET
Go back and reread the HTTP spec. In particular, read about 303 See Other on the first hit here: http://www.google.com/search?q=http+status --Erik On Mon, Mar 16, 2009 at 3:57 PM, Cliff Binstock cliff.binst...@coyotereporting.com wrote: My apologies for asking what I think should be obvious. I am using POST to upload files. Works great. When I’m done, I want to return to a standard GET URL. To do this, I am using: response.redirectTemporary(newLoc); My new location is a restlet route (of course!). It appears that the redirect is getting a POST (remember I’m inside of a POST), and not a GET. How do I redirect, setLocation, etc. so that the next URL is a GET? P.S., I tried “?method=get”, but I suppose that’s getting ignored because I’m not in a GET. Thanks much, Cliff Binstock -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1335946
Re: Customized 200 level response status codes
I know this doesn't answer your question, but doesn't 204 do what you want already? --Erik On Tue, Dec 9, 2008 at 6:58 PM, [EMAIL PROTECTED] wrote: I define a customized status code(299) to handle the case of a success request with no data found. I tried two different ways to set this status code(see below), but the status code client receives is 404, not 299. There's no place in my codes to set status to 404, so this 404 must be generated by Resetlet automatically. If I change 299 to any 400-level or 500-level code, for example, 499, then it works fine. Does anyone know why? If there any way I can set a status of 299? Thanks. code // somewhere define my customized status public static Status SUCCESS_NO_DATA = new Status(299); // public Representation represent(Variant variant) throws ResourceException { try { // ... } catch (Exception e) { // OPTION getResponse().setStatus(SUCCESS_NO_DATA, No Data); // OR // OPTION 2 throw new ResourceException(SUCCESS_NO_DATA, No Data, e); } } /code -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=981976 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=981980
Re: Restlet 1.1.0 released!
Congratulations on the release! I'm very excited to see where Restlet goes. --Erik On Tue, Oct 28, 2008 at 10:57 AM, Jerome Louvel [EMAIL PROTECTED]wrote: Hi all, Thanks to all of you who helped us getting there: we have just pushed Restlet 1.1.0 out of the door!! The release process is just starting, now we need to get the word out now. If you can help us spreading the good news that would be great. Below is the announce text from http://blog.noelios.com --- Since the launch of Restlet 1.0 in April 2007, we have been working hard to prepare this new version. To protect your investment in existing code, we have maintained the initial API design, extending it where necessary and always ensuring a direct if not transparent migration path. Here is a selection of the most exciting new features: - Broader and deeper HTTP support with features such as partial downloads, resumable uploads or content integrity validation. - Best support for the WADL specification in the industry, allowing an automatic and always in sync documentation of your REST APIs. WADL documents can be generated in XML or converted on the fly to HTML using the popular stylesheet from Yahoo! - One of the first and most complete implementations of the new JAX-RS 1.0 specification provided for those preferring an annotation-oriented approach. - New Restlet-GWT module provided, porting the client-side of the Restlet API to the popular Google Web Toolkit 1.5 JavaScript platform, allowing you to invoke RESTful applications right from your Web browser. - New extensions for easier integration with the JAXB 2.1, JiBX 1.1, Spring 2.5, OAuth, OSGi, Oracle XDB and SSL technologies. - Improved support for Atom Syndication XML format and for Atom Publishing Protocol. Both formatting and parsing are now available. - New POP3 connector based on JavaMail to access RESTfully to remote mail boxes. - New Grizzly HTTP server connector, first to fully leverage the NIO support in the Restlet API, leading to new levels of scalability and performance. - New internal HTTP client and server connectors to simplify development phases (zero configuration necessary) and allow very small footprint deployments. http://www.restlet.org/ Direct contributors: - Aaron Crow - Aaron Roberts - Adam Harris - Bruce Lee - Diego Ballve - Erik Beeson - Jérôme Bernard - Kevin Conaway - Richard Hoberman - Tim Peierls In addition, we have significantly expanded our documentationhttp://www.restlet.org/documentation/1.1/with a 150 pages long Restlet User Guide, a screencast and first steps tutorials. We have also added new licensing options: LGPL 3.0 and transferable commercial licences (OEM). You just need to download Restlet 1.1.0http://www.restlet.org/downloads/to enjoy those new features ! Best regards, Jérôme Louvel -- Restlet ~ Founder and Lead developer ~ http://www.restlet.org Noelios Technologies ~ Co-founder ~ http://www.noelios.com
Re: uriPattern exactness
In what scenario (other than maybe development) do your routes change at runtime? --Erik On Mon, Oct 20, 2008 at 2:44 PM, Cliff Binstock [EMAIL PROTECTED] wrote: Jérôme, I thought of another reason why it would be *really nice* to know the matching URI pattern: I would like to be able to dynamically determine how to handle a resource request from a configuration. To simplify my actual use case, suppose for example that I implemented a default resource, and the default resource could look at, say, an external XML configuration file to determine which class to really call (dynamically). This external configuration might look like: entry matching-uri-pattern/foo/{foos}/bar/matching-uri-pattern invokecom.coyotereporting.foo.Bar/invoke /entry Right now, I can see how to use the above to dynamically define *resources* once on startup, but not how to abstract this one level to have the default resource call different handlers on the fly. So, if I can add to the long term request list: 1) Get back the original URI (e.g., /foo/{foos}/bar) 2) Get back the as-matched URI (e.g., /foo/myFoo/bar). Note that #1 above (original URI Pattern), would enable a very flexible default handler. Cliff Binstock Coyote Reporting -Original Message- From: Jerome Louvel [mailto:[EMAIL PROTECTED] Sent: Friday, October 17, 2008 4:02 AM To: discuss@restlet.tigris.org Subject: RE: uriPattern exactness Hi Cliff, In combination with MODE_EQUALS, you could also add a variable for your extensions like: /foos/{foo}/bar.{ext}. That could reduce the number of alternative routes you would have to attach. Best regards, Jerome Louvel -- Restlet ~ Founder and Lead developer ~ http://www.restlet.org Noelios Technologies ~ Co-founder ~ http://www.noelios.com -Message d'origine- De : Cliff Binstock [mailto:[EMAIL PROTECTED] Envoye : vendredi 17 octobre 2008 01:28 A : discuss@restlet.tigris.org Objet : RE: uriPattern exactness Aron, Thanks, I didn't realize this was here. This would potentially work, and I may end up using it. Frankly, I want to be able to have my cake and eat it too. An exact match using this construct would work, but would also force me to itemize every possible variation of a path via router.attach(). I was hoping to do some fuzzy enforcement in a base Resource class. Cliff Binstock Coyote Reporting -Original Message- From: Aron Roberts [mailto:[EMAIL PROTECTED] Sent: Thursday, October 16, 2008 11:37 AM To: discuss@restlet.tigris.org Subject: RE: uriPattern exactness In the message Re: uriPattern exactness, dated 2008-10-16, Cliff Binstock wrote: P.S. What is worse (maybe very confusing) is that this might match too: /foo/myFoo/bar/baz/bletch/fred.xml Again, I would like to forcefully ensure that this doesn't end up matching. From memory - by default, the mode for matching incoming URIs to your URI templates is 'starts with' rather than 'equals'. As Jerome wrote back in February 2008: In some cases, you might want to change this default mode, and this is easy to do via the defaultMatchingMode property on Router, or by modifying the matchingMode property of the template associated with the route created by the Router.attach() methods. For the modes, you can use the Template.MODE_EQUALS or Template.MODE_STARTS_WITH constants. Here's one example of the latter: router.getTemplate().setMatchingMode(Template.MODE_EQUALS) Hope this is germane to your needs. Aron
Typo in org.restlet.resource.Resource#allowPut javadoc
The javadoc for allowPut says Indicates if DELETE calls are allowed...: http://restlet.tigris.org/source/browse/restlet/trunk/modules/org.restlet/src/org/restlet/resource/Resource.java?view=markup --Erik
Re: Best practices when Implementing acceptingRepresentations?
We use XStream to do all of our serialization, so we get to switch between XML and JSON for free, which is really nice. I've been considering XStream so it's great to hear that it's working for you, especially regarding JSON. Yep, very happy. Joe Walnes has done a lot of great stuff, and Google was very wise to hire him up. XStream gives you all the right entry points to be able to tweak it in just about any direction that you need. annotations (mainly @XStreamAlias and @XStreamImplicit), so separating them helps keep the data POJOs much cleaner. Our containers end up really cluttered with a lot of XStream related This is why I've never been that keen on annotations. Keeping this information external to the POJO would leave them suitable for use in a client API as Vincent suggests. I really like annotations as I got pretty burned out on XML sit ups in Java web frameworks back in the day, but I see how it could be helpful for you to decouple that information. Most things (XStream and OVal at least) offer annotation support as an addon, so you can still provide your configuration however you want. How are you handling circular references/normalization in JSON? My prototype uses flat structures and uses the business keys to resolve references on the client-side (javascript). But I've noted techniques for serializing denormalized/circular JSON (e.g. http://www.jspon.org/#JSPON%20Core%20Spec). Have you formed a view? I'm not as my data isn't structured that way. The most we have in terms of relationships is parent/child, and we don't have situations where the relationships get modified, so this hasn't really come up. For example, we have Users which have Entries which have Comments. Comments don't move between entries, and entries don't move between users, so our updates are generally just modifying properties of a single object. --Erik
Re: bad experience with restlets
I second Michael's thoughts. I looked at restlets half a dozen or so times over the past year or so before finally taking the plunge a couple of weeks ago. While I might not say it's the easiest framework I've ever used, it is very nice once you get the hang of it. It took a couple of days of fiddling, but now I do all kinds of great stuff with it and I just love it. Alex, what were you trying to do? I found that following the First Steps, First Resource and Tutorial, step by step, was very helpful. I actually went back and forth between the First Steps and the First Resource a few times before I really got the hang of it. http://www.restlet.org/documentation/1.1/firstSteps http://www.restlet.org/documentation/1.1/firstResource http://www.restlet.org/documentation/1.1/tutorial Hope it helps. --Erik On Thu, Sep 18, 2008 at 11:47 PM, Michael Terrington [EMAIL PROTECTED] wrote: Hi Alex, Sorry to hear of your bad experience but I have to speak up to defend Restlet. I've not seen a cleaner, easier to follow framework with so much flexibility before. I'm not sure how you were starting off, but I found that running standalone was the easiest to get going and understand. It certainly helped to be able to breakpoint and follow the code. Once you understand how Restlet handles and routes requests you should be in a good position to get more complicated. Regards, Michael. On Fri, Sep 19, 2008 at 11:33 AM, Alexei Sokolov [EMAIL PROTECTED] wrote: Well, I can't figure out how to do very simple things with restlets. I get NPE in RC1, I cannot configure restlets the way I want and wiki does not have anything useful on it. So much for breaking away from servlets. Sorry, but maybe when restlets reach v. 2.0 I will give it another try. Alex