Creazione di una semplice API RESTful

Question

Sto cercando di rendere rapidamente un'API, seguendo i principi REST, per una semplice applicazione Web che ho creato. Il primo posto in cui verrà utilizzata l'API è l'interfaccia con un'app per iPhone. L'API deve solo gestire alcune chiamate di base, ma tutte richiedono l'autenticazione, nulla è dati pubblici.

• login/autenticazione utente
• lista get di record in gruppo di utenti ancora
• lista get, solo quelli che hanno cambiato (appena aggiunto o aggiornato)
• aggiornamento di un record

Così , seguendo i principi REST, dovrei impostare lo schema uri ?:

• mysite.com/api/auth (post?)
• mysite.com/api/users (GET)
• mysite.com/api/update (post?)

e le risposte saranno in XML per cominciare, anche JSON più tardi.

1. Sul sito Web, gli utenti accedono con e-mail e password. Dovrei lasciare che ottengano un "token" nella pagina del loro profilo per passare con ogni richiesta di API? (renderebbe superflua la risorsa URI standalone/auth).

2. Best practice per strutturare la risposta xml? Sembra che con il riposo, che si dovrebbe tornare o 200 ok e l'XML o effettivi codici di stato corretto vale a dire 401 ecc

Tutti gli indicatori generali apprezzati.

Answer 1

1- per autenticazione, si potrebbe prendere in considerazione qualcosa di simile http-base o digest auth (nota - dati di base, in particolare, non è sicuro se non su HTTPS)

per il regime degli URL:

• /api/auth non è necessario se si fa uso di base o digest.
• /api/group/groupname/è probabilmente più canonico
• /api/update generalmente viene eseguito come/api/users/username (POST) con i nuovi dati aggiunti - la risorsa è l'utente - POST è il verbo
• altrimenti, in pratica la tua API sembra equilibrata, molto dipende dal fatto che i gruppi siano gerarchici e gli utenti debbano vivere in un gruppo - se così fosse, i tuoi url dovrebbero rispecchiarlo ed essere navigabili.

2 codici di stato devono riflettere lo stato - 200 per OK, 401 per accesso negato, 404 per non trovato, 500 per l'elaborazione degli errori. Generalmente si dovrebbe restituire un record XML solo se si dispone di una buona richiesta

Answer 2

Sei generalmente sulla strada giusta. Lo schema URI dovrebbe essere basato sull'idea di risorse e dovresti usare un metodo appropriato per fare il lavoro.

Quindi, recuperare per ottenere informazioni. POST (O forse PUT) per creare/cambiare risorse. CANCELLARE per bene, cancellare. E HEAD per controllare i metadati.

La struttura del tuo XML non ha molto a che fare con un'API RESTful, assumendo che non richieda la gestione dello stato. Detto questo, hai l'idea giusta. Se si tratta di una buona richiesta, restituire il codice XML desiderato (per una richiesta GET) e il codice di stato 200. Se si tratta di una richiesta errata, è anche possibile, e in alcuni casi necessario, restituire qualcosa di diverso dal solo codice di stato. Fondamentalmente, acquisire familiarità con le specifiche HTTP e seguirle il più fedelmente possibile.

Answer 3

L'autenticazione in un'API funziona sempre inviando un token di autenticazione nell'intestazione della richiesta. Ad esempio, anche quando si utilizza l'approccio di accesso separato /auth, si restituirà all'utente un token, possibilmente un cookie, che dovrà essere inviato insieme ad ogni richiesta.

HTTP fornisce già uno header dedicato per questo scopo: Authorization.
Il più fondamentale HTTP "Autorizzazione" è HTTP Basic access authentication:

Authorization : Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ== 

Digest Authentication è un altro, più sicuro, schema. Puoi utilizzare questo campo di intestazione per qualsiasi forma di autenticazione che desideri, anche per l'autenticazione personalizzata implementata.

Authorization : MyCustomAuthentication foo:bar:n293f82jn398n9r 

È possibile inviare il token di accesso sopra indicato in questo campo. Oppure è possibile utilizzare uno schema di firma delle richieste, in cui determinati campi di richiesta vengono sottoposti a hash insieme alla password dell'utente, in pratica inviando la password senza inviare la password (simile all'autenticazione del digest, ma è possibile utilizzare qualcosa di meglio di md5). Ciò cancella il passaggio di accesso separato. AWS employs this method.

Per un'API in generale, fare buon uso dello HTTP status codes per indicare cosa sta succedendo.