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> 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> 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> 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 @Mobclix
> >>
> >> The leading global technology provider of
> >> mobile marketing and advertising solutions
> >>
>