Sébastien Stormacq wrote:
> Hello Craig,
>
> Thanks for your answer
> See Inline
>
>
> On 22 Jun 2009, at 19:40, Craig McClanahan wrote:
>
>> 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.
>
> That's a good point. The generated code refers to
> "PurchaseConverter", then a <Purchase> element is certainly the right
> one.
>>
>> 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.
>
> It seems that jersey implementation is requiring URI. Not specifying
> an URI for relationship elements causes
> javax.ws.rs.WebApplicationException: java.lang.RuntimeException: No
> uri specified in a reference
>
> So, After experimenting a bit, it appears than only URI is required,
> as in this sample
>
> <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/"/>
> </purchase >
>
Ah ... I must confess that I gave up on the NB code generators for
JAX-RS resource classes, because I didn't like some of the things that
code does. But I haven't looked at this since the early 6.5 days, so
maybe things have improved.
For my own Java based REST services, I've found it the most convenient
to start from an XML schema with JAXB annotations to generate my model
classes, then hand craft the resource classes the way *I* want them to
look :-). Which mostly means they just adapt the HTTP communication
(including things like sending back 404s for "not found" use cases) and
delegate all the real work to my business logic and model classes.
There's some examples of the JAXB stuff (among other places) in the EE5
tutorial:
http://java.sun.com/javaee/5/docs/tutorial/doc/bnazf.html
Craig
> Thanks for pointing me in the right direction
>
> Seb
>
>>
>> Craig
>>
>
>
> ---
> 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
>