Well, that was definitely a new thing to learn,
that is why you could obviously see why I typed
target.accept(...)
What was the rationale behind making it immutable ?
Cheers, Sergey
On 01/09/11 12:55, Marek Potociar wrote:
>
>
> On 09/01/2011 01:06 PM, Sergey Beryozkin wrote:
>> On 01/09/11 11:31, Marek Potociar wrote:
>>> int[] bookIndexesToRetrieve = ...;
>>> Target booksResource = client.target("http://books/");e
>>> for (int bookIndex : bookIndexesToRetrieve) {
>>> books.add(booksResource.path(String.valueOf(bookIndex)).request("text/plain").get(Book.class));
>>> }
>>
>> Won't the above result in "http://books/1/2/3/4" say after 4 iterations ? I'm presuming that target.path() is
>> accumulative, that is calling target.path("1") is equivalent to target.path("1").path("1").path("1").path("1") ?
>
> No, Target is *NOT* mutable (unlike Invocation.Builder or HttpRequest). IOW:
>
> Target t1 = client.target("http://books");
> Target t2 = t1.path("1");
> t1 != t2; // !!!
>
>>
>>>
>>> Or alternatively via path templates:
>>>
>>> int[] bookIndexesToRetrieve = ...;
>>> Target bookResource = client.target("http://books/{id}");
>>> List<Book> books = new ArrayList(bookIndexesToRetrieve.length);
>>> for (int bookIndex : bookIndexesToRetrieve) {
>>> books.add(bookResource.pathParam("id", String.valueOf(bookIndex)).request("text/plain").get(Book.class));
>>> }
>>>
>>
>> I guess this should work...q
>>
>>> I don't see the need for back() here.
>>>
>> This time I was more after seeing if a transition from Target to Request can be problematic or not. It would probably
>> help in the 1st example (assuming I'm correct about path() being accumulative unless a template var is used)
>
> Again, Target is not mutable. Not even in case of template paths. Each Target method is supposed to return an instance
> that may be usable independently.
>
>>
>> Repeating the same request("text/plain") is not a big deal, the flow would see more duplications in case of repetitive
>> posts, not a big deal I guess too - just not optimal.
>>
>> We have to repeat request(...) because of course we can't set path() once we moved to this next request stage.
>>
>> I think I'd prefer seeing
>>
>> Target booksResource = client.target("http://books/{id}");
>> for (int bookIndex : bookIndexesToRetrieve) {
>> books.add(bookResource.pathParam("id", String.valueOf(bookIndex)).accept("text/plain").get(Book.class));
>> }
>>
>> which could be optimized further to:
>>
>> Target booksResource = client.target("http://books/").accept("text/plain");
>> for (int bookIndex : bookIndexesToRetrieve) {
>> books.add(bookResource.pathParam("id", String.valueOf(bookIndex)).get(Book.class));
>> }
>
> Now you just stopped producing a well-formed HTTP GET request as it does not have an Accept header. I don't think we
> want to encourage that.
>
>>
>> This is why I liked a nearly perfect revision involving Target.prepare.
>> Just curious, would Entity thing work in that revision ?
>
> Yes. But the problem with well-formed HTTP GETs would be there too.
>
>>
>> Also I start thinking about the current Target to Invocation to get/etc support being not a complete API per se but a
>> customized API covering basic GET/POST cases. As soon as we want to set even a basic custom header then we are forced to
>> move into that unfriendly Invocation/HttpRequest world with method("GET").invoke(), etc.
>
> If you checked the examples or at least looked at the Invocation.Builder API, you would notice the
> Invocation.Builder.header(...) method.
>
>>
>> But I promise, I will check the examples next :-)
>
> Yes, you most certainly should do it. I am ready to clarify any questions around the API or examples, but I prefer
> experts do some self-study first.
>
>>>>
>>>> 2. Similarly to one, but using a query param.
>>>
>>> Very similar code to the above:
>>>
>>> int[] bookIndexesToRetrieve = ...;
>>> Target booksResource = client.target("http://books");
>>> List<Book> books = new ArrayList(bookIndexesToRetrieve.length);
>>> for (int bookIndex : bookIndexesToRetrieve) {
>>> books.add(booksResource.queryParam("id", String.valueOf(bookIndex)).request("text/plain").get(Book.class));
>>> }
>>>
>>> Again, no need for back().
>>>
>> Yes, back() would be non-appropriate here. queryParam, is it accumulative or not ? How do we express "?id=1&id=2" ?
>
> All Target URI-related methods work the same way as their's counterparts in UriBuilder. The only difference is that the
> returned Target instance is not the same (different URI, different Target instance).
>
> HTH,
> Marek
>
>>
>>>>
>>>> I think the fluent API should be flexible enough to accommodate for repetitive invocations against the same targetURI
>>>> without forcing a user to retype things which are shared across requests, ex, an accept type, base URI, Content-type.
>>>
>>> It is - via path templates or via query params.
>>>
>>>>
>>>> Can you give me a favor and actually type some code showing how say 1 can be done, please don't hesitate to use BFS or
>>>> DFS techniques
>>>
>>> I didn't have to use DFS or BFS for such simple case. Give me a more complex problem! :)
>>>
>> Sounds good :-)
>> Sergey
>>
>>> Marek
>>
>>
--
Sergey Beryozkin
http://sberyozkin.blogspot.com
Talend - http://www.talend.com