for example, if in one of my methods we require the client to send us
a unique ID - we are relying on the client that the ID sent is really
unique - so the client should also keep track of it's requests and add
logic to it's code.
In one of the web service we have developed, the requirement was that ID was generated by the client (web service) and it is assumed to be unique for all future references. Thus, the database on this side of the web service, has that ID as a primary key, it was UNIQUE id, but it was not Auto Increment. This was never a problem. The client side CAN dictate the id if the business logic needs so. (i won't go into details of how to logically. In our case, unique-ID was pre-fixed against a code for which a client is already authenticated) I am not saying you should always ask for client to generate id - but when required this is not a showstopper.
However, we cannot rule-out the possibility that incoming requests cannot be erroneous or garbled in some cases. For that, strict type and bound checking was done (on the XML inputs) and unless everything is found perfect, no existing database records would ever get modified.
is it ok or should we try to solve ths kind of issues in a different
more transparent ways?
I didn't quite understood what other transparent ways are - but as a simple rule of thumb is, that if you can do the followig:
- define a very simple and clear flow of transactions on paper and
- define clear cut roles of each party,
- have least possible variations in contexts,
(i mean various different situations where different behavior is expected for same inputs).
- and align your database schema closely to the transaction structures,
then chances of getting in troubles reduces drastically.
Most reasons, why surprises are seen in incorrect error checking almost always draws back to ambiguity in requirements specs to be frozen.