On Feb 17, 2010, at 12:53 PM, Markus Karg wrote:
>
> The other part of the discussion was about generic vs. specialized clients. Jan wants to do spezialized clients, i. e. a client that know where to find such links (besides in the entity aka document itself) and possibly the role names of the links, while my idea is to have a generic client that can be scripted from outside, so the script provides the information what role's link is of next interest (like "genericClient.invoke("roleName");").
>
I'm curious how an API like that would work in practice. E.g. how would the genericClient find the URI corresponding to "roleName" ? How would the generic client determine the HTTP method to use and what media type to send in its requests (where appropriate).
I think a useful client-side framework will need to straddle the generic vs specialized divide:
- It needs to be able to be used with any link relationship and workflow
- Ideally it would support common formats out-of-the-box
- It needs to allow specialized extensions that can extract links from the appropriate point in a representation.
- It needs to allow metadata (method, media-type etc) to be provided to configure the request
Seems to me that:
Specialized Client == Generic Client + Metadata (script)
The only real difference is the shape of the APIs. I'm not sure what a specialized client API for JAX-RS would look like ?
Marc.