Upon further reflection, I think we've confused two different topics.
1. We need to differentiate between "HTTP Resources" and "Jersey
Resource classes". For example, you might have a single HTTP
Resource of type "Employee" that is implemented by multiple Jersey
classes, where each Jersey class might implement a different
resource representation (Content-Type).
2. My use-case needs to resolve a URI back to a HTTP Resource. The
resource identity should be identical regardless of the headers and
filters.
This simplifies the problem quite a bit, but Jersey has no concept
of a "HTTP Resource" decoupled from the headers/filters so it's not
clear how you would implement this.
I'm going to give this some more thought. I need to figure out
whether it is reasonable for me to implement this outside of Jersey and,
if not, figure out what extra functionality I need Jersey to expose.
Thanks for helping me think this through.
Gili
On 05/11/2013 8:27 PM, cowwoc wrote:
> Brian,
>
> On 05/11/2013 7:39 PM, Van Klaveren, Brian N. wrote:
>> 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.
>
> You bring up a good point. Note that
> https://java.net/jira/browse/JERSEY-708 is related to this discussion.
>
>> 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.
>
> Now I understand why Marek was asking about filters and
> interceptors. Okay, so here is exactly what I'm looking for:
>
> URI uriFromRequestEntity = ...;
> ContainerRequest containerRequest = ...;
>
> // ResourceMatcher has an interface like the Client API
> ResourceMatcher matcher = containerRequest.getResourceMatcher();
>
> WebTarget target = matcher.target(uriFromRequestEntity);
>
> // configure target with relevant headers and fire the request
> Response response = ...;
>
> MyResource resource = response.readEntity(MyResource.class);
>
> So essentially what I need is the Client API, but instead of returning
> the response body, I need it to return the resource object. I expect
> the request to pass through all filters and interceptors just like a
> normal request would.
>
> Now that you understand what I mean, how hard do you think it would be
> to implement?
>
>> 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.
>
> I prefer baking this into the resource object because, in my
> experience, it reduces code duplication.
>
> Gili
>
>>
>> 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
>