Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

When creating a web service API, how much should I count on the developer to act by my rules?

We are really aimed on creating an API so the developers shouldn't develop client side logic too much...

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.

is it ok or should we try to solve ths kind of issues in a different more transparent ways?

share|improve this question
2  
does the ID need to be unique at your side or at his side? If its at your side, you should include a GetUniqueId function in your API. –  Thomas Stock Nov 2 '11 at 14:46
4  
Expect them to do every conceivable thing wrong at least once. –  Jeremy Nov 2 '11 at 14:52
add comment

3 Answers

up vote 9 down vote accepted

Never trust user input, even if that user is an API consumer. Its your responsibility to maintain integrity in your data, their reponsibility to maintain theirs. If your code requires the clientID to be unique then check its unique before you save it.

Trusting user input couples your code with theirs, when they have bugs on their system they can then introduce bugs into yours.

share|improve this answer
add comment

You shouldn't assume that anyone is going to be following your rules. You should assume that there is at least one malicious user out there who is going to try to break your system. You accept an int and expect it to be positive, assume that someone is going to try to send 0 or negative values. You accept objects, so assume people will pass objects in invalid states or null values. You should program defensively - someone will try to use your API in a manner that you don't expect. If you don't have control over the code, never assume that someone else will not make a mistake (intentionally or otherwise).

You use an example of a unique ID for a client. If the client provides this information, how do you know that multiple clients won't provide the same "unique" ID, even unintentionally? If the client provides this ID, you first assume that there are no defects in the client code and every ID a particular client generates is unique and valid. You also assume that you don't have a malicious client that isn't trying to spoof unique IDs.

share|improve this answer
add comment

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 validate it,
  • 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.

Dipan.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.