jsr339-experts@jax-rs-spec.java.net

[jsr339-experts] Re: Target: two new properties

From: Sergey Beryozkin <sberyozkin_at_talend.com>
Date: Wed, 7 Sep 2011 10:39:35 +0100

On 06/09/11 19:13, Marek Potociar wrote:
>
>
> On 09/06/2011 06:15 PM, Sergey Beryozkin wrote:
>> Experts,
>>
>> I'd like to propose to get two new properties added to Target[1]
>>
>> 1. baseURI (type: URI)
>>
>> Every Target points to a specific HTTP resource. However resources are often can be considered to be part of a given
>> RESTful application/service. It should be possible in most cases to report what was a base Target/URI this given Target
>> originated from.
>>
>> Rules:
>>
>> All Targets created from absolute URIs (via Client or Target.path() factory methods) must report that absolute URI as
>> the base URI.
>>
>> In all other cases it must be an original absolute URI which led to the creation of the top-level Target.
>>
>> Examples:
>>
>> Target t = client.target("http://service");
>> assertEquals("http://service", t.getBaseURI());
>>
>> assertEquals("http://service/1", t.path("http://service/1").getBaseURI());
>>
>> Target t2 = t.path("2");
>> assertEquals("http://service", t2.getBaseURI());
>
> I don't have a problem with adding base URI support for a target as such, although it would help to see at least one use
> case for the Target.getBaseUri().

Right... I think if we look at Target as something that identifies a dot
in the WEB then there's no need for introducing this and the next
proposed properties. Recall my very first attempt to merge Client &
Target - it may've been not a good idea - but it was an attempt to get
things less disjointed then they are now. Having this properties may
help rectify it.

IMHO, from a perspective of a client code attempting to consume a
RESTful service, it can be helpful to get Target carry around some
important associated metadata. No association exists between
the following two targets right now:
Target t = client.target("http://service");
Target t2 = t.path("2");

t & t2 are alien targets identifying two dots in the WEB.
Of course. we can have

Target t = client.target("http://service");
Target t2 = client.target("http://service/2");

But I think the former example gives an opportunity to have t2 be aware
of t, it seems to me a more realistic coding pattern, and thus should be
utilized for the purpose of tracking the base or rather, a specific
entry into a RESTful application.

I can think of a few few examples right now - but I think what is more
important is to agree on whether this and next props are important
Target props or not. If yes then undoubtedly they'd be used.

> Let's just wait a little and give a chance to other experts to chime in. Also, please
> open a new Jira issue to track this RFE.
>
> There's a one thing that bothers me though:
>
> Target t1 = client.target("http://service/1");
> Target t2 = client.target("http://service").path("1");
>
> assertEquals(t1.getUri(), t2.getUri()); // Targeting same resource
> assertEquals(t1.getBaseUri(), t2.getBaseUri()); // Still fails!!!
>
> In the code above, both targets point to the SAME resource. It therefore feels somewhat weird that a base URI might not
> be the same for all targets addressing the SAME resource via the SAME URI.
>

I see. One option is to recognize that t1 & t2 represent different
flows, showing that a given WEB dot can be reached in a number of ways.
But I agree it can be confusing nonetheless. Perhaps a cleaner and less
ambiguous option is to have a
baseTarget(type: Target)

property instead. Targets initialized with abs URIs will return null;
others - the original Target.

>>
>> 2. prevTarget (type: Target)
>>
>> It should be possible to start from a current Target and revert back to the original Target which initiated the chain.
>> Similarly how one can express a process "from this Target to the next Target", one should be able to express "from this
>> Target to the previous Target".
>
> There is *NO* concept of next Target in the current API. There is just a general concept of 'some other' or 'that'
> target. If anything, the proposal should talk about 'originating target'. 'Next target' as well as 'previous target' are
> IMO very confusing terms, esp. because of the potential confusion with 'Back' and 'Forward' browser actions.
>

see my reasoning above. Yes - right now all we have is disjointed
Targets. By the way, can you clarify please what you find being
confusing about Target being able to point to the root or the prev Target ?

> Also, I don't see a use case that would justify the need for every target to hold the full history of ancestors. In
> larger deployments, this is a road to nasty memory leaks, I'm afraid. Seems to me that in case of Target, tracking the
> ancestor history should be deferred to the application layer.
>
That is a reasonable concern. I'm not proposing though to have two way
links here. Hmm... If you think it's quite realistic, then well...

I'm concerned I'm seeing the immutability showing its other side
here...It allows for doing the explicit dynamic configuration of Targets
in the code - which IMHO does not belong to the application layer at all
- but presents a challenge to introducing properties
which IMHO could be explored at runtime dynamically...

> Anyway, if you still feel strongly about this proposal, please open a new Jira issue to track this RFE too.
>
Lets see if it's worth it...
Sergey

> Marek
>
>> This makes Target a more 'capable' and allows for tracing all the intermediate Targets. To some extent this can be
>> compared to UriInfo.getMatchedURIs property...
>>
>> Rules:
>>
>> All Targets created from absolute URIs must return null;
>> Those created from Target.path(relativePath); return the previous Target.
>>
>> Examples:
>>
>> Target t = client.target("http://service");
>> assertNull(t.getPrevTarget());
>>
>> Target t2 = t.path("2");
>> assertSame(t, t2.getPrevTarget());
>>
>> assertSame(t2, t2.path("3").getPrevTarget());
>>
>>
>> Comments ?
>> Sergey
>>
>> [1]
>> http://java.net/projects/jax-rs-spec/sources/git/content/src/jax-rs-api/src/main/java/javax/ws/rs/client/Target.java?rev=bdee7808db117198b8e611551a12a099bcf6b103
>>
>>
>> Cheers, Sergey


-- 
Sergey Beryozkin
http://sberyozkin.blogspot.com
Talend - http://www.talend.com