users@jersey.java.net

Re: [Jersey] RESTful Philosophy

From: <amsmota_at_gmail.com>
Date: Wed, 20 May 2009 12:31:42 +0000

Since your questions (this and the other 2 subsequent posts)
are "philosophic" and this list is much more about the "practical" things
of Jersey, I think you'll have much more interesting answers in the
rest-discuss list. You risk, however, to get answers that are way too
philosophical :) And I'm not by all means implying that this list doesn't
have excellent rest theorist...

http://tech.groups.yahoo.com/group/rest-discuss/




On May 20, 2009 9:46am, Markus Karg <karg_at_quipsy.de> wrote:





> Hi Everybody,





> today I have a philosophic question about how to do
> "correct" RESTful JAX-RS applications!





> The problem is:





> We have to write a client-side software which shall do a
> rather complex algorithm. All data is stored on a JAX-RS RESTful server.
> The
> algorithm is like this (the business use case is hypothetical, just to
> express
> the complexity of the problem):





> * View a subset of server-stored data, which is to be found
> using a really, really complex SQL query (like "Give me all spare parts
> but only those not being ordered in the past five years and only those
> with red
> labels").


> * Let the user type in a lot of data (like a list of physical
> modifications to be applied to the selected spare parts).


> * Create a new bunch of server-stored data (lots of rows)
> from this user data + the queried data (like work orders what to do with
> which
> part at what day on what machine etc. -- far more than a simple row but
> more a
> complete hierarchy of rows).


> * All created data must be consistent, ie create all or
> nothing.


> * Run a business validation on the created data and return a
> list of business level warnings (like "Not enough parts on stack." --
> not just a single return code but actually a list of errors)





> I have done simple "Hello World" RESTful samples
> all the time, so my problem is not the technics behind JAX-RS or JAXB. The
> problem is more: How to do "correct" RESTful design in such a complex
> case?





> My first attempts was to provide a simple service that just
> can provide a complete list of spareparts and accept a lot of PUTs for
> each
> work item to create. But the drawback is that this would involve possibly
> one
> million spare parts while only five pass the client filter, and the
> creation of
> work items is not atomic, so I have to provide some rollback facility on
> the
> client side in case of a single PUT returning an error code.





> My second attempt was to provide a highly complex service
> that returns an exact list of only the wanted spare parts, and provide
> only a
> single PUT. Both uses highly specialized XML containing the search result
> / all
> work items in one single document. The benefit is that the client code
> size and
> transmission bandwith is optimal, but the service would not be reusable
> in any
> way.





> So my question is: What is the "correct" RESTful
> design for complex things like this? First attempt? Second attempt?
> Something
> totally different?





> All comments are welcome!





> Regards


> Markus