From: Joseph Mocker <jmocker_at_velti.com>
Date: Mon, 8 Jul 2013 09:22:53 -0700

Hi Paul,

I understand what you are saying and that sounds good to me. What I fail to see is how to Jersey can this flexible. I see only a couple of options


  1. create a more generic resource method which could accept multiple representations and deal with figuring out which is being passed in each time:

@Consumes("application/json")
public Response createPerson(String representation) {
    try {
        // try to deserialize into first representation
     } catch (Exception ex) {
        // nope, that wasn't it, try to deserialize into the next representation
    }

Definitely some ugly boilerplate

  2. another option would be to create an entity that encompasses all the variations and switch depending on whether key values are defined, in your example

public class Person {
    private int heightInches;
    private int weightPounds;
    private String via;
}

This seems a little odd since "via" is transient, only used in a creation mode. I could get around this by having a special version of the Entity for creation purposes, but that seems a bit unnatural

Are there other options where Jersey may be able to assist more?

  --joe


[Velti]<http://www.velti.com> Joseph Mocker | Senior Software Architect
t +1.650.566.7033 m +1.408.676.6625
e jmocker@velti.com @Mobclix<http://twitter.com/Mobclix>
[cid:sep11117255ae]
The leading global technology provider of
mobile marketing and advertising solutions

<http://mwc.velti.com/meet-us>

On Jul 3, 2013, at 10:52 AM, Paul Moore wrote:

Joe,

I understand the thinking, but I would try to make your POST accepting resource more flexible.

It really opens up *a lot* of options if the "expected" representation can be less exact / complete. For example (slightly contrived), you don't *need* a person's height to create a person resource, although you *might* allow it, and provide it if known.

This identification of must haves vs nice-to-haves dictates how flexible your API is for (you and other) users, the tighter the API is locked down, the more difficult integration becomes.

The representation flexibility also moves you away from the need to version the API, as (old) clients can provide what they expect to be handled, without having to have all the new features.

Your POST accepting resource can look for a "via" (or whatever rel you choose) link, and switch on that basis. This is good thing :)

For what it's worth it took me a *long* time to unwire my "interfaces must be fixed" thinking, and embrace the flexibility that ReST promotes.

Paul

On 3 July 2013 17:07, Joseph Mocker <jmocker_at_velti.com<mailto:jmocker_at_velti.com>> wrote:
Hi

I had originally though about that option but the problem I see is this.

Say I have a POST method for entity creation that takes a specific representation.

I guess I would want POST to also take a representation like you suggest the problem is that, unless I am mistaken, I cannot define a second POST method to accept this alternate representation, unless the method entity parameter is simply a String and then I deal with unmarshalling the value myself.

Basically I can only register a single method for a given @Path, http method, @Consumes & @Produces regardless of the payload parameter.

--joe

On Jul 3, 2013, at 5:42 AM, "Paul Moore" <paulkmoore_at_gmail.com<mailto:paulkmoore_at_gmail.com>> wrote:

> Joseph,
>
> An alternative approach...
>
> You could send in a representation that contains (only?) a link to the
> resource that you want to use as a source.
>
> A quick review of the IANA link registry reveals nothing exact, you
> could perhaps use 'via' or 'related'. Alternatively, you could define
> an suitable extension relation (as RFC5988) e.g.
> http://relations.example.com/source (or similar).
>
> It seems to me that "copy" is *just* creation of a new resource that
> gets its data from a specified source.
>
> This pattern would also allow to copy resources from outside your domain.
>
> Best
>
> Paul
>
>
>
> On 2 Jul 2013, at 23:37, Joseph Mocker <jmocker_at_velti.com<mailto:jmocker_at_velti.com>> wrote:
>
>> Hi,
>>
>> I am looking for the rules about how Jersey selects the resource method to service a request. I know the @Path, Http Method, @Consumes and @Produces are all used to select a resource method. Are there any other attributes of the request like Headers for example, which I can use to influence the selection process?
>>
>> I am trying to define a pattern for copying or duplicating an entity, where I simply reference the original entity somehow instead of passing in the entire entity as in the normal "create" Resource. There are three ideas I've bounced around to implement this
>>
>> 1. just use a different @Consumes type, such url form encoded and define a separate Resource method to handle it
>> 2. pass in a header such as "X-Copy-Entity" and pass in different payload data representing source, and having Jersey automatically select it somehow
>> 3. define a new Http Method to designate a Copy and figure out how to get Jersey to recognize it in resource method selection
>>
>> Has anyone run up against trying to do something like this?
>>
>> Thanks…
>>
>> --joe
>>
>> Joseph Mocker | Velti | Senior Software Architect
>> t +1.650.566.7033 m
>> e jmocker_at_velti.com<mailto:jmocker_at_velti.com> @Mobclix
>>
>> The leading global technology provider of
>> mobile marketing and advertising solutions
>>