Create a resource for each special case and hide the complexity in the
server side... And split the use car in several calls
Sent from my iPhone
On 20.05.2009, at 10:46, "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, i. e. 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
>
>
>
>