RE: Re: Accept header sent by the client not being taken into account (2.0 snapshot from July 9th, 2009)
I've been having the same problem as Fabian. The annotation way of doing
things is still not working for me, and I'm getting strange results with
manually specifying the variants.
I'm running the snapshot I downloaded yesterday
(Engine.VERSION_HEADER="Noelios-Restlet-Engine/2.0snapshot")
I get a 406 error when I try the annotation approach.
Specifically the url:
http://localhost:8080/world.xml does NOT work
http://localhost:8080/world.json WORKS!
I've tried @Get("xml") @Get("application/xml") and @Get("text/xml") and none
of them work.
Meanwhile Get("json") is working.
If I try overriding doInit like this:
List variants = new ArrayList();
variants.add(new Variant(MediaType.APPLICATION_JSON));
variants.add(new Variant(MediaType.APPLICATION_XML));
/*variants.add(new Variant(MediaType.TEXT_XML));
*/ getVariants().put(Method.GET, variants);
I also get a 406 Error for the URL ending in ".xml" (again, json works).
Finally, if I uncomment out the line that adds text/xml as a variant, it works.
Here is the header firefox is sending:
Hostlocalhost:8080
User-Agent Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.0.11)
Gecko/2009060215 Firefox/3.0.11
Accept text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language en-gb,en;q=0.5
Accept-Encoding gzip,deflate
Accept-Charset ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive 300
Connection keep-alive
So:
1) Any ideas why the annotations are not working for the xml extension?
2) Why does the code only work for "text/xml" and not "application/xml"
(especially since the browser specifies in it's accept header that it accepts
"application/xml" but NOT "text/xml") if I manually specify media types for GET?
Thanks,
T
> Hello Fabian,
>
> Actually your resource does not declare the kind of variants it is able
> to generate.
>
> So I indicate two ways to achieve what need according to the current
> state of the code.
>
> Either, you create one annotated method per each supported variant:
> @Get("html")
> public Representation toHtml(){
> }
>
> where the parameter is the "extension" declared for the corresponding
> media type (see the MetadataService class).
>
> Or you declare them manually in the "doInit" method :
> List variants = new ArrayList();
> variants.add(new Variant(MediaType.TEXT_HTML));
> variants.add();
> getVariants().put(Method.GET, variants);
> In addition, remove the @Get annotation and rename the "represent"
> method to "get" (the "represent" method has been removed)
>
> I hotpe this will help you.
>
> Best regards,
> Thierry Boileau
>
> > Hello there,
> >
> > still with my content negotiation issues (which worked great and
> > simple in restlet 1.1.x series, I've just checked the Variant's media
> > type and acted according to its value, which just matched the client's
> > expectations...)
> >
> > I've downloaded 2.0 snapshot from yesterday (July 9th, 2009) and
> > changed jars in my project (currently,
> > org.apache.commons.fileupload.jar,
> > org.restlet.ext.fileupload.jar, org.restlet.ext.xml.jar and
> > org.restlet.jar), recompiled and rerun the jar (I was using 2.0M3)
> >
> > Now, when I connect with my browser (Firefox 3.0) it sends the
> > following Accept header:
> > text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
> >
> > The method accepting that request starts like this:
> >
> > @Get
> > public Representation represent(Variant variant) throws
> > ResourceException {
> > long lstart = System.currentTimeMillis();
> > MediaType mt = variant.getMediaType();
> > getLogger().info(" MediaType = " + mt);
> >
> > The idea is to have the method return the corresponding representation
> > according to the media type specified in the Variant, which I
> > understand comes from the request and the Accept header. However, even
> > with the above Accept header, I get the following output:
> >
> > Jul 10, 2009 10:20:49 AM com.calenco.resource.WorkspacesResource represent
> > INFO: MediaType = */*
> > Jul 10, 2009 10:20:49 AM com.calenco.resource.WorkspacesResource represent
> > INFO: Request processed in 0.045 sec.
> > Jul 10, 2009 10:20:49 AM org.restlet.engine.log.LogFilter afterHandle
> > INFO: 2009-07-1010:20:490:0:0:0:0:0:0:1 - - 8182
> > GET /workspaces - 200 - - 1410
> > http://localhost:8182 Mozilla/5.0
> > (X11; U; Linux i686; en-US; rv:1.9.0.11) Gecko/2009060308 Ubuntu/9.04
> > (jaunty) Firefox/3.0.11-
> >
> > And this happens no matter the value of the Accept header, for example
> > with curl:
> >
> > curl -uad...@host:password -HAccept:text/xml
> > http://localhost:8182/workspaces
> >
> > gives me this on logs:
> > Jul 10, 2009 10:27:13 AM com.calenco.resource.WorkspacesResource represent
> > INFO: MediaType = */*
> > Jul 10, 2009 10:27:14 AM com.calenco.resource.WorkspacesResource repres
Re: Guidance on Atom/APP in Restlet
One way I've worked with Atom services within Restlet is to use freemarker templates to generate atom representations and use an XML parser to parse entity bodies of APP POST/PUT requests. This allows me to extract the data I'm interested in without pulling the whole Atom tree into memory as Rome would. A nice side effect of this design is that my resources support con-neg and can also return and process hAtom micro-formatted HTML and JSON (both generated using freemarker as well). One more note, Atom XML is great to use when you need to support generic APP clients, but if you control both the client and server I'd seriously consider using JSON (while also supporting Atom). JSON tends to push fewer bytes across the wire is infinitely easier to parse in a browser (I'm not an XML hater, but when you need to support IE 6). Dave On Fri, Jul 17, 2009 at 2:00 PM, Tim Peierls wrote: > Thanks, Stephen, this is very helpful. > --tim > > On Fri, Jul 17, 2009 at 3:01 PM, Stephen Groucutt > wrote: >> >> I'll qualify this by saying that I know of plans to use APP in enterprise >> applications, but I haven't ever actually seen anything in the enterprise. >> There's a good presentation on APP's capabilities in non-trivial >> environments over at >> http://qconsf.com/sf2007/presentation/Building+your+next+service+with+the+Atom+Publishing+Protocol >> that you might find helpful if you haven't already read it. >> >> To my mind, the thing APP really has going for it in terms of how it >> applies to the REST world is that it is a media type that allows for the >> fulfillment of the "hypermedia as the engine of application state" part of >> Dr. Fielding's thesis. You can use the feeds, the links in the feeds, and >> some microformats you can develop specifically for your program domain, to >> develop APIs. Links can send your clients to the next step of your >> workflows, if the clients understand your microformats. If you google >> around for restbucks, you should find a good presentation on that kind of >> stuff. In theory, it sounds great (but again, I haven't seen it done >> myself). >> >> As to what extensions are best, I was working on Atom stuff back around >> 1.2 milestone 4 or so, and at that time I found it easiest to use ROME to >> offer up feed representations instead of the Restlet Atom extension, so I >> can't say much about what would work best now. >> >> On Fri, Jul 17, 2009 at 2:32 PM, Tim Peierls wrote: >>> >>> Some rambling newbie Restlet design questions: >>> Background: I'm in the preliminary stages of a ground-up redesign of an >>> existing non-Restlet application. I'm (naturally) convinced that Restlet is >>> the way to go for this redesign, and I'm pretty sure I want the UI to be >>> GWT-based. So far so good ... GWT-Restlet is alive and well. (And I'll get >>> cracking on a Restlet-Guice extension before too long, or not, depending on >>> how you define "too".) >>> My analysis of the existing application keeps leading me to the Atom >>> Publishing Protocol, because the key elements of that application "feel" >>> like collections of publishable/updatable resources (and collections of such >>> collections). It doesn't fit the canonical examples of APP, however, which >>> leads to my first questions: Does anyone know of APP being used successfully >>> outside of the usual document/news item examples that everyone uses to >>> explain it? If so, what criteria would you use to determine whether APP is >>> really appropriate to my resource design? >>> I'm sort of hoping the answer is a resounding yes to this, in which case >>> my second question is: If I want to design my application around APP but I >>> don't intend to use a file-based storage system like eXist, what does >>> Atomojo have for me that the Restlet Atom extension doesn't? Is there >>> something else that I should know about? >>> --tim >> > > -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2372172
Re: Guidance on Atom/APP in Restlet
Thanks, Stephen, this is very helpful. --tim On Fri, Jul 17, 2009 at 3:01 PM, Stephen Groucutt < stephen.grouc...@gmail.com> wrote: > I'll qualify this by saying that I know of plans to use APP in enterprise > applications, but I haven't ever actually seen anything in the enterprise. > There's a good presentation on APP's capabilities in non-trivial > environments over at > http://qconsf.com/sf2007/presentation/Building+your+next+service+with+the+Atom+Publishing+Protocolthat > you might find helpful if you haven't already read it. > > To my mind, the thing APP really has going for it in terms of how it > applies to the REST world is that it is a media type that allows for the > fulfillment of the "hypermedia as the engine of application state" part of > Dr. Fielding's thesis. You can use the feeds, the links in the feeds, and > some microformats you can develop specifically for your program domain, to > develop APIs. Links can send your clients to the next step of your > workflows, if the clients understand your microformats. If you google > around for restbucks, you should find a good presentation on that kind of > stuff. In theory, it sounds great (but again, I haven't seen it done > myself). > > As to what extensions are best, I was working on Atom stuff back around 1.2 > milestone 4 or so, and at that time I found it easiest to use ROME to offer > up feed representations instead of the Restlet Atom extension, so I can't > say much about what would work best now. > > On Fri, Jul 17, 2009 at 2:32 PM, Tim Peierls wrote: > >> Some rambling newbie Restlet design questions: >> >> Background: I'm in the preliminary stages of a ground-up redesign of an >> existing non-Restlet application. I'm (naturally) convinced that Restlet is >> the way to go for this redesign, and I'm pretty sure I want the UI to be >> GWT-based. So far so good ... GWT-Restlet is alive and well. (And I'll get >> cracking on a Restlet-Guice extension before too long, or not, depending on >> how you define "too".) >> >> My analysis of the existing application keeps leading me to the Atom >> Publishing Protocol, because the key elements of that application "feel" >> like collections of publishable/updatable resources (and collections of such >> collections). It doesn't fit the canonical examples of APP, however, which >> leads to my first questions: Does anyone know of APP being used successfully >> outside of the usual document/news item examples that everyone uses to >> explain it? If so, what criteria would you use to determine whether APP is >> really appropriate to my resource design? >> >> I'm sort of hoping the answer is a resounding yes to this, in which case >> my second question is: If I want to design my application around APP but I >> don't intend to use a file-based storage system like eXist, what does >> Atomojo have for me that the Restlet Atom extension doesn't? Is there >> something else that I should know about? >> >> --tim >> >> > -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2372163
Re: Guidance on Atom/APP in Restlet
I'll qualify this by saying that I know of plans to use APP in enterprise applications, but I haven't ever actually seen anything in the enterprise. There's a good presentation on APP's capabilities in non-trivial environments over at http://qconsf.com/sf2007/presentation/Building+your+next+service+with+the+Atom+Publishing+Protocolthat you might find helpful if you haven't already read it. To my mind, the thing APP really has going for it in terms of how it applies to the REST world is that it is a media type that allows for the fulfillment of the "hypermedia as the engine of application state" part of Dr. Fielding's thesis. You can use the feeds, the links in the feeds, and some microformats you can develop specifically for your program domain, to develop APIs. Links can send your clients to the next step of your workflows, if the clients understand your microformats. If you google around for restbucks, you should find a good presentation on that kind of stuff. In theory, it sounds great (but again, I haven't seen it done myself). As to what extensions are best, I was working on Atom stuff back around 1.2 milestone 4 or so, and at that time I found it easiest to use ROME to offer up feed representations instead of the Restlet Atom extension, so I can't say much about what would work best now. On Fri, Jul 17, 2009 at 2:32 PM, Tim Peierls wrote: > Some rambling newbie Restlet design questions: > > Background: I'm in the preliminary stages of a ground-up redesign of an > existing non-Restlet application. I'm (naturally) convinced that Restlet is > the way to go for this redesign, and I'm pretty sure I want the UI to be > GWT-based. So far so good ... GWT-Restlet is alive and well. (And I'll get > cracking on a Restlet-Guice extension before too long, or not, depending on > how you define "too".) > > My analysis of the existing application keeps leading me to the Atom > Publishing Protocol, because the key elements of that application "feel" > like collections of publishable/updatable resources (and collections of such > collections). It doesn't fit the canonical examples of APP, however, which > leads to my first questions: Does anyone know of APP being used successfully > outside of the usual document/news item examples that everyone uses to > explain it? If so, what criteria would you use to determine whether APP is > really appropriate to my resource design? > > I'm sort of hoping the answer is a resounding yes to this, in which case my > second question is: If I want to design my application around APP but I > don't intend to use a file-based storage system like eXist, what does > Atomojo have for me that the Restlet Atom extension doesn't? Is there > something else that I should know about? > > --tim > > -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2372149
Guidance on Atom/APP in Restlet
Some rambling newbie Restlet design questions: Background: I'm in the preliminary stages of a ground-up redesign of an existing non-Restlet application. I'm (naturally) convinced that Restlet is the way to go for this redesign, and I'm pretty sure I want the UI to be GWT-based. So far so good ... GWT-Restlet is alive and well. (And I'll get cracking on a Restlet-Guice extension before too long, or not, depending on how you define "too".) My analysis of the existing application keeps leading me to the Atom Publishing Protocol, because the key elements of that application "feel" like collections of publishable/updatable resources (and collections of such collections). It doesn't fit the canonical examples of APP, however, which leads to my first questions: Does anyone know of APP being used successfully outside of the usual document/news item examples that everyone uses to explain it? If so, what criteria would you use to determine whether APP is really appropriate to my resource design? I'm sort of hoping the answer is a resounding yes to this, in which case my second question is: If I want to design my application around APP but I don't intend to use a file-based storage system like eXist, what does Atomojo have for me that the Restlet Atom extension doesn't? Is there something else that I should know about? --tim -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2372142
Re: REST in mobiles
You can definitely run a web server on your phone. The bigger issue you will encounter is that your mobile device almost definitely doesn't have a routable IP and is most likely behind several NATs and FWs. What are you trying to do? dave On Fri, Jul 17, 2009 at 4:14 AM, feda abdul wrote: > I am new to RESTFul web services and > Iwould like to know if itis possible implementing RESTFul web services on > mobile devices acting as server and consumed from other desktop or mobile > devices. Thanks > > -- > http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2372023 > -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2372128
Re: Receive a multipart HTTP response
Check out org.restlet.ext.fileupload. Its a representation wrapper around apache file upload that will allow you to parse multipart uploads. dave On Fri, Jul 17, 2009 at 8:02 AM, Evgeny Shepelyuk wrote: > Hello > > We're about to develop application that should read data from video camera. > Data from camera is sent via HTTP as single multipart _response_. > > My question is ift convenient and possible to use restlet to read such > kind of data. > Is there any possibilities not to manually read boundaries header from > input stream > but rather use some high-level api. > Smth like > > reponse.getNextPart() - > this return bytes of next chunk from stream. > > Referring to this article at StackOverflow/ > > http://stackoverflow.com/questions/419850/java-receive-a-multipart-http-response > > -- > Regards, > Evgeny Shepelyuk > > -- > http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2372092 > -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2372127
Receive a multipart HTTP response
Hello We're about to develop application that should read data from video camera. Data from camera is sent via HTTP as single multipart _response_. My question is ift convenient and possible to use restlet to read such kind of data. Is there any possibilities not to manually read boundaries header from input stream but rather use some high-level api. Smth like reponse.getNextPart() - > this return bytes of next chunk from stream. Referring to this article at StackOverflow/ http://stackoverflow.com/questions/419850/java-receive-a-multipart-http-response -- Regards, Evgeny Shepelyuk -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2372092
REST in mobiles
I am new to RESTFul web services and Iwould like to know if itis possible implementing RESTFul web services on mobile devices acting as server and consumed from other desktop or mobile devices. Thanks -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2372023
beginner question about Resource
Hello,
I'm new to rest and restlet, and I'm a trying to make a demo/sample to
help management to choose between rest framework.
I have read restlet faq and wiki to find some info, and it has been a
great help, but now I'm stuck with a problem for a beginner.
I need to handle several GET and POST in a /ServerResource/ child class.
I have declared variants in /doInit/ method, such as
TEXT_HTML,TEXT_PLAIN,APPLICATION_JSON.
I have method returning a /Representation/ with annoted GET such as :
@Get("json") public Representation toJson() {}
@Get("html") public Representation toHtml() {}
@Get("text") public Representation toText() {}
and I have also a method
@Override public Representation get(Variant variant)
where I build a representation suitable for the specified variant
MediaType (using variant.getMediaType() )
When I test, using cURL or a junit test case :
If a specify in my /Request/ object (or in cURL using -H "Accept:
text/html") a MediaType.TEXT_HTML,
this is handle through /get(Variant)/ method.
If the MediaType is APPLICATION_JSON, this go through /toHtml()/ method.
What am I doing wrong ? any clue ?
Thanks,
Laurent.
--
Laurent Rustuel,
Alten contractor for Genesys, an Alcatel-Lucent Company
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2372044
Re: Question about 'org.restlet.engine.Engine.registerHelper(ClassLoader, URL, List, Class)'
Hi, Marcelo Paternostro wrote: > My environment is: > > - Eclipse 3.5 > - The Jetty support offered by Eclipse > > So I've added all 'org.mortbay.jetty.*' bundles that come with Eclipse plus > 'org.restlet.ext.jetty' to the class path and run the basic restlet example > just to see it dying in a NoClassDefFoundError agony. > > After a lot of digging, I understood the problem: > 'org.restlet.ext.jetty.jar!/META-INF/services/org.restlet.engine.ServerHelper' > declares 3 helpers (AJP, HTTP, HTTPS) and Eclipse has support for only one > of them (HTTP). So when the method in the subject tries to load the other > helper classes (for AJP and HTTPS), everything breaks down due to the fact > that their dependencies are not in the class path. > > I manage to hack a workaround by overriding the referred method to ensure > that only the HTTP helper is registered. Everything seems to be working fine > now. I have 2 question though: > > 1. > Can anyone foresee a problem on my approach (other than not having AJP and > HTTPS)? The Jetty extension in Restlet (org.restlet.ext.jetty.jar) provides AJP, HTTP and HTTPS connectors indeed, but they're effectively using Jetty directly within a stand-alone Restlet application, rather than Restlet within a Jetty container. If you want to use Restlet within the Jetty container offered by Eclipse, you should the Servlet extension instead: this can run Restlet applications and components within an Servlet environment. It is documented here: - http://www.restlet.org/documentation/1.1/faq#02 - http://www.restlet.org/documentation/1.1/ext/com/noelios/restlet/ext/servlet/ServerServlet.html Best wishes, Bruno. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2372055
Re: Restlet SSL and Weblogic (even tomcat would help)
Hello, Andrew Whelan wrote: > Hello, > > I am trying to deploy a Restlet application as a Servlet to weblogic using > SSL for authentication and authorization. I have successfully gotten the SSL > authentication to work with my Restlet, running it as a Java application > using the default Jetty > container. Now I'm trying to deploy it to weblogic. > > I am trying to use mutual authentication. > I have client and server keystores and a trustore for each. I used OpenSSL to > create a certificate authority and have signed > client and server certificates correctly imported into their respective > truststores. > > I have the SSL code used for the class that extends org.restlet.Application. > That class gets associated with the necessary > org.restlet.application context-param in the web.xml when trying to configure > the servlet(see it below the code). > > Besides > A)The code in the class below that extends Application > B)The content of the web.xml that follows the class > C)Adding a user with a username that matches that of the distinguished name > of the client certificate > > Should I have to do anything else? [...] > > > > Data Services > /* > GET > POST > PUT > > > user > > > CLIENT-CERT > > > > > user > > > > In Tomcat, with a traditional Servlet, when the connector isn't configured to ask for a client certificate (not sure if you have done so), the settings you're using would trigger a re-negotiation (a new SSL/TLS handshake which will ask for a certificate). As far as I know, this feature isn't supported in Jetty (in-built or as a full container). I would have expected com.noelios.restlet.ext.servlet.ServerServlet not to behave differently from other Servlets in that respect (even if it would ignore the container's roles). In the configurations I got to work using this approach (with JSP or other servlets), the and elements are outside (just after) the element, and also use : My Webapp ... App / cert CONFIDENTIAL CLIENT-CERT cert Another solution is to configure the connector (rather than the webapp) to ask for the client certificate. In this case, there is no re-negotiation, since the client certificate is requested during the first handshake when the client makes the connection. I'm not sure how this is done in Weblogic, but in Tomcat, it's in server.xml: You get three choices for 'clientAuth': - "false": no client auth, - "want": requests a client certificate, but it's optional, - "need": requires a client certificate; if the client doesn't give one, the connection will be closed at the SSL/TLS level, without giving the server the opportunity to send an error page. Best wishes, Bruno. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2372018
