Re: Protobuf, protocolbuffer
A while back I wrote a Restlet Representation that could be used for wrapping a protobuf. The code is in the issue tracker, but i never got around to cleaning it up such that it could be checked in. Unfortunately my current job makes contributing to Restlet (or any open source project) a bit painful, so I probably won't be able to finish the work. Dave On Wed, Apr 21, 2010 at 3:26 AM, Alexander J. Perez Tchernov < xas...@gmail.com> wrote: > I suppose it can be great if to choose "protobuf+gzip"/"protobuf+deflate" > (*) media-type. > > Some links as well ... > > *Protobuf* > http://code.google.com/p/protobuf-gwt/ > http://code.google.com/p/protobuf-js/ > http://code.google.com/p/google-web-toolkit/issues/detail?id=2649 > * > Rest* > http://code.google.com/p/gwt-rest/ > http://wiki.restlet.org/docs_2.0/13-restlet/275-restlet/144-restlet.html > > *Benchmarking* > http://code.google.com/p/thrift-protobuf-compare/wiki/Benchmarking > > (*) http://www.qos.ch/pipermail/logback-dev/2009-March/003889.html > > > On Wed, Apr 21, 2010 at 12:58 PM, Xavier M. wrote: > >> Hello, >> I would like to know if it is intended to use protobuf/protocolbuffer for >> exchanging compressed structured data over the net through Rest. >> http://code.google.com/p/protobuf/ >> http://code.google.com/intl/fr/apis/protocolbuffers/docs/overview.html >> >> regards >> Xavier >> > > > > -- > Best regards, > ~ Xasima ~ > -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2592800
Re: RESTful batch operations
The philosophical answer: RESTful HTTP doesn't have semantics to support BATCH operations. There has been conversations in the IETF about supporting a BATCH method, but it hasn't really gone anywhere. For servers that support HTTP pipelining you can issue multiple asynchronous GET requests, but I don't think this is what your really have in mind. The more practical solution: GDATA has an implementation of BATCH processing using POST based upon AtomPub. Its completely non-standard but you could potentially implement the protocol on top of RESTlet. Dave On Tue, Feb 2, 2010 at 8:21 AM, Erick Fleming wrote: > This is more of a REST question, but is anyone using Restlet to handle batch > operations? > For example: given the following resource: /api/blog/1/posts. I would like > to make client-side changes, then update them on one call. > I realize this is very SOAP like, but was wonder how Restlet users are > handling these sorts of Use Cases. > -- > Erick Fleming > -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2444223
Re: XML format in ATOM content element
Not sure about your formatting problem, but I thought i'd mention that
you need to add a namespace declaration (at the minimum use the
default namespace) on the XML within your atom:content element,
otherwise an XML processor is going to assume that your XML is in the
Atom namespace and many processors will fail. That said, why not use a
standard dialect such as hCard in xhtml to represent your contact
objects?
dave
On Mon, Dec 7, 2009 at 10:24 AM, Rob Lincourt wrote:
> Hi,
>
> I am trying to use the Restlet ATOM extension and I cannot figure out why
> I am losing the formatting of my element in the Atom document I am
> creating. Here is a piece of code from my class that extends ServerResource:
>
> public Representation getAtomFeed() throws IOException {
> Feed f = new Feed();
> Map attrs;
>
> f.setTitle(new Text(MediaType.TEXT_PLAIN, "Feed Title"));
>
> f.setId("some identifier");
>
> Person p = new Person();
> p.setName("me");
> f.getAuthors().add(p);
>
> Generator gen = new Generator();
> gen.setName("RESTlet");
> gen.setUri(new Reference("http://www.restlet.org";));
> gen.setVersion("2.0M6");
> f.setGenerator(gen);
>
> f.setUpdated(new Date());
>
> //Add feed links
> //...
>
> //Perform query that returns a map of strings.
> attrs = something.getAttributes(someValue);
>
> Entry entry = new Entry();
> entry.setUpdated(new Date());
> entry.setId(identifier);
>
> Content c = new Content();
> c.setToEncode(false);
>
> c.setInlineContent(new SaxRepresentation(MediaType.APPLICATION_XML) {
> �...@override
> public void write(XmlWriter writer) {
> for(Map.Entry e : attrs.entrySet()){
> try {
> writer.dataElement(e.getKey(), e.getValue() == null ? ""
> : e.getValue());
> } catch (SAXException e1) {
> e1.printStackTrace();
> }
> }
> }
> });
>
> entry.setContent(c);
>
> //Add entry links
> //...
>
> f.getEntries().add(entry);
>
> return f;
> }
>
>
> Here is the ATOM feed that this code creates:
>
>
> http://www.w3.org/2005/Atom";>
>
> me
>
> http://www.restlet.org"; version="2.0M6">RESTlet
> some identifier
> Feed Title
> 2009-12-07T13:03:04.79Z
>
> John Smith MD
> John
> Smith
> MD
>
> entry identifier
> 2009-12-07T13:03:07.65Z
>
>
>
> Is there a way to correct this format issue or I am completely off base with
> my resource code. Any help is appreciated.
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2428073
Supporting multiple types of authorization for a given route
I was wondering if anyone had experience offering multiple types of authorization (HTTP BASIC, HTTP DIGEST, OAUTH, etc.) for a given route using Restlet. It isn't immediately apparent to me what the best way to do this is using the ChallengeAuthenticator class. Also what is the status of the 1.1 OAUTH extension? Will it be reintroduced in the 2.0 cycle? Thanks, Dave -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2427494
Re: Newbie question about passing JSON object in a get request
If you're passing the JSON object as part of the URL it must be URL encoded.
Dave
On Sat, Nov 21, 2009 at 7:51 PM, Steven Headley wrote:
> I am trying to pass a JSON object in a restlet client get request as follows:
>
> final Client client = new Client(Protocol.HTTP);
> Log.info( "json = "+json);
> client.get("http://localhost:8080/greet"+"/"+json, new Callback() {
> �...@override
> public void
> onEvent(Request request, Response response) {
>
> This get request gives me the following error:
>
> 2009-11-21 22:49:08,921 [FATAL] Uncaught Exception:
> java.lang.IllegalArgumentException:
> Invalid character detected in URI reference at index '28': "{"
>
> any help would be appreciated.
>
> --
> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2422957
>
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2423232
Bug with getClientInfo().getPreferredVariant()
The HTTP spec section 14.1 states: "If no Accept header field is present, then it is assumed that the client accepts all media types. If an Accept header field is present, and if the server cannot send a response which is acceptable according to the combined Accept field value, then the server SHOULD send a 406 (not acceptable) response." So I'm wondering if from within the handle() method in a Restlet if the following code should return null: request.getClientInfo().getPreferredVariant(variants, this.getApplication().getMetadataService()); if a client's request does not include one of the variants in the variants List, so that a server can detect the situation and return 406. Right now it seems to return the first variant in the variant list. Thanks, Dave -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2423188
Re: GET and POST - Semantics vs. Function
Hi Andrew, It might be more useful if you could supply a more detailed example that is causing you headaches. Really the difference between POST and GET is idempotence. GET operations must be idempotent, not having side effects, while POST operations may have side effects as defined by the server. A good rule of thumb is that if a request returns data but doesn't change the state of the server, than GET should be used as it allows for sane client/intermediary caching. On Sat, Sep 12, 2009 at 12:21 PM, Schley Andrew Kutz wrote: > I'm faced with a dilemma. I'm trying to be a good RFC consumer and > stick with the true purpose of GET and POST (see > http://www.cs.tut.fi/~jkorpela/forms/methods.html > for a good discussion on the history of these two HTTP verbs). > Plainly put, GET is for retrieving data and POST is for creating data. > However, the problem lies in the fact that their purpose and their > data encoding mechanism are mutually exclusive. GET requests encode > data in the URL and POST requests encode data into the form. However, > it is not always desirable to issue a GET request with URL-encoded > data (login information for example), not is it always desirable to > POST data with a form (sometimes a query string will do). I actually disagree with this statement. Using GET to pass login parameters is fine, and in some cases preferable (particularly as it relates to client caching). If you're concerned about security, you should encrypt such requests using SSL (you really should do this regardless of the method used in this case). Also the URI RFC doesn't require that URI parameters be form encoded. You could as easily pass JSON, XML, etc. in the query string as long as it is properly escaped. Form encoding for these parameters is typically chosen as a pragmatic decision due to HTML. Dave -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2394479
Re: Guidance on Atom/APP in Restlet
On Tue, Jul 21, 2009 at 6:08 AM, Tim Peierls wrote: > Hmm, the wind is going out of my sails. I started by recognizing that > AtomPub seemed to be a natural fit for my domain, and now I'm looking at > JSON/serialized beans and "optional" plain Atom feeds. (Optional in the > sense that my main applications wouldn't need them, because they'd be > happily talking JSON.) Interestingly enough, when work first began on the AtomPub spec, there were some in the working group who were in favor of making the spec representation agnostic [*]. Even with its concentration on Atom as its representational format, the App spec for managing collections provides a pretty clear outline of how to use HTTP effectively for managing datasets. [*] One of the AtomPub spec authors clued me in to this a few months ago. > Anybody have anything encouraging to say about why I shouldn't just stick > with my existing DWR application? (www.directwebremoting.org) > --tim I haven't used DWR in probably 3 years so I'm sure some stuff has changed but let me enumerate my reasons for preferring a REST approach: 1) REST approach works with the web, RPC works against it. When you design your service API Restfully you get all the built in benefits of HTTP such as: cache support, security, scalability, wide client support, etc. This approach is proven. When using DWR you get none of these. DWR must push all requests over POST to ensure that no cache server accidentally caches a result thus breaking your app. Conversely when using DWR you can't leverage internet caching architecture that can help offload your servers. Furthermore, a restfully linked set of resources that support con-neg can support multiple representational types (such as HTML), thus your API is not just an API but also a static HTML website that can be indexed by search engines, and allows for a nice debugging interface in a browser. 2) Strongly defined server interface that is implementation agnostic. When using DWR, you essentially are exposing your server's Java methods and tying your client to that implementation. You can't replace your Java implementation with one in Ruby/C#/fill in the blank language, later. With the REST approach you are essentially defining an implementation neutral wire protocol. 3) Strong client/server separation. When using HTTP as your protocol, you're forced to acknowledge in your client code that you are accessing a remote resource and take this into account. One of the major flaws with RPC systems has been the attempt to give remote resources the appearance of being local, which just doesn't work well in practice. 4) Multiple client support. DWR only allows you to build your client in JavaScript (well at least in a well defined way). However, what happens when your service takes off and you want to support an iPhone Apps, Android Apps, Desktop widgets, etc. A well defined REST service may be reused across devices, because it defines a data model with well understood semantics. That said, from a software engineering perspective you need to look at your intended goals for your application and make a sane cost/benefit analysis. Dave -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2373212
Re: Receive a multipart HTTP response
On Fri, Jul 17, 2009 at 12:02 PM, Evgeny Shepelyuk wrote: > 2. we need to read long time multipart HTTP response item by item > 3. i think FileUpload extension will work only after complete read of input > stream. but in our case the request is "never" finished and the items should > be read from stream only when available. Sounds like you want to implement a comet client. I'm pretty sure you could achieve this using the apache fileupload streaming API. See http://commons.apache.org/fileupload/streaming.html. You would probably have to implement a callback api to asynchronously return data to your main application thread as it arrives. That said if you're outside of a browser have you considered using XMPP which as a protocol is much better suited for the purpose? dav > -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2372649
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: 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
Re: how to unsubcribe
Log into your tigris account at restlet.tigris.org. In the discussions section, there is a link to manage your subscriptions. Pretty self explanatory from there. dave On Tue, Jul 14, 2009 at 11:41 AM, ilango wrote: > Hi > I want to unsubscribe from this group. How would I do that? > > thanks > ilango > > > > --- On Mon, 6/1/09, Jerome Louvel wrote: > > From: Jerome Louvel > Subject: RE: get servletContext on GAE? > To: discuss@restlet.tigris.org > Date: Monday, June 1, 2009, 4:33 AM > > Hi Zsolt, > > Did you have a look at Restlet extension for Velocity? It doesn't need a > ServletContext. > > Otherwise, I've just changed the ServerServlet in SVN trunk to copy the > ServletContext into a special "org.restlet.ext.servlet.ServletContext" > attribute of both the Component's context and the Application's context. > > 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 : Zsolt Czinkos [mailto:czin...@gmail.com] > Envoyé : vendredi 22 mai 2009 00:49 > À : discuss@restlet.tigris.org > Objet : get servletContext on GAE? > > Hello > > Restlet 1.2 snapshot on GAE. > > Is it possible to get servletcontext on gae? How? I'd like to try > velocity, and need ServletContext for init Velocity engine. > > Thanks in advance, it must be a trivial question... > > > zsolt > > -- > http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=23526 > 94 > > -- > http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2357406 > > -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2371327
Re: Licensing question
Its probably worth mentioning that javax.xml.stream is part of the core Java SDK in version 1.6. I suppose that it is included in the Restlet distribution only to support building on java 1.5. If you're concerned you could distro your application against version 1.6 of Java. Also I doubt that javax.xml.stream is required for any the core Restlet classes. dave On Mon, Jul 13, 2009 at 12:29 PM, Jennifer Carlucci wrote: > > As part of clearing Restlet v1.4 through our legal team to include it in our > product, we did code scans of the javax.xml.stream package. The license.txt > shows that the bundle is licensed under CDDL, but the code scans show that > the source contains the BEA license. Does the CDDL license that's found in > the bundle override the BEA license that's found in the source? > > Thanks, > Jennifer Carlucci > > -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2371326
Re: Distributed Observer Pattern
You might want to check out the following IETF draft that proposes a standard for doing this with SIP. You'd probably want to follow at least the style of this proposal in your implementation. http://www.ietf.org/internet-drafts/draft-roach-sip-http-subscribe-01.txt dave On Mon, Apr 20, 2009 at 8:03 AM, Jurrie Overgoor wrote: > Hello everyone, > > I'd like to implement something based on the Distributed Observer Pattern as > described by Duncan Cragg on > http://duncan-cragg.org/blog/post/distributed-observer-pattern-rest-dialogues/ > > When a "client" GETs a resource, I like it to send an extra header saying it > wants to receive a POST when the resource is updated. When the resource is > updated, it POSTs to the clients URL and removes it from the list of clients > to notify. The client then fetches the resource again with a GET (updating > caches in the process), and subscribes again. > > In the resource, I need to store the URL of the clients that it needs to call > when it is updated. But in Restlet, resources are created every request. > Where should I store the list of URLs? > > -- > http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1825957 > -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1847272
Re: ServerResource conditional mode
Have you considered that having a generic server resource might be a bit to simplistic or not granular enough? I guess from my point of view the resource class is really the implementation of the gritty protocol details of your application. I'm wondering if at least in addition to ServerResource, if resources such as AtomPubCollectionResource and AtomPubEntryResource would be useful to implementors who want to use standard RESTful protocols without needing to dig into the details. thanks, Dave -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1634241
Re: Resource factories
Out of curiosity is there a reason why Resource isn't implemented as a subclass of Restlet? It seams like there is a lot of overhead in initializing a new Resource on every request especially when a lot of salient features such as what methods,variants, etc that are supported tend to static for a give route to that resource. Thanks, Dave On Mon, Mar 23, 2009 at 11:46 AM, Rob Heittman wrote: > I'd be careful of judgement-words like "bad practices" since this implies > some universal level of harm in all cases. I think the current Finder > design is simplistic, flexible, and easy to implement. I think there is > also room for a more structured base implementation that exposes some > advantages for more complex resource object hierarchies. I don't think > these are mutually exclusive. > > On Mon, Mar 23, 2009 at 2:34 PM, Tal Liron > wrote: >> >> Good point, Rhett. >> >> Well, let me put it this way -- do you think the current Finder design >> encourages bad practices for Restlet users? >> >> -Tal > > -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1392294
Re: File upload - as stream
Apache File Upload supports a stream API. (see http://commons.apache.org/fileupload/streaming.html) You should be able to use it with RestletFileUpload. dave On Sun, Mar 8, 2009 at 10:41 AM, Matt Rutherford wrote: > Hi. > > Is there a way to receive a file element from an html form without storing > it to disk? > > I will be storing the file directly into a DB so no need to have it on disk > anywhere. > > Would be nice to just stream bytes to the LargeObject.write() Postgres JDBC > method. > > Sorry if this is a silly question, I'm a (enthusiastic) beginner with this > stuff. Any guidance much appreciated. > > Thanks! > > -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1298336
Re: Integrating WADL and Spring
It would be nice if you could allow more fine grain configuration support via WADL, including adding Guards to resources, configuring what methods and variants a resource supports via WADL etc. I added some technical suggestions in the bug itself. dave On Mon, Mar 9, 2009 at 10:02 AM, Jerome Louvel wrote: > Hi all, > > This is a good idea indeed. I've made a first step by updating > WadlApplication to make it easy to customize the way resources are created > based on the WADL resource descriptor, as suggested by Rhett. > > 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 : Rhett Sutphin [mailto:rh...@detailedbalance.net] > Envoyé : dimanche 8 mars 2009 03:07 > À : discuss@restlet.tigris.org > Objet : Re: Integrating WADL and Spring > > Hi David, > > On Mar 6, 2009, at 4:10 PM, David Bordoley wrote: > >> On Fri, Mar 6, 2009 at 11:32 AM, Rhett Sutphin >> wrote: >> >>> This would be an RFE (at least, I'm not aware of any way to get it to >>> work currently). I'm curious about how you would tie the resources >>> in your application context to the WADL. Would you add a custom >>> attribute for the spring bean id? Is there a WADL feature which >>> would help with this? I'm not that familiar with it. >>> >>> Rhett >> >> Hi, >> >> The current way WADL works in Restlet is to require implementors to >> specify the class of the resource you want to map a WADL resource to >> using the resource's id attribute. You then pass the the WADL xml as a >> constructor argument to a WadlComponent or WadlApplication. You can >> see an example of this in org.restlet.test.YahooSearch.wadl (omitting >> the details in the example below): >> >> >> http://api.search.yahoo.com/NewsSearchService/V1/";> >> > path="newsSearch"> >> >> >> >> >> It would be cool if you could do something similar but instead of >> passing a Resource class (and be stuck using the default constructor >> etc.), instead use a Spring Bean id as the resource id in WADL, and >> have restlet use spring to wire all the resources together, thus >> getting all the benefits of IOC, while also being able to more >> explicitly state your resource interface in a standard method. >> >> Anyway i can open an RFE if necessary, but I wanted to ask on the list >> first. > > This is a good idea. I think the implementation might be more generic than > just spring support, so I went ahead and entered the RFE against the WADL > component: http://restlet.tigris.org/issues/show_bug.cgi?id=756 > > Thanks, > Rhett > > -- > http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=12864 > 20 > > -- > http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1297634 > -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1298256
Re: Integrating WADL and Spring
On Fri, Mar 6, 2009 at 11:32 AM, Rhett Sutphin wrote: > This would be an RFE (at least, I'm not aware of any way to get it to > work currently). I'm curious about how you would tie the resources in > your application context to the WADL. Would you add a custom > attribute for the spring bean id? Is there a WADL feature which would > help with this? I'm not that familiar with it. > > Rhett Hi, The current way WADL works in Restlet is to require implementors to specify the class of the resource you want to map a WADL resource to using the resource's id attribute. You then pass the the WADL xml as a constructor argument to a WadlComponent or WadlApplication. You can see an example of this in org.restlet.test.YahooSearch.wadl (omitting the details in the example below): http://api.search.yahoo.com/NewsSearchService/V1/";> It would be cool if you could do something similar but instead of passing a Resource class (and be stuck using the default constructor etc.), instead use a Spring Bean id as the resource id in WADL, and have restlet use spring to wire all the resources together, thus getting all the benefits of IOC, while also being able to more explicitly state your resource interface in a standard method. Anyway i can open an RFE if necessary, but I wanted to ask on the list first. thanks, Dave -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1279214
Integrating WADL and Spring
Hi All, I've been playing around with Restlet for some projects I'm working on and have really enjoyed the platform. I'm wondering if there is a way to define your service in a WADL document but still use Spring to configure all your applications Resources, etc. In the abstract what I would like to do is is define a WADL but instead of using ID's which map to Java classes, map them to Spring bean ids, essentially use WADL as a replacement for SpringRouter. Any suggestions? Is this an RFE? Thanks, Dave -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1278554
