Hi Bill,
>
> Sergey, client.request(link) is no different than
> client.request(uribuilder) IMO.
>
Link is Configurable and it will have more associated metadata around
URI, describing what this Link is 'about'.
> You will also want to use Link interface as it current exists, for link
> headers and the hypermedia framework.
>
> so, you could do:
>
> HttpResponse res = client.request(...).get();
>
> res = res.getLinkHeader("edit").request().post();
>
> or, with a hypermedia API like Restfulie:
>
> Customer cust = client.request(...).get();
> client.links(cust).getLink("edit").request().post();
>
That looks nice. One problem I see is that the code like this:
httpResponse.getLinkHeader("edit").request().post();
is going to lose Client's features/etc (unless response itself keeps
track of the original Client/Invocation) and IMHO original Client's
features must be in scope unless overridden.
> With your approach of Link *NOT* being a request factory, you'd have to
> interact with the Client object.
>
OK, the fluent style involving Links looks good. That said
Client.request(Link)
needs to be there IMHO.
One other problem with Link having factory methods is that it prevents
it from being passed around. We have HttpRequest and Invocation.
Invocation is invocable HttpRequest and I can see why API wants to
prevent custom filters and such from doing invocations.
Link with factory methods letting creating Invocable invocations is a
problem, same way HttpRequest with get(), etc, would be.
Thus, having
client.request(httpResponse.getLinkHeader("edit")).post();
instead of
httpResponse.getLinkHeader("edit").request().post();
does not look that bad at all IMHO, because:
- It's easier to push original Client's configuration to the Invocation
being initialized from Link.
- Passing Link around won't have unexpected sideeffects
- It's more obvious that Client is in control
IMHO, making Link a bean (possibly with few setters - I'll start another
thread to investigate if we can drop them) won't affect API negatively
Thoughts ?
Sergey
>