Discussions

News: Restlet, a REST framework for Java

  1. Restlet, a REST framework for Java (23 messages)

    Restlet is a new open source project that provides a concrete solution for people wanting to build solid applications following the REST architecture style defined by Roy T. Fielding.

    The mission of this open source project is to bring the simplicity and efficiency of the REST architectural style to Java developers. Concretely, it is composed of two parts:

    1) Restlet API
        * Supports all REST concepts (resource, representation, data, connector, components, etc.)
        * Suitable for both client and server REST applications
        * Maplets support the concept of URIs as UI with advanced pattern matching features
        * Chainlets filter calls to implement features like logging, authentication or compression
        * Complete alternative to Servlet API with no external dependency (JAR < 50kb)
        * Supports blocking and non-blocking NIO modes

    2) Noelios Restlet Engine (NRE)
        * Reference implementation of the Restlet API provided by Noelios Consulting (core JAR < 60kb)
        * Server connector provided: HTTP (via Jetty connectors)
        * Client connectors provided: HTTP, JDBC, SMTP (via JavaMail)
        * Support for logging (LoggerChainlet) and cool URIs rewriting (RedirectRestlet)
        * Static files serving (DirectoryRestlet) with metadata association based on file extensions
        * FreeMarker template representations as an alternative to JSP pages
        * Automatic server-side content negotiation based on media type and language

    Also, an introduction paper as well as a detailled tutorial are available.

    It's early in development (the current version is 0.18b) but comments are welcomed.

    Jerome Louvel
    http://www.restlet.org

    Threaded Messages (23)

  2. Just to kick off the debate..[ Go to top ]

    (But in a reasonable manner I hope..)

    I've worked with different types of SOAP..er.. I mean.. Web Services environments over time and have seen it grow from a minimal prototype concept to a rather overly complex environment it is today, however if I compare the basic SOAP request/response process with REST, what skews the advantage one way or another?

    For example, with common tools building a SOAP service is trivial and exporting the WSDL is automatic. (Same on the inverse for importing a WSDL and generating the access code) So for basic operations, what would be a driving factor to REST instead of SOAP?

    Are there fundamental differences in bandwidth characteristics? In handling different types of data types and objects? Interoperability? I ask this for comparison and certainly not to kick off any silly arguments of the type "my X is better than your Y" debates.

    The description of this REST project looks very nice, and it sounds like its been carefully planned out. I'm also curious if there is a REST framework (this one or another) that will tie into Spring in the same way that some of the SOAP engines do, to make service exporting a matter of configuration.

    thanks!
  3. Just to kick off the debate..[ Go to top ]

    Paul,

    I agree, let's not start a new debate on REST vs SOAP here, this subject has been discussed too many times already.

    In practice, REST-style HTTP has less need for a description API than SOAP. Check this recent discussion for details.

    Concerning the bandwidth, REST-style HTTP has the lowest requirements because there is no need for wrapping XML envelopes like with SOAP. Business documents (also called resource representations) are directly exchanged, in any media type (XML, Word, text, etc.) that makes sense.

    Integration with Spring is considered but that may make more sense to leave that to the Spring project experts.

    Thanks,
    Jerome
  4. Restlet, a REST framework for Java[ Go to top ]

    What would a minimal web application look like in Restlet ? I mean how easy would it be to build a simple todo list for instance.

    And what are the benefits of using Restlet over say struts or ruby on rils ?

    Regards

    Ian Purton
    Script Hosting
  5. Restlet, a REST framework for Java[ Go to top ]

    Ian,

    I encourage you to read tutorial and to tweak the examples. You should get a better feeling on how to build a web application with Restlets.

    As an indication, the http://www.restlet.org web site only runs with Restlets (using a Jetty HTTP connector) and its only based on two classes of about 250 lines (including comments and main method), with no additional configuration file!

    Concerning a comparison with Struts or Ruby on rails, that's an interesting question that we need to explore. If you are an expert with these frameworks I would appreciate your input. I would only say that integration with Struts or Spring or any other Java framework should be straightforward, even though you should feel less need to rely on a MVC-oriented framework if you design your application in a RESTful way.

    Thanks,
    Jerome
  6. This framework looks really neat. Having worked quite a bit with SOAP WS and dabbled with REST, I've been surprised that there hasn't been such a framework already. My conclusion is that REST lacks concrete guidelines, patterns and best practices. Sure its a just a "style", but this makes it difficult to concretely compare with SOAP alternatives.

    What would be nice is to have a sample app a la J2EE Pet Store implemented in a REST-like fashion and SOAP-based. Let's have a moderately complex multi-tier app with a DB and some realistic QOS. This way the discussion of SOAP vs REST could be grounded on some evidence. For example, implement the app using Axis and Restlet!
  7. Thanks for the compliments! I do hope that Restlets will provide a more practical approach to REST ideas.

    I think that the Pet Store project suggestion is great and would be happy to provide support to anyone willing to perform a complete and neutral comparison of both implementations (using Axis or another WS-* stack)!
  8. This is a new framework that seems to focus on scalability and performance. But does the actual observed performance provide a noticeable level of improvement over servlet based architechtures like Struts etc. ?
  9. I would like to make a precision: as you noticed, the Restlet framework has full provision for non-blocking NIO support, especially see the Representation interface. Basically, the Restlets don't control the actual writing on output streams or channels, this is only the responsability of the Restlet engine/container. This approach is impossible with Servlets and leads to scalability issues.

    With the latest Jetty connector (6.0 beta), NIO support has improved, but the full potential won't be leveraged for now. This is due to the fact that they also need to support the Servlet API with its inherent limitations regarding NIO. See this post from Jetty's author for details.

    I'm considering several ways to enable the full scalability potential of Restlets (including a custom HTTP connector). For now, all I can say is that Restlets are at least as performant as any Servlet engine, with the REST compliance in addition.

    Another important aspect regarding performance is the absence of any memory-based session mechanism in Restlets, contrary to Servlets. This would be absolutely contrary to REST principles. The benefit is that there is no need for complicated session persistence and distribution mechanism, a common bottleneck with Servlets.

    Jerome
  10. I would like to make a precision: as you noticed, the Restlet framework has full provision for non-blocking NIO support, especially see the Representation interface. Basically, the Restlets don't control the actual writing on output streams or channels, this is only the responsability of the Restlet engine/container. This approach is impossible with Servlets and leads to scalability issues.

    Ya know, I've heard that claim before, and sorta almost agree with it, however, Glassfish is running the Grizzly NIO based server and seems to be claiming some novel performance boosts and IS a Servlet container.

    Now, maybe it's "smart" and doesn't use the NIO part for Servlets/JSPs, but only for static resources -- but that seems like a whole lot of work for not a lot of practical gain. While it may benchmark well, many webapps are deployed fronted by a web server specifically for static content, so it would not really help the basic problem of delivering dynamic content.

    Or perhaps it is smart and uses NIO for the most common uses (like generic JSPs and such), but then, somehow, it must "know" that your application wants a stream that works like a stream, rather than just a place to dump bits in to. And I don't know of a way to specify that in the Servlet spec.

    So, anyway, Glassfish seems to be making good progress with its NIO implementation, even though it uses the Servlet spec.
  11. Grizzly, like Jetty 6, have NIO listeners that attempt to improve the performance. Basically, they use NIO to prevent the allocation of one thread per socket necessary with BIO. Then, as the Servlet API is based on the blocking BIO, they need to convert the outputstreams to NIO byte buffers/write channel. This appears to bring in more scalability (number of simultaneous connections) with a slightly lower throughtput.

    As the Restlet API is fully NIO compliant, we could also use features such a direct file to socket writing and memory-mapped files for static files. For dynamic representations, we could also prevent the conversions from BIO streams to NIO buffers.

    My understanding from this presentation of Grizzly and this blog entry from the author, is that Grizzly is only the HTTP listener and thread pool manager, not the actual Servlet container.

    That would be interesting to provide a Grizzly-based connector for Restlets and run benchmarks comparing the results on a PetStore application.
  12. Nice work from skimming over it. But I have a few remarks:

    Please don't confuse performance with scalability. Scalability is a metric of a software system that basically says how good a system can support a growing number of clients by increasing the number of physical servers (ideally the number of supported clients will increase/scale linearly with the number of physical servers...)

    As the previous posters mentioned: I doubt that the performance of "fully NIO" and "best of breed almost fully NIO" will be a huge difference. I would be surprised if it were more than a 10% difference. Also in this early development stage I wouldn't focus too much on performance. "Premature optimization is the root of all evil". And imho scalability is much more interesting than performance especially because Java has issues in this space and REST is an architectural style which addresses this very problem. Better invest your energy on API, integration, docs, samples...

    Given that assumption. I would recommend basing your implementation on the Servlet API and thus being able to run on any servlet container. This would imho also help with the adoption of your framework...

    Also I would recommend releasing the source of the restlet.org site because as you write it is implemented in restlets (so you basically have already one working sample app).
  13. Michael,

    Thanks for the feed-back. I used a larger definition of performance which includes both scalability and throughput but I'll try to be more precise in the future.

    I agree with your remark on optimization. My current priority is not the optimization of Restlets for NIO but functional coverage of RESTful applications. I'm happy with current HTTP connectors shipping (Jetty 5 and Jetty 6) as they provide a very stable foundation. However, I like the idea of a Servlet adapter which seems easily feasible, good point!

    I will also release the source code of http://www.restlet.org as a sample very soon, another excellent idea!

    Thanks,
    Jerome
  14. Version 0.19 beta has just been released.
    http://www.restlet.org

    Changes include a sample application detailling the source code of the Restlet and Noelios Consulting Web sites and a new Servlet-base HTTP server connector.

    Thanks for the suggestions Michael.
  15. Configuration[ Go to top ]

    Looking through the tutorial, this looks very nice. I notice that all configuration is done programmatically. Is it possible to configure a restlet server by xml file? Or using Spring?

    Regards
    Kit
  16. Configuration[ Go to top ]

    Hi Kit,

    Current there is no XML configuration available but this is definitely a feature that I want to add later. See the following issue: http://restlet.tigris.org/issues/show_bug.cgi?id=9

    However, that's not my top priority right now, I prefer to stabilize the API and the engine features first.

    I have not explored the integration with Spring yet, but that's another area of interest. If there are Spring experts that want to give some insight on this, that would be appreciated.

    Thanks,
    Jerome
  17. The future ...[ Go to top ]

    EJB died because of (its complexity and its price and) Hibernate and Spring.
    Servlet died because of REST and AJAX :)

    Conclusion:
    Opensource kills!
  18. HTTP Sessions[ Go to top ]

    I'd like to hear some opinions. Does the HTTP Session concept violate the statelessness of REST?

    I didn't notice anything session-related in the API, which is justifiable, but I think that support for sessions within the REST API (or an API extension) would be something I'd like to have available in an alternative Servlet technology.

    BTW, this all looks very promising for the future of Java web apps. Keep up the good work!
  19. HTTP Sessions[ Go to top ]

    Hi Joe,
    Does the HTTP Session concept violate the statelessness of REST?

    The way I see it: Yes it does, because one central guideline of REST is statelessness and because of that REST systems can be scaled easier than non-REST systems (which need things like sticky sessions or session replication to the other clustered servers).

    I have found these resources nice short introductions to REST:

    http://en.wikipedia.org/wiki/Representational_State_Transfer
    http://rest.blueoxen.net/cgi-bin/wiki.pl?ShortSummaryOfRest
    ...this all looks very promising for the future of Java web apps...

    I don't see REST as an advance productivity-wise because the abstraction level is much lower. But that is another story. What do RESTafarians think about this?
  20. HTTP Sessions[ Go to top ]

    I think that designing applications according to the REST style requires a kind of paradigm shift, from object-oriented modeling to resource-oriented modeling if you like.

    For some guidance on REST and sessions in particular, I recommand this paper from Paul Prescod:
    http://www.prescod.net/rest/mistakes/

    Concerning, the abstraction level I don't think Restlets are at a lower level than Servlets. If you consider not just the Restlet API but also the components shipping with the Restlet Engine (DirectoryRestlet and TemplateRepresentation based on FreeMarker for example), you have pretty much everything you need to build a fully featured web application. And you can always integrate with complementary frameworks if needed (Spring, EJB, etc.).

    Thanks,
    Jerome
  21. HTTP Sessions[ Go to top ]

    Concerning, the abstraction level I don't think Restlets are at a lower level than Servlets. If you consider not just the Restlet API but also the components shipping with the Restlet Engine (DirectoryRestlet and TemplateRepresentation based on FreeMarker for example), you have pretty much everything you need to build a fully featured web application. And you can always integrate with complementary frameworks if needed (Spring, EJB, etc.)

    For webapps with a browser-based GUI:
    From my point of view the Servlet level is low (even if you add a template mechanism). I was thinking more at the level of JSF or WebObjects. I think I have heard some frameworks can serialize (and encrypt) the http session of a client and send it to the client, but I don't remember which.

    For webservices:
    There shouldn't be a big productivity difference especially if you leverage those mentioned complimentary frameworks and I think this is what Jerome was speaking of in the first place.

    However, your mileage may vary...
  22. HTTP Sessions[ Go to top ]

    Apparently the Spring guys are already working on better REST remoting support. I hope that they come up with a nice workable solution (most times they do ;-)) and don't drop this issue.

    Take a look at this
    http://opensource2.atlassian.com/projects/spring/browse/SPR-976?page=all

    I would see that as a personal highlight for Spring 2.0.
  23. HTTP Sessions[ Go to top ]

    I think that designing applications according to the REST style requires a kind of paradigm shift, from object-oriented modeling to resource-oriented modeling if you like.

    Why not just call it the old fashioned way: from object orientation to procedural programming. Call it whatever fancy way you like, but doing 'method calls' by passing all state you might need is just that.

    As you might have guessed, I'm one of those persons that hate the direction Java has been going in this respect; whether it is with SOA, REST or whatever, it's all back to procedural programming again, and as long as you're not building the next Amazon, it's premature optimization in my book.
  24. HTTP Sessions[ Go to top ]

    Eelco,
    Why not just call it the old fashioned way: from object orientation to procedural programming.

    REST-style and what I designated as resource-oriented design means so much more than old procedural programming. First, we are talking about distributed Web applications. As you know, distributed objects don't work that well in large and loosely-coupled environments like the Web (refer to CORBA, DCOM and RMI experiences).
    Call it whatever fancy way you like, but doing 'method calls' by passing all state you might need is just that.

    I think you misunderstood me, I'm not advocating to pass all the session state between the clients and the server for each request. In REST, hypermedia can be used as the engine of application state: you can design differently to remove the need for sessions.

    Also, for authentication purpose, nothing prevents you from using cookies and a sessions store if the standard HTTP authentication mechanism is not usable for you. For example, I'm building a web site that is doing exactly this using db4o (a cool object-oriented database) as the authenticated sessions store.
    As you might have guessed, I'm one of those persons that hate the direction Java has been going in this respect; whether it is with SOA, REST or whatever, it's all back to procedural programming again, and as long as you're not building the next Amazon, it's premature optimization in my book.

    I don't think you can reduce the Java language to the current trends like SOA, REST and Web 2.0. Also, it's not incompatible to support object-orientation for complex local applications and resource-orientation for distributed ones.

    Until you can force any host to run the latest JVM, it will be hopeless to try to do distributed objects over the Web. It's better to standardize on documents (REST call them Representations) to exchange.

    As for premature optimization, my experience is that you don't need to be Amazon or eBay to be concerned by hardware cost and performance.

    Thanks,
    Jerome