Craig,
I agree that starting with a sound schema is certainly the best
approach.
I choose to start from the DB, then generate everything from the
Entity up to REST web service because it looked like the fastest
approach in my context : prototyping.
But this approach is now showing some of the limits, mainly the lack
of flexibility and the time needed to understand the code generated.
For a real-life project, I will mostly adopt another approach,
probably based on a sound XML schema, as you suggested.
Thanks
Seb
---
Sébastien Stormacq
Senior Software Architect
GSS Software Practice,
Sun Microsystems Luxembourg
On 22 Jun 2009, at 21:23, Craig McClanahan wrote:
> 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
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>