I bought your book, “Restful Java” – it is an mazing resource! Thank you!

Got a question on one of the recent readings off of burkecentral.com
I was following some ideas for RestEasy clients on http://www.javauc.com/java/1432

Where is the following 2 annotations defined? Or, is it something one need to write thier own? I searched every maven repository – could not find any jars with those interfaces

@ResponseMapping
@ExpectedCode(int)

For example, in the following:

@ResponseMapping
@ExpectedCode(200)
public interface MyResponse {

@Body public Customer getCustomer();

@LinkHeader public Link getNext();

@LinkHeader(“last”) public Link getLastCustomer();

@Header(“ETag”) public String getHash();

}

–
Have a Nice Day!

Suresh Bhaskaran
Consulting IT Specialist
Home
Work
Cell (310) 499 6211

Bill, please, don’t call jBPM “BPM”. Let’s talk about Events, Resource lifecycles, Human Tasks and Organizations not to forget Assemblies or Contracts, then we’ll talk about.

>> why are people that have been developing middleware for decades (13 years for me) embracing REST?
I have already answered that question. REST is the perfect CORBA. It is the way CORBA should have been designed. It is the ideal “distributed object” technology. This is why you have no problem “annotating” OO. This is why you like it so much. Just take CORBA one feature at a time, map it to how REST works. You’ll be stricken by the similarities.

People that have tried to develop middleware for 20-30 years should ask themselves whether it is sensitive to always reduce middleware to “plumbing” (ie boiler plate code that calls a method or procedure) or should there be a distributed programming model (in which OO does not fit of course) and where bi-directional interfaces, versioning, orchestrations and choreographies, assemblies… are key concepts. Then maybe then we will stop all these silly discussions.

So, sorry Bill, I am not sure you really understand “distributed programming models” (I won’t even talk about BPM) even though you might be a great “middleware” guy shoveling bits from A to B (B to A is a bit harder). There is value in what you are doing, but please, understand that it is only and will ever be “distributed OO”. This is what you have been doing for 15 years, and you will be doing 15 years from today. Your mind cannot shift from a monolithic programming model (a la OO) to a “distributed programming model”.

JJ-

JJ, you need to ask yourself, why are people that have been developing middleware for decades (13 years for me) embracing REST? I’ll leave it at that…

Finally, the only fantasy claims that RESTafarians need to drop IMO, is the the idea that clients actually care about self describing messages and that we don’t need middleware.

Gees, don’t you get a sense of deja vu? Don’t you get a sense that since you are always binding to the same corny OO methods the model is OO-based, regardless of which type of binding you use? It would be fun to see the same type of code sample with an action like Submit PO.

Don’t you think the problem is “distributed objects” not the bindings? Could we once and for all agree that OO does not provide a factoring of the business logic that can support information systems? Data Models, Processes, Tasks, Organizations… no to mention (forwards compatible) versioning.

Don’t you get a sense that the “client” in the JBPM example needs to know a think or two about the “links”? Where is the uniform interface? I don’t hear much about that lately. How do you version the client code when the response with the “links” changes?

How long will be have to wait until we put OO to rest and seriously consider the architecture of information systems? How will we have to wait until the RESTafarians quit their fantasy claims?

JJ-

Basically you implement ResponseHandler and implement the T handleResponse(..) method. Mostly you don’t actually need to return a wrapper object (actually, especially with post/put requests, I usually go for Boolean) but if you need one, you can return one.

So I think you need to go for a callback style solution as well. Secondly, I don’t like the abuse of exceptions for what are really not exceptional situations. Why not let the user specify a callback interface that you annotate with the expected status and corresponding types? Then throw an exception for unhandled responses (or better have a default handle method in the interface).

So you would get something like

@Path(..)
@ResponseHandler(MyHandler.class)
public void getCustomer(…)