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