Creazione di un'API webservice: quanto "credito" dovrei dare al cliente / sviluppatore

Non fidarti mai dell'input dell'utente , anche se quell'utente è un utente API. È vostra responsabilità mantenere l'integrità dei vostri dati, la loro responsabilità di mantenere il loro. Se il tuo codice richiede che il clientID sia univoco, controlla il suo univoco prima di salvarlo.

Affidandoti all'input dell'utente accoppi il tuo codice con il loro, quando hanno dei bug sul loro sistema possono quindi introdurre dei bug nel tuo.

Non dovresti dare per scontato che qualcuno stia seguendo le tue regole. Dovresti dare per scontato che ci sia almeno un utente malintenzionato là fuori che tenterà di interrompere il tuo sistema. Accetti un int e aspetti che sia positivo, supponi che qualcuno proverà a inviare valori 0 o negativi. Accetti gli oggetti, quindi supponi che le persone passino oggetti in stati non validi o valori nulli. Dovresti programmare in modo difensivo - qualcuno proverà a utilizzare la tua API in un modo che non ti aspetti. Se non hai il controllo sul codice, non dare per scontato che qualcun altro non commetta un errore (intenzionalmente o in altro modo).

Usi un esempio di ID univoco per un cliente. Se il cliente fornisce queste informazioni, come fai a sapere che più client non forniranno lo stesso ID "univoco", anche involontariamente? Se il client fornisce questo ID, per prima cosa si assume che non vi siano difetti nel codice cliente e che ogni ID generato da un particolare cliente sia univoco e valido. Presumi anche che non hai un client dannoso che non sta cercando di falsificare ID univoci.

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 uno dei servizi Web che abbiamo sviluppato, il requisito era che l'ID fosse generato dal client (servizio Web) e si presume che sia univoco per tutti i riferimenti futuri. Quindi, il database su questo lato del servizio web, ha quell'ID come chiave primaria, era un ID UNICO, ma non era Incremento Automatico. Questo non è mai stato un problema. Il lato client CAN imposta l'id se la logica di business lo richiede. (Non entrerò nei dettagli di come logicamente. Nel nostro caso, l'ID univoco era prefissato contro un codice per il quale un client è già autenticato) Non sto dicendo che dovresti sempre chiedere al cliente di generare id - ma quando richiesto questo non è uno showstopper.

Tuttavia, non possiamo escludere la possibilità che le richieste in entrata non possano essere errate o confuse in alcuni casi. Per questo, è stato eseguito il tipo rigoroso e il controllo associato (sugli input XML) e, a meno che non sia stato trovato tutto perfetto, nessun record di database esistente sarebbe mai stato modificato.

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

Non ho capito bene quali altri modi trasparenti sono - ma come una semplice regola empirica è che, se riesci a fare il seguente:

• definisce un flusso di transazioni molto semplice e chiaro su carta e convalidarlo,
• definisce i ruoli ben definiti di ciascuna parte,
• ha meno varianti possibili in contesti, (Intendo diverse situazioni in cui è previsto un comportamento diverso per gli stessi input).
• e allinea strettamente lo schema del tuo database alle strutture delle transazioni,

quindi le probabilità di finire i problemi si riducono drasticamente.

La maggior parte delle ragioni, perché le sorprese sono viste nel controllo errato degli errori, rimandano quasi sempre all'ambiguità delle specifiche dei requisiti da congelare.

Dipan.