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
