You can do what Jakub suggested - for your API users it still looks the
same and you can minimize duplication of code by calling the JSON method
from the String one (once your String one constructs the FooBean which
it would pass as a parameter).
Martin
On 18.3.2011 20:05, NBW wrote:
> So yes, I was trying to consolidate things into one endpoint.
> Originally, I thought I could do something like this:
>
> @POST
> @Consumes({MediaType.APPLICATION_JSON, MediaType.TEXT_PLAIN})
> @Produces(MediaType.APPLICATION_JSON)
> public Response test1(@FormParam("foo") String foo, FooBean
> fooBeanJsonDO) {
> ...
> }
>
> And I had hoped that Jersey would be able to infer which method
> parameter to unmarshall into based on the Resquest type. Per request
> the client is only going to send one type of data, it can't send both
> Json AND form data in the same request for example. So based on this
> restriction I had hoped that Jersey would be able to unmarshal into
> the proper parameter, eg. use the FormParam when receiving form data
> and use the bean when receiving Json data that matched the resource
> path and HTTP method for this endpoint.
>
> Looking back, I suppose that capability might be a bit ugly though
> because then the method would have to test to see if the String was
> null and the bean wasn't and vice versa. A cleaner solution would be
> to have Jersey be able to simply unmarshall into the bean with both
> media types so then the method would simply look like this:
>
> @POST
> @Consumes({MediaType.APPLICATION_JSON, MediaType.TEXT_PLAIN})
> @Produces(MediaType.APPLICATION_JSON)
> public Response test1(FooBean fooBeanJsonDO) {
> ...
> }
>
> It sounds like from Martin's response I would need to create my own
> MessageBodyReader for this. I probably won't invest in this approach
> in the short term because of higher priorities but I think it would be
> a useful capability to see in Jersey.
>
> Thanks for all you feedback on this.
>
> -Noah
>
> On Fri, Mar 18, 2011 at 2:37 PM, Martin Matula
> <martin.matula_at_oracle.com <mailto:martin.matula_at_oracle.com>> wrote:
>
> Oh, I see what you mean. You are right.
> Martin
>
>
> On 18.3.2011 19:29, Tatu Saloranta wrote:
>
> On Fri, Mar 18, 2011 at 10:47 AM, Martin Matula
> <martin.matula_at_oracle.com <mailto:martin.matula_at_oracle.com>>
> wrote:
>
> Noah said: "I suppose I could break this into two
> resources, one consuming
> JSON and one consuming FormData but I'd rather not - seems
> like it defeats
> the purpose."
> So, I was assuming he knows about breaking it up into two
> methods and was
> wondering how to avoid it.
>
> Right right, agreed, he was trying to do it this way. I was just
> pointing out that plain text String was not meant to be bound to
> object; rather it would be (I thought) alternative
> representation. And
> then the question of how to support alternatives is an interesting
> one, given that they are structurally different (not just
> different
> formats).
> But maybe difference here is that just having 2 methods does not
> create 2 separate resources (iff paths are the same), but just 2
> physical end points.
>
> Of course it is possible to get by with just a single method,
> taking a
> String or byte[], and call binders manually based on incoming
> type.
> Just couple more lines of code.
>
> -+ Tatu +-
>
>