Paragrafo precedente: « C11.5 Ricerca nel database
Paragrafo precedente: « C11.5 Ricerca nel database
Come anticipavamo, ogni richiesta al server riceve innanzitutto un codice di esito nella forma stabilita dal protocollo HTTP: 200 in caso di successo, un codice di errore altrimenti. Ecco un esempio usando cURL:
curl -i 'https://test.mygelsia.it/API/registrazione/15159?username=luca @accomazzi.net&password=tvumdb&group=registrati'
Ottiene come header:
HTTP/1.1 200 OK
E come corpo della risposta
{"masterId":"15159","id":"15159","lastMod":"2016-11-26 11:29:31"
(eccetera)
Per un controesempio, alla richiesta di leggere l'anagrafica di un'altra persona viene opposto un rifiuto. Notate che lo id numerico qui è diverso e corrisponde a un altro utente.
curl -i 'https://test.mygelsia.it/API/registrazione/15160?username=luca @accomazzi.net&password=tvumdb&group=registrati'
Ottiene come header:
HTTP/1.1 401 Unauthorized
Nel corpo della risposta Sar-At riporta un messaggio esplicativo, pensato per aiutare lo sviluppatore durante il suo lavoro a capire i motivi del rifiuto. I messaggi di errore possono venire cambiati nel corso del tempo, a ogni successivo rilascio di Sar-At, e lo sviluppatore non deve fare affidamento su di essi. Il codice rilasciato in produzione per la soluzione clientside deve utilizzare esclusivamente gli indicatori numerici per desumere il risultato della richiesta.
Paragrafo successivo: » C11.7 Possibili codici di errore