On 02/09/11 12:18, Marek Potociar wrote:
>
>
> On 09/02/2011 12:58 PM, Sergey Beryozkin wrote:
>>>
>>>> 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");
>>>> Target library = library.path("books");
>>>> Target 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. A is more naturally readable - but you can't get from the books
>>> section back to the library entry. Which is possible with B...
>>
>> You should've named Target in B) as libraryResource :-).
>> library, books, dantesDivineComedy, are all libraryResources :-), with the latter two being library subresources...
>>
>> Not that that matters but I thought I'd add yet another comment :-)
>> Sergey
>>
>
> Actually, I cannot agree with the above. In the example, there is only one library resource, which provides access to
> the "list of books" resource and that one provides access to the particular book resource. While all three resource
> types *are related to* the root library resource, they *are not* library resources, in terms of REST. There is *only
> one* library resource.
>
> The above is not nitpicking, it's the important aspect of REST captured in the Target API.
>
Sure. Technically yes, every individual resource is a resource on its
own. However if we talk about scoping, then I think that if we have a
library service, then individual book resources, being subresources, can
be qualified as being library resources...
Sergey
> Marek