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>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> 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 +-
>>
>