Skip to end of metadata
Go to start of metadata

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....
  • No labels

2 Comments

  1. 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.

  2. Yeah, that sounds like a good idea. Hiram echoed similar sentiments about method names.