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