Sébastien Stormacq wrote:
> Dear All,
>
> I am looking for some help to find the exact XML / JSON document to
> post to a resource.
>
> - I have a DB with a 1 - N relationship, such as "PURCHASE" and "CARD"
> (one purchase is made using a credit card)
> - All DB IDs (primary keys) are auto generated
> - I generated the corresponding Entity Beans
> - I generated the corresponding REST resources
>
> When testing the REST service,
>
> - GET operation on PURCHASE is OK : I receive XML such as
>
> <?xml version="1.0" encoding="UTF-8"?>
> <purchases uri="http://localhost:8080/iFidelity/resources/purchases/">
> < purchase
> uri="http://localhost:8080/iFidelity/resources/purchases/3/">
> <amount>30.000</amount>
> <buyDate>2009-06-05</buyDate>
> <cardId
> uri="http://localhost:8080/iFidelity/resources/purchases/3/cardId/"/>
> <id>3</id>
> </purchase>
> ...
> </purchases >
>
>
> - Question is : what is the correct format for POST statement,
> creating a new PURCHASE while referring to an existing CARD ?
> I tried several documents similar to
>
> <?xml version="1.0" encoding="UTF-8"?>
> < purchases
> uri="http://localhost:8080/iFidelity/resources/purchases/">
> <purchase
> uri="http://localhost:8080/iFidelity/resources/purchases">
> <amount>30.000</amount>
> <buyDate>2009-06-05</buyDate>
> <cardId
> uri="http://localhost:8080/iFidelity/resources/cards/3/">3</cardId>
> </purchase>
> </purchases>
>
> But they were all rejected with various exceptions ...
>
> Could someone point me to the right syntax to POST to resources with a
> 1-N relationship ?
The right answer depends on what kind of object your resource method
takes for its entity argument. For example, I'm going to assume you're
leveraging JAXB and have created Purchases, Purchase, and Card classes
that correspond to <purchases>, <purchase>, and <card> elements in a
schema. Then, if you defined a method like this:
@POST
@Consumes("application/xml") // Or whatever media type your client
is sending
public Response createPurchase(Purchase purchase) { ... }
Then a <purchase> element would be the right answer.
As a side issue, it seems sort of redundant for a purchase to have to
know both the URI and the primary key of a card. I'd experiment with
just using a <card> element with a URI attribute in the purchase
representation.
Craig
>
> Thanks
>
> Seb
> ---
> Sébastien Stormacq
> Senior Software Architect
> GSS Software Practice,
> Sun Microsystems Luxembourg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>