Bill the Plumber

Software plumbing using middleware wrenches

  • My New Book

  • Recent Posts

  • Categories

  • Archives

REST-* Messaging Draft 5: new post and subscribe patterns

Posted by billburke on March 4, 2010

I’ve made some small changes to REST-* Message Draft 5.  First is to the reliable posting of messages to a message destination.  The second is to the push model default subscription creation method.

New post-message-once protocol

Previously, the post-message-once link used the POE pattern to avoid duplicate message posting.  I asked around and it seems that the POE pattern isn’t used a lot in practice.  I’m glad because it kinda breaks the uniform interface (unsafe GET) and isn’t really consistent with the other protocols I defined.  It is also very inefficient as you have to make two round trips to post each message.  Nathan Winder, on the reststar-messaging list suggested using a one-off link generated with each message post.  Here’s how it looks:

The post-message-once link URL provided by this link is not used to actually create a message, but rather to obtain a new, one-off, URL. An empty POST should be executed on the post-message-once link. The response provides a new “create-next” link which the client can then post their message to. The link is a “one-off” URL. What that means is that is that if the client re-posts the message to the create-next URL it will receive a 405 error response if the message has already successfully been posted to that URL. If the client receives a successful response or a 405 response, there should be a Link header returned containing a new “create-next” link that the client can post new messages to. Continuously providing a “create-next” link allows the client to avoid making two round-trip requests each and every time it wants to post a message to the destination resource. It is up to the server on whether the create-next URL is a permanent URL for the created message. If it is not permanent, the server should return a Content-Location header to the message.

post-message-once example

  1. Query the destination root resource for links.Request:
    HEAD /topics/mytopic HTTP/1.1
    Host: example.com
    

    Response:

    HTTP/1.1 200 OK
    Link: <...>; rel="post-message",
          <...>; rel="post-batch",
          <http://example.com/topics/mytopic/messages>; rel="post-message-once",
          <...>; rel="message-factory"
    
  2. Client performs a POST request to the post-message-once Link to obtain a create-next link.Request:
    POST /topics/mytopic/messages
    Host: example.com
    

    Response:

    HTTP/1.1 200 OK
    Link: <http://example.com/topics/mytopic/messages/111>; rel="create-next"
    
  3. Client POSTs message to create-next LinkRequest:
    POST /topics/mytopic/messages/111
    Host: example.com
    Content-Type: application/json
    
    {'something' : 'abitrary'}
    

    Response:

    HTTP/1.1 200 Ok
    Link: <http://example.com/topics/mytopic/messages/112>; rel="create-next"
    

Change to push model subscription

I also added a minor change to the push model’s subscriber registration protocol.  In the previous version of the spec, the client would post form parameters to a subscribers URL on the server.  The form parameter would define a URL to forward messages to and whether or not to use the POE protocol to post this message.  I changed this to simple require the client to post an Atom Link.  Since links define protocol semantics, the server can look at the link relationship registered to know how to interact with the subscriber when forwarding messages.  So, if the client registers a post-message-once link when it creates its subscription, the server knows how to interact with the link.  This gives the client and server a lot of simple flexibility in describing how messages should be forwarded.  For example:

This example shows the creation of a subscription and the receiving of a message by the subscriber.

  1. Client consumer queries topic resource for subscribers link.
    Request:

    HEAD /mytopic
    Host: example.com
    

    Response:

    HTTP/1.1 200 OK
    Link: <http://example.com/mytopic/subscribers, rel=subscribers, type=application/atom+xml
          ...
    
  2. Client does POST-Created-Location pattern to create subscriber
    Request:

    POST /mytopic/subscribers
    Host: example.com
    Content-Type: applicatin/atom+xml
    
    <atom:link rel="post-message-once" href="http://foo.com/messages"/>
    

    Response:

    HTTP/1.1 201 Created
    Location: /mytopic/subscribers/333
    
  3. A message comes in, the message service does a POST to this subscriber based on the interaction pattern described for post-message-once
    Request:

    POST /messages
    Host: foo.com
    

    Response:

    HTTP/1.1 200 OK
    Link: <http://foo.com/messages/624>; rel=create-next
    

    Request:

    POST /messages/624
    Host: foo.com
    Link: <http://example.com/mytopic/messages/111>; rel=self,
          <http://example.com/mytopic>; rel=generator
    Content-Type: whatever
    
    body whateve

Posted in REST, REST-star | Leave a Comment »

Study shows Republicans stupider

Posted by billburke on March 3, 2010

Ah, finally! a recent study shows what all us liberals already knew.  That conservatives are stupider.

Posted in flame bait | Leave a Comment »

Mapping response on client side

Posted by billburke on February 19, 2010

I’ve been prototyping a bit lately for the REST-* effort, specifically for BPM.  I rely heavily on Link headers to pass links around.  RESTEasy has become pretty decent at handling links on the client side.  Here’s an example of client request/responses and link following via link headers:

      InputStream jpdl = Thread.currentThread().getContextClassLoader().getResourceAsStream(file);
      ApacheHttpClientExecutor executor = new ApacheHttpClientExecutor();

      ClientRequest request = executor.createRequest("http://localhost:8081/bpm/definitions");
      request.body(mediaType, jpdl);
      Link definition = request.create();
      Assert.assertNotNull(definition);
      ClientResponse response = null;

      response = definition.request().head();
      Assert.assertEquals(200, response.getStatus());
      Link instanceFactory = response.getLinkHeader().getLinkByTitle("instances");

      MultipartFormDataOutput form = new MultipartFormDataOutput();
      form.addFormData("order", "$199.99", MediaType.APPLICATION_XML_TYPE);
      response = instanceFactory.request()
              .body(MediaType.MULTIPART_FORM_DATA_TYPE, form)
              .post();
      Assert.assertEquals(201, response.getStatus());
      System.out.println(response.getLinkHeader().toString());
      Link instance = response.getLocation();
      Assert.assertNotNull(instance);

      Link next = response.getLinkHeader().getLinkByTitle("continue");
      Assert.assertNotNull(next);

      Link variables = response.getLinkHeader().getLinkByTitle("variables");
      Link newVariables = response.getLinkHeader().getLinkByTitle("variable-template");

      response = variables.request().head();
      Assert.assertEquals(200, response.getStatus());
      System.out.println(response.getLinkHeader().toString());
      Link order = response.getLinkHeader().getLinkByTitle("order");
      String xml = order.request().getTarget(String.class);
      request = newVariables.request();
      response = request.pathParameter("var", "customer")
             .body(MediaType.APPLICATION_XML_TYPE, "bill")
              .put();
      Assert.assertEquals(201, response.getStatus());
      response = request.pathParameter("var", "customer")
             .body(MediaType.APPLICATION_XML_TYPE, "bill burke")
              .put();
      Assert.assertEquals(204, response.getStatus());

      response = next.request().post();
      Assert.assertEquals(204, response.getStatus());

The thing about this code, it is a little hard to read.  Because HTTP is being treated like a messaging API, the code is a conglomeration of simple API calls.  The RESTEasy client proxy framework provides a nice way to map Java method calls to HTTP requests.  It also allows you to map automatically, a response body to a Java object.  Unfortunately though, this doesn’t work that well for my usecases.  Because I’m relying a lot on Link headers to pass information around in REST-*, I need something that can represent an HTTP response as a whole in a nice way.

A POJO Response Mapping

So, I thought, why not define (or reuse JAX-RS annotations) to map an HTTP response to a Java POJO?  It would kind of be the opposite of the RESTEasy @Form feature (where form maps an incoming request to a POJO).  It could look something like this:

@ResponseMapping
@ExpectedCode(200)
public interface MyResponse {

   @Body
   public Customer getCustomer();

   @LinkHeader
   public Link getNext();

   @LinkHeader("last")
   public Link getLastCustomer();

   @Header("ETag")
   public String getHash();

}

In this example, the client code would be expecting a response code of 200 (OK), a message body converted to a Customer object, a Link header named “next”, and a HTTP response header “ETag”. Using the RESTEasy proxy framework, you could then return this as a method return value, i.e.

@Path("/customers")
public interface CustomerClient {

   @Path("{id}")
   @Produces("application/xml")
   public MyResponse getCustomer(@PathParam("id") int custId);
}

What about errors?

For responses where the response code does not match, you could define similar mappings on an exception class.

@ResponseMapping
@ExpectedCode(404)
public class NotFoundException extends RuntimeException {}

You’d integrate it with the RESTEasy proxy framework by putting it within the throws clause.

@Path("/customers")
public interface CustomerClient {

   @Path("{id}")
   @Produces("application/xml")
   public MyResponse getCustomer(@PathParam("id") int custId) throws NotFoundException;
}

What do you think?
Maybe I’m going a little overboard here. Maybe not? I don’t know. Let me know what you think.

Posted in JAX-RS, REST, RESTEasy, java, jboss | 6 Comments »

Speaking at new Boston JBoss User Group 2/9

Posted by billburke on February 2, 2010

Jesper Pederson has created a Boston JBoss User Group.  Our first meeting is next Tuesday, February 9th.  I’m the first speaker and will be giving an intro to REST, JAX-RS, and, if I have time, some of the stuff that we’re doing at REST-* (rest-star.org).  Please click here for more details.

Posted in JAX-RS, REST, REST-star, jboss | Leave a Comment »

Polling styles show difference between Coakley and Brown

Posted by billburke on January 15, 2010

I don’t know if you’ve been following Massachusetts politics, but there is a run-off election for the deceased senator Edward (Ted) Kennedy between Martha Coakley and Scott Brown.  I’ve been telephoned twice, once by each candidate’s supporters.  I think the difference in how these polls were conducted tell you a lot about the candidates.

Scott Brown’s poll:

It was automated and voice-recognition driven.   A long series of questions were asked before the final “Who will you vote for?” question.  Questions like “Does abortion affect who you will vote for?”, “Do you support a health bill that will add trillions in debt to our country?” “Do you believe in fiscal responsibility for our govt?”.  Very slick…

Marth Coakley’s call:

It was a person who first states “I’m from the Martha Coakley campaign”.  She asked if I knew there was an election on Tuesday and if I was going to vote.  She asked if I knew where the poll was.  She asked if any voting members of my family needed a ride to the poll and gave me a number to call if I didn’t have a ride.  That was it.  There was no “Who will you vote for?”  Nothing else.

If you’re a MA resident, I hope you vote on Tuesday.  Its a pretty important election no matter what side of the fence you sit on.

Posted in spam | 2 Comments »

dm to Eclipse: Does it really matter?

Posted by billburke on January 12, 2010

I was just reading on Adrian Coyler’s blog that Spring’s dm Server is moving to Eclipse.org.  Cutting through all the blah blah blah, this is what I came up with as the reason for this move:

“At SpringSource we know that open source development and community involvement can play a huge role in evolving simple, pragmatic solutions that enable a technology to bridge from early adopter to mainstream usage. We know because it is a path we have successfully taken many times. In creating the Virgo project at Eclipse.org, we seek to accelerate the journey of the dm Server and of enterprise OSGi along this path.”

What I extrapolate from this is that they want to accelerate adoption.  I have a simple fundamental question:

Does it really matter if you host your project at an OSS organization like Eclipse.org or Apache?

I’ve been living in the Java OSS community for about 9 years now.  IMO, based on my experiences with JBoss, the only thing that Eclipse.org or Apache really gives you is an established brand to promote your project.  I’ve always felt that a move to Apache or Eclipse, while may be beneficial in the short run with a bump in your adoption curve, in the long run it is bad for both your project and ultimately your business.  Why?  Because you lose control of both your brand and the governance of your project.  Brands cost money and time to build.  Governance introduces the inefficiencies of any bureaucracy (see my previous blogs on problems at Apache.org).  So, with both of those disadvantages, I question the advantages of moving dmServer to Eclipse.org.  JBoss has never had a problem starting a new project and building new communities on our own.  Neither has Spring for that matter.  Our brands are strong enough so that we don’t need the bump of an Apache or Eclipse to drive adoption.

The only real benefit I see to move to Eclipse or Apache is if you’re trying to build a consortium of companies that build off of a base core technology.  I really don’t see that happening with dmServer, even if that is there goal.  I know we wouldn’t use the technology.  Would Oracle?  IBM?  SpringSource is no longer the little guy.  VMWare is a serious competitor to all of us.

Standardization more important

IMO, a better route to grow adoption is standardization.  Hibernate got a huge bump in adoption by aligning itself under the JPA banner and EE 5.  We are seeing the same with Seam->CDI->Weld and Bean Validation.  Standardization drives adoption because it frees competing companies from having to depend on a competitor’s code base.  Since the APIs are public, vendors can provide their own implementations and value add on their own terms.  At the same time, standardization gives an easier entry point for vendors that want to enter into the space and gives users the peace of mind that they have less vendor lock-in.  Just because something is open source doesn’t mean that it is immune to lock-in.  The lock-in here is to the implementation.  Standardization breeds multiple implementations.

With dmServer, yeah, it is built upon the OSGi specification (and OSGi implementations), but that is just not the same.  You have to bring your innovations to a standards body to create the ecosystem.

What do you think?

So please help me optimize my personal algorithm for professional open source.  Do you think it really matter if you bring your project to an established organization if you yourself are already established?  I say no…


Posted in opensource | 14 Comments »

Speaking in DC on REST, JAX-RS, and REST-*

Posted by billburke on January 8, 2010

I’ll be speaking for NOVAJUG in WashingtonDC on Wednesday, January 20th 6:30pm-9:00pm. You can sign up for the event here.

The presentation will be about REST, JAX-RS, and REST-* specifically I will provide a short introduction to REST along with an explanation of the JAX-RS specification and how you can build RESTful web services with it. I will then get into how REST intersects with middleware services like messaging, transactions, and workflow.  Hope to see you there!

Posted in JAX-RS, REST | Leave a Comment »

Possible POE support in Resteasy

Posted by billburke on December 3, 2009

I was thinking about some POE support for Resteasy.  On the client side add a poe() set of methods on ClientRequest and a @POE annotation for the Proxy framework.  I.e.

ClienRequest request = ...;
request.body("<stuff/>", "appliation/xml");
ClientResponse response = request.poe();

@Path("/")
public interface MyService {
   @POE
   @Consumes("application/xml")
   public void poeIt(Data data);
}

The way they’d both work is a HEAD to the base URL would be sent to get the POE-Link, then a POST to the POE-Link would be done using the message body.  A Retry-like exception would be thrown if the POST fails.  For the serverside it could look something like this:

@Path("/foo/{sub}/{id}")
@POE
public void poeIt(@PathParam("sub") String subpath, @PathParam("id") @PoeGenerated int id) {...}

@PathParam combined with @PoeGenerated is an automatically uniquely generated id.  So, the user would invoke on /foo/{sub} and get back a POE link of /foo/{sub}/{id}.  i.e.

HEAD /foo/stuff

HTTP/1.1 200 OK
POE: 1
POE-Link: /foo/stuff/3333

Thoughts?

Posted in JAX-RS, REST, RESTEasy | Leave a Comment »

RESTEasy 1.2.1 Released

Posted by billburke on November 23, 2009

Minor bug fix release.  Also, had to remove one of the referenced maven repositories because it was screwing up the build.

Posted in JAX-RS, REST, RESTEasy | Leave a Comment »

“rel” name requirement overloaded

Posted by billburke on November 19, 2009

The Atom link element and the Link header name their links using the “rel” attribute.  There is a requirement in the Atom Syndication Format and Link header RFCs that states that if the relationship is not registered with IANA, that you must use a IRI instead of a simple name.  Maybe I’m misinterpreting things, but it seems that this IRI must point to an actual resource that describes the link relationship.  IMO, this will make using links awkward as REST permeates into the application development space.  Why?  Applications will define new links.  It would be rather silly for each application to register themselves at IANA for every link they define.  So, they are stuck putting in an IRI that may change over time.  Clients that consume resources will be looking for specific relationships to do their processing.  The Link header specification, I think, tries to mitigate this problem by introducing a “title” attribute.  Which, still will be weird, because clients will be looking up “rel” or “title” attributes depending on what link relationships that want to traverse.  Seems very inconsistent to me.

What I wish they had done (or would do) is define a “relref” that is an optional URL to the description of the non-standard link relationship.  That way the rel attribute remains simple and not overloaded.

If I’m misinterpreting things, apologies.  But thats what I seem to read and what I see in examples.

Posted in REST | 2 Comments »