This page is for brainstorming how REST support should work in XFire (or possibly a new project if xfire ends up being too heavy weight).
Dan's First Take
Creating a Service
Mapping data to method parameters
The information to invoke our service could come from a number of places:
- URI Path Info
- @Path(2) - would select the first query parameter - i.e. "123" in "/customer/123"
- @QueryParameter("customerId") - would select the query parameter with the name "customerId".
- @RegexPath("someregexexpression") - would select some stuff from the uri
- HTTP Headers
- @HttpHeader("customerId") - would select the HTTP header with the name "customerId"
- XML in a POST/PUT method
- This can be done with JAXB, XMLBeans, etc.
Mapping the Operations to URIs
This could be done in the interface a couple different ways. At the class level:
At the method level
At the service registration level:
Questions
- What is the best way to map operations to URIs?
- Is there a good syntax to map URI fragments to method parameters
- What about MIME?
- Should this framework allow non XML responses? i.e. could it return a JPEG? - the bigger question is can XFire support that....
Labels:

2 Comments
Hide/Show CommentsMay 22, 2006
bsnyder bsnyder
I've been thinking of this same concept in ServiceMix to allow for direct exposure of endpoints via HTTP methods (i.e., mapping endpoints to HTTP methods). I figured that the endpoint name could be used as the endpoint portion of the URI. I'd really like to see these two concepts come together because I think that ServiceMix would then be able to support REST in a manner that is sufficiently simple but still powerful for users.
May 22, 2006
Dan Diephouse
Yeah, that sounds like a good idea. Hiram echoed similar sentiments about method names.