Hi Gili ,
I think Marek can comment, but part of the problem with re-exposing the API, after examining the dispatching source code myself, I think partially has to do the fact that it’s hard to do with the HTTP methods, filters and interceptors, headers, etc... The resource could easily depend on the Accept header or HTTP method, in which case, it’s not straightforward to tell which resource should be returned just from the URI.
At the end of the day, in order to do this reliably, you kind of need a method that accepts a HttpServletRequest with URI and headers (and not just a URI) in order to properly determine which resource to map to, when you probably could have just submitted the request, and got the response and been done with it. Or, you return a collection of all resources that might match a URI and a method.
On the json:
I can’t honestly say what the best solution for you is, because it’s hard to know without looking at your code, and maybe I am just misinterpreting the question, but I don’t think that relying on java object discovery at runtime is the best way, or even a particularly good way to go about getting relevant information.
It seems like you should be using an ORM/DAO or something which should be available to the /calls resource to discover the id instead.
Brian
On Nov 5, 2013, at 2:54 PM, cowwoc <cowwoc_at_bbs.darktech.org> wrote:
> Hi Brian,
>
> I don't like the idea of the server making requests back to itself,
> but I'd be willing to do this if it actually worked.
>
> The main problem I have with your approach is that you're exposing
> implementation details to the end-user. My understanding of HATEOAS is
> that responses should return links to other resources as opposed to
> clients piecing together URIs using implementation-details like database
> id numbers. As such:
>
> GET /users/31
> {
> “id”: 12345,
> }
>
> seems like a big no no. Internally, Jersey knows how to navigate
> from a URI to a resource class. It did this in 1.0 and does it under the
> hood in 2.0. We just need to re-expose this API.
>
> Gili
>
> On 05/11/2013 5:37 PM, Van Klaveren, Brian N. wrote:
>> Hi Gili,
>>
>> I’m a little confused still on exactly what you are trying to do, so excuse me if this question seems off base, but I can suggest that it might be worthwhile to just use (or create) this functionality in your actual REST api defined by the resource you are attempting to find.
>>
>> You may receive a small performance hit from serialization/deserialization of the response, by doing this since you aren’t making a direct API call, but there’s technical reasons why this may also be a good idea, such as database connection pooling/application mobility/backwards compatibility, etc…
>>
>> i.e. use HttpURLConnection, Apache’s HttpClient, etc… get your json back, etc…
>>
>> 1. Server receives POST
>> 2. Server makes the following requests (back to itself, to another server, etc...):
>>
>> GET /users/31
>> {
>> “id”: 12345,
>> }
>>
>> GET /users/31
>> {
>> “id”: 67890,
>> }
>>
>> 3. Server parses json requests, server updates the call/participants/call participants table.
>>
>> Optionally, defer to the users resource to update with the new calls:
>> PUT /users/31?newcall=31298
>> PUT /users/32?newcall=31298
>>
>>
>> Brian
>>
>>
>>
>> On Nov 5, 2013, at 1:54 PM, cowwoc <cowwoc_at_bbs.darktech.org> wrote:
>>
>>> Hi Marek,
>>>
>>> Here is a simple example:
>>>
>>> POST /calls/31298
>>> {
>>> "from": "/calls/3124532/participants/31",
>>> "to": "/calls/3124532/participants/32"
>>> }
>>>
>>> This creates a connection between participants 31 and 32. How is
>>> the server supposed to honor this request? In Jersey 1.0 I would resolve
>>> each URI back to a resource. Each resource contains the following methods:
>>>
>>> long getId();
>>> URI getUri();
>>>
>>> So, once I've got the resource, I invoke getId() to get the
>>> database identifier and create the connection. When someone invokes GET
>>> /connections/321213 I convert the database id to a resource and from
>>> there invoke getUri(). I take the resulting URI and add it to the
>>> response body.
>>>
>>> What am I supposed to do in Jersey 2.0?
>>>
>>> Thanks,
>>> Gili
>>>
>>> On 05/11/2013 3:55 PM, Marek Potociar wrote:
>>>> Hi Gili,
>>>>
>>>> This is not supported in Jersey 2 at the moment. When considering the old ResourceContext API we could not agree how useful the feature as well as how to address the processing of the new JAX-RS filters and entity interceptors in that method.
>>>>
>>>> What is the use case where you would need the method? What behavior do you expect from (pre-matching and post-matching) filters and interceptors in that use case?
>>>> Answering these questions will help us in our considerations whether we should re-introduce the old API somehow or come up with a better concept.
>>>>
>>>> Thanks,
>>>> Marek
>>>>
>>>> On 25 Oct 2013, at 18:56, cowwoc <cowwoc_at_bbs.darktech.org> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> I posted this question at http://stackoverflow.com/q/17284419/14731. What replaces ResourceContext.matchResource(URI)? How do we go from a URI back to a resource class?
>>>>>
>>>>> Thanks,
>>>>> Gili
>