Hi guys,
- You can finalize the DSL building on the post method, as Bill
suggested, which will create a long list of post/get/... variations,
but it helps not to create an invalid invocation chain.
- About instantiating, any factory pattern?
RestClient.create()?
- If you dont want to force vendors to implement new methods, nowadays
in interfaces you can add new methods and set up the default
implementation.
- The usual DSL pattern that I see for clients involve a body() or
entity() method. I am not sure, but doesn't it allow the creation of
invalid invocations?
client.body().get()?
To avoid that, I am doing (another) variation of post:
result = RestClient.create().at(uri).post(body);
result = RestClient.create().at(uri).get();
Another variation that I have implemented is this way:
result = RestClient.create().at(uri).with(body()).post(); // compiles
result = RestClient.create().at(uri).with(body()).get(); // will not compile
So anything can be extended without breaking the API interface. Let's
say that next year we want to add cache support without breaking the
interface:
result = RestClient.create().at(uri).with(cache().config()).get();
Or first config then use multiple times:
client = RestClient.create().with(cache().config());
result = client.at(uri).get();
Is it interesting to share the source code or try to apply any of
those changes to your proposal?
Regards
Guilherme Silveira
Caelum | Ensino e Inovação
http://www.caelum.com.br/
On Mon, May 23, 2011 at 9:17 AM, Bill Burke <bburke_at_redhat.com> wrote:
>
>
> 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
>