I'm Solomon Duskis, NYC consultant and a Java/J2EE guy. I work at Sungard Consulting Services in NYC. The postings on this site are my own and do not necessarily represent the positions, strategies or opinions of my employer. Solomon is a DZone MVB and is not an employee of DZone and has posted 22 posts at DZone. You can read more from them at their website. View Full User Profile

RESTEasy Wishlist

04.15.2010
| 8666 views |
  • submit to reddit

Here are some stuff that I've been working on with RESTEasy. I simply don't have enough free time to spend on all of these. I'm hoping that this list will serve as a reminder about the important things I'm working on. I'm also hoping that this will serve as a method of other developers joining in the efforts to build some interesting functionality. Some of this functionality will simply come down to additional documentation of existing features.

  1. Pluggable annotation handling

    1. Pluggable method parameter annotation handling - Allow users to plug in their own behavior via annotations - for example, accessing session attributes or classing Servlet requestParameter (form/query parameter abstraction). Allow users to plug in their own annotations for existing behavior (such as Spring MVC annotations).
    2. Pluggable method and class handling - Allow additional handling of method finding. Allow additional annotation based post response construction processing (for example, 404 status instead of 204, additional cache header capabilities)
  2. Security - this is a common need of REST frameworks. There are solutions, but there needs to be a lot more before we're "there."

  3. Input Validation - this is a common feature of MVC frameworks. REST frameworks should have them as well. I know that Restlet has some kind of integration. I was also able to cobble together hibernate-validator with RESTEasy using Spring AoP. There should be an easier way to do that.

    The biggest issue here, IMHO, is defining requirements. Which status should be returned for which type of invalid input? URL parameters validation errors might return 404 (Not Found) while query/form parameter errors might return 400 (Bad Request). What should the body of the result message look like? HTML? JSon/XML? There are quite a few questions here, and no really "standard" yet that I've seen. IMHO, REST validation requires standardization

  4. Tighter integration with marshalling frameworks - Deep integration between RESTEasy/JAX-RS and the XML/JSon/YAML marshalling framework.

    1. Reusing Converter frameworks - Marshalling converters and Controller converters have a lot in common. They both need to take Strings and convter them to objects (or vice versa). Give the end user (the REST programmer) a consistent interface (API) for both body (un)marshalling and header (un)marshalling.
    2. HATEOAS - representing relationships and future actiosn as <link href=".." rel=".." > or something similar. I had some ideas, and apparently, Marc Headly, the JAX-RS spec co-lead, is working on HATEAOS as well.
    3. Context based marshalling - for example, in some resoures you want an object to be fully marshalled, and in others you want to expose only some information. Allow a user to do that in a declarative manner.
    4. Client-side Proxy based Lazy Loading - the client side should use <link href=".." rel=".." >'s to GET the next "application state". Allow simple ORM like lazy loading. This requires some deep integration between RESTEasy and a marshalling framework.
  5. RESTEasy Client: The Next Generation - The RESTEasy client is pretty cool already, but there are some ideas to make it even cooler.

    1. Client-side Proxy based Lazy Loading - this heavily depends on tighter integration with the marshalling framework.
    2. Annotation base Responses - Right now, there's a class structure for responses.
    3. Pluggable annotations - Custom annotations should be simple. Why not use Spring MVC's annotations here as well?
    4. Asynchronous clients - Ning has it... I want it (and the Jersey team is working on it... see the comments on the Ning link). Keep a comet connection open, and stream in data. Perhaps wrap Ning's client in RESTEasy somehow.
  6. Pluggable Metadata handling - JAX-RS and other metadata, such as validation annotations, Spring bean definitions and custom annotations, are pretty useful. Sure, you can map HTTP requests to methods with JAX-RS annotations, but you can do so much more with them. RESTEasy already allows you to generate. What this will give:

    1. Management consoles
    2. Auto-generated JavaScript APIs
    3. Auto-generated Test pages
  7. Pluggable cross system behavior - RESTEasy is very pluggable right now. You can do some pretty neat tricks with it... Hopefully, they're documented enough. There's always additional room for improvement. This would be features like:

    1. Customized exception handling
    2. Customized handling of "Not Found" scenarios
  8. Package Refactoring - the resteasy-jaxrs project got big. It's probably time to take out the client into resteasy-client. There are probably some other changes as well, although doing things like may break backwards compatibility, if it's not done carefully... I'm sure that Bill Burke has done this kind of thing before :).

There are definitely plenty of items that I forget... so much to do, and so little time. I definitely can't do all this myself... I hope I can "marsall" some assistance. I also need to have some conversations with REST experts on these items... I really should go to the WS-REST convention that's taking place this month. I should also use my recent promotion to Principal to further the OSS culture at SunGard Consulting.

 

From http://www.jroller.com/Solomon/entry/resteasy_wishlist1

Published at DZone with permission of Solomon Duskis, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Tags:

Comments

Robin Bygrave replied on Thu, 2010/04/15 - 5:38pm

Hi Solomon,

I have been working on something related to Context based marshalling.

 

As an example:

Get the customers using default representation

/customer

Get customer 3 using default representation

/customer/3

 

If for a given use case the client wants a more specific representation of customer. Lets say the client is interested in the customers id, name  ... the contacts for that customer ... with the contact lastName and email address.

Get the customers... but specifying which properties 

/customer:(id,name,contacts(lastName,email))

 

 ... and do this for customer 3

/customer:(id,name,contacts(lastName,email))/3

 

I have done this from an ORM perspective (I'm a committer for Ebean ORM). The marshalling and the ORM query both take into account the explicit properties requested (this is an Ebean ORM jax-rs integration module).

Anyway, I'm getting close to finishing off the first version of this and at the moment it is JSON only. I'm looking for critical feedback.

Assuming this is roughly what you meant by context based marshalling then I'd be interested in any comments.

Cheers, Rob.

Solomon Duskis replied on Thu, 2010/04/15 - 8:35pm

Hey Rob,

I'm glad to hear that someone on the ORM side is looking into this as well.

You hit the nail on the head about "contextual marshalling." While my implementation would have a slightly different nuance, the overall idea is the same.  My thoughts are that Order objects found at /customer/3 have "basic" information, Order objects found at /customer/3/orders have "medium" information and /order/1294 has "full" Order information.  Overall, the idea is the same... something in the URL dictates what gets marshalled.

Robin Bygrave replied on Fri, 2010/04/16 - 12:58am in response to: Solomon Duskis

http://www.slideshare.net/linkedin/building-consistent-restful-apis-in-a-highperformance-environment

The above is a presentation from some "linkedin" folks regarding their rest API (presented at JavaOne).

You can see my effort was inspired by this and the potential performance implications (as it can reduce the number of requests required (chattiness) for a given use case and optimise the ORM query at the same time).

Slide 7 talks about "Variety versus Uniformity".  The thought is that you start with "basic" and "full" representations and then the API gradually increases over time....  The documentation of the API also increases and developers need to read though the documentation to find the closest representation that fits their needs.

So the idea behind providing the option to do something like ":(name,id,contacts(*))" ... is to stop API explosion. The client can have the option of requesting exactly what they want without any additional API on the server side (or any extra work on the server side). 

At least that's the thoughts behind it anyway.

Note: This works for partial updates as well. You only need to put back the parts of the object graph you want to update (with preferably the @Version property for optimistic concurrency checking).

Cheers, Rob.

Berita Terkini replied on Wed, 2013/10/23 - 1:16am

Dapatkan informasi berita hari ini terkini dari situs berita liputan6.com

kabar timnas indonesia terbaru hari ini, kabar liga inggris terbaru hari ini, kabar bunda putri terbaru hari ini, kabar ratu atut terbaru hari ini, kabar demo buruh terbaru hari ini dari situs berita terbaru hari ini Liputan6.com

Markoio Skario replied on Fri, 2014/08/22 - 10:16am in response to: Berita Terkini

This works for partial updates as well. You only need to put back the parts of the object graph you want to update. Croatia apartments holiday

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.