On 5/23/11 6:00 AM, Marek Potociar wrote:
> Hi Bill,
>
> I think this is very similar to the changes I have currently in my local sandbox that I have made based on the EG
> feedback so far.
>
> There are few differences:
>
> - I like the way you simplified the WebResource API and gave it more constrained purpose
>
> - your proposal is full of interfaces. I like it for it's cleanness, esp. while still without javadoc :-), but do we
> really want to stick to these interfaces forever without the ability to add any new methods?
>
Eh, I'd only write Javadoc if the proposal was gonna be taken seriously.
I don't understand your point of not being able to add methods though.
Why couldn't you with an interface?
> - I don't see how you plan to instantiate the Client
>
I couldn't decide whether it should be RuntimeDelegate or a
ClientRuntimeDelegate. The latter of which we might want to have so
that we could separate client and server runtimes.
> - the need for the extra .execute() and .resolve() method is something I find redundant
>
It was either those, or an explosion of put, post, get methods that
returned a ClientResponse or a entity body type. I don't mind either way.
> - your request builder pattern can lead to "illegal" states which I find really unacceptable. The final API simply
> cannot let me write this code:
>
> ClientRequest request = client.request("http://localhost:9095/customers/{id}");
> ClientResponse response = request.pathParam("id", 123).execute(); // which HTTP method was executed?
>
> The above code is IMO the tax for the reduced number of classes in the proposal. Also the fluent builder API suffers
> greatly. In the days of IDE being the prevalent coding tool, I want the API provide the best code completion possible
> and I want to let user to write the fluent code that will *not* allow for this:
>
> ClientRequest request = client.request("http://localhost:9095/customers/{id}");
> ClientResponse response = request.get().pathParam("id", 123).put().accept("text/plain").post().execute();
>
> Anyway, seems to me that we are on the same page in the most important aspects of the API. Let me finish my changes so
> that I can push the latest version to the public repo.
>
TBH, I don't see your point at all. You'd have the same issues with a
tradional Builder pattern. Maybe some code on a better way would make
it clearer for me?
> Can I take your samples code and rewrite it to fit my version to have a better way to compare and pick the best of the
> two worlds?
>
Sure! I just want to get the best API possible and I'm not known for
always having the cleanest API.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com