On 09/02/2011 12:38 PM, Sergey Beryozkin wrote:
> On 02/09/11 10:41, Marek Potociar wrote:
>>
>>
>> On 09/01/2011 07:33 PM, Sergey Beryozkin wrote:
>>> On 01/09/11 15:34, Marek Potociar wrote:
>>>> Not sure I understand what is supposed to be over-engineered here. Different (sub)resources may have different
>>>> requirements. These requirements may be represented as different set of target configurations. Sometimes the different
>>>> requirements may be even at the level of a single request - e.g. you need to be authenticated to do PUT or POST, but
>>>> you
>>>> can freely invoke a safe operation, such as GET. It's common use case with many existing web pages, including java.net.
>>>
>>> I can see how the idea in general, disagree it's practical to assume the immutability of URI is needed to address
>>> "Sometimes the different requirements may be even at the level of a single request" because it's difficult to imagine a
>>> case when a *single" mutable Target URI instance is shared between multiple concurrent consumers all having diff auth
>>> requirements. Even it's feasible, it does not warrant in itself the need for the immutability given how highly
>>> 'esoteric' this case is IMHO.
>>
>> This is not about concurrency, this is about demarcating the configuration boundaries. Different URIs point to different
>> resources. Different resources may have different configuration requirements. Concurrency has nothing to do with it.
>
> I may've got it wrong, as far as the concurrency is concerned. I think though a practical code would not rely on the
> config demarcation facilitated by the Target's immutability:
>
> right, I'm here now, so lets apply this filter, now move next, hmm, may be I should apply another filter here, actually,
> what user I am, is it POST or PUT or GET ? That sounds highly unpractical to me - I'd think how to do it at the
> practical level without expecting the mainline code to *know* it all and not building this into API.
>
> May be I'm just missing the point.
I don't know how to make it more clear at the moment. I think that in the course of our discussion I did cover all the
various aspect of why Target is designed immutable wrt. URI. Configuration is one aspect of it, but you need to look at
it from the higher-level perspective taking into account all parts of the story and look beyond a simple single-request
use case.
>>
>> Additionally, current design proves practical for traversing URI hierarchies, as shown by the iteration examples earlier.
>>
> Yes I can agree - you can't use a Target to glide back and forward, be a bit more 'capable' but may be it's a bit
> hypothetical...
Not sure I understand. It was you who came with the example where you wanted to move back and forth in the resource
hierarchy. Why are you now saying it's all hypothetical?
>> Consider looking at it in the following perspective:
>>
>> 1. Target is a link to a particular resource
>> 2. The invocation above, in terms of resources captures a resource transition:
>>
>> client.target("http://bar").path(1).path(2).path(2).path(4)
>> R1 ----------> R2 ---> R3 ---> R4 ---> R5
>>
>> So, the Target.path() tells you "from here, go there", not "change this resource into that resource".
>>
> OK. This looks OK. I guess I'm saying that .path(1).path(2).path(2).path(4) does look like a classical builder chain to
> me and perhaps it might be a bit confusing...Assuming you want to keep the immutability, then may be rename path() to
> toPath() or next() or forward(), to capture "from here, go there" better.
I just used the names from UriBuilder, since JAX-RS 1.x users should be familiar with those names.
>
>> Another example to illustrate that the resources are really different is here - consider which of the following reads
>> better:
>>
>> A)
>> Target library = Client.target("http://library");
>> Target books = library.path("books");
>> Target dantesDivineComedy = books.queryParam("ISBN-13", "978-0451208637");
>>
>> B)
>> Target library = Client.target("http://library");
>> library = library.path("books");
>> library = books.queryParam("ISBN-13", "978-0451208637");
>>
>> I hope we can agree that A) makes more sense.
>>
> A) looks fine, but a bit unusual, when I type a URI in the browser, I'm still working with the same URI string, which I
> guess B) captures pretty well.
What are you trying to say? We don't work here with strings, we work with resources and their URIs. This is not a text
editor API.
> A is more naturally readable - but you can't get from the books section back to the
> library entry. Which is possible with B...
Are you really suggesting, that in the example A, after executing line 2 you cannot refer to the library, but in the
(corrected) example B you can?? Are we both still talking about Java code? :)
Marek