Hi Shay,
Thanks for the interest. Just to be clear, when you talk about
extending the capability, you're having a resource with 2 methods
like:
@Consumes("application/xml")
public Response postEntity(Entity e) {
}
@Consumes("application/xml;type=collection")
public Response postEntities(EntitiesCollection e) {
}
?
On Tue, Sep 1, 2009 at 9:39 AM, Tsadok, Shay<[email protected]> wrote:
> Hi All,
>
> My name is Shay, my team & I are currently working on exposing REST API for
> an enterprise application using the Wink framework.
>
> Most of our collection resources supports POSTing of new single resource in
> xml format.
> HTTP POST Request example of single entity:
> POST /my-collection
> Content-Type: application/xml
> <Entity>
> <Data/>
> </Entity>
>
> We would like to extend this capability to support creation of multiple
> entities in a single roundtrip (i.e. POST a XML that represents a collection)
> The problem is that we want the collection resource to support both single &
> multiple XML representations for POST method (i.e. POST on my-collection can
> consume both collection and single XML schemas)
>
> The way we thought to distinct between the two representations is using a
> more specific content type header, for example:
> In that case the Content-Type is the same, and one of the way to solve the
> problem is to use content-type additional params:
> HTTP POST Request example of entities collection:
> POST /my-collection
> Content-Type: application/xml;type=collection
> <Entities>
> <Entity>
> <Data/>
> </Entity>
> <Entity>
> <Data/>
> </Entity>
> </Entities>
>
> Unfortunately Wink doesn't supports content-type params matching.
> I would like to propose a change in the matching algorithm of Wink in which
> the content-type params will be considered.
>
> Just for the record, the JSR311 doesn't define the behavior in this case, we
> believe that this enhancement doesn't contradict the specification (take a
> look at JSR311, section 3.7.2.3).
>
> Thanks in advance,
> Shay
>
>
>
--
- Bryant Luk
