John O'Conner wrote:
> I'm having great success with GET and providing XML representations of
> my backend data. However, I haven't yet successfully POSTed any XML
> data yet.
>
> Questions:
> 1. If I have an Account class and a URL /accounts/{id} that returns an
> XML representation of an account object, shouldn't I be able to
> provide that same XML representation with a different ID and POST it
> back to /accounts to create a new account with a new id? Maybe I
> should leave off the id and let the URI processor create a new ID.
There are two general conventions for creating new resources, depending
on whether you want the client to assign the identifier or not.
* If the server assigns the identifier, do a "POST /accounts".
* If the client assigns the identifier, do a "POST /accounts/{id}".
In both cases, the server should return a 201 status on successful
creation, along with a "Location" header whose value is the absolute URL
of the newly created resource.
> Regardless, the POSTed xml should be in exactly the same format as the
> GET xml right?
>
That is certainly typical, but it is not required. It just needs to be
a representation that the client and server both understand.
> 2. What is the best practice for testing the POST feature? Do you use
> curl to send an xml representation to the uri? Something else?
>
Lots of the Jersey modules (including contribs/jersey-multipart which I
work on) have JUnit tests with what amounts to a "test server" running
on top of Grizzly. In the setup method, a new instance of the test
server is started, and in teardown it's terminated (minimize side
effects that could affect other tests). The test method itself uses
Jersey client APIs to interact with the server.
On the server side itself, I assume you already have unit tests for the
business logic that creates a new row in the database or whatever, so
the test of the web service is mostly about making sure that your
resource class is doing the right things (such as checking
authentication credentials, the right status code if a duplicate key
error occurs, and so on).
This pattern works nicely for testing JAX-RS based services, especially
if you're a TDD-head like I am :-).
> THanks,
> John
Craig