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(). 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.
>
> 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.
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.
Anyway, if you still feel strongly about this proposal, please open a new Jira issue to track this RFE too.
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