L'idea di RE di presentazione S tato T ransfer non riguarda l'accesso ai dati nel modo più semplice possibile.
Hai suggerito di utilizzare le richieste post per accedere a JSON, che è un modo perfettamente valido per accedere / manipolare i dati.
REST è una metodologia per l' accesso significativo ai dati. Quando vedi una richiesta in REST, dovrebbe immediatamente essere evidente cosa sta succedendo con i dati.
Per esempio:
GET: /cars/make/chevrolet
è probabile che restituirà un elenco di auto chevy. Un buon API REST potrebbe anche incorporare alcune opzioni di output simili a querystring ?output=jsono ?output=htmlche consentirebbero all'accessorio di decidere in quale formato devono essere codificate le informazioni.
Dopo un po 'di pensare a come digitazione dati ragionevolmente incorporare in un API REST, ho concluso che il modo migliore per specificare il tipo di dati in modo esplicito sarebbe tramite l'estensione del file già esistente, come .js, .json, .html, o .xml. Un'estensione di file mancante sarebbe predefinita in qualsiasi formato predefinito (come JSON); un'estensione di file non supportata potrebbe restituire un 501 Not Implementedcodice di stato .
Un altro esempio:
POST: /cars/
{ make:chevrolet, model:malibu, colors:[red, green, blue, grey] }
è probabile che creerà un nuovo malibu chevy nel db con i colori associati. Dico probabilmente perché l'API REST non ha bisogno di essere direttamente correlata alla struttura del database. È solo un'interfaccia di mascheramento in modo che i dati reali siano protetti (pensali come accessori e mutatori per una struttura di database).
Ora dobbiamo passare alla questione dell'idempotenza . Di solito REST implementa CRUD su HTTP. HTTP utilizza GET, PUT, POSTe DELETEper le richieste.
Un'implementazione molto semplicistica di REST potrebbe utilizzare la seguente mappatura CRUD:
Create -> Post
Read -> Get
Update -> Put
Delete -> Delete
C'è un problema con questa implementazione: Post è definito come un metodo non idempotente. Ciò significa che le chiamate successive dello stesso metodo Post genereranno stati server diversi . Ottieni, Put ed Elimina, sono idempotenti; il che significa che chiamandoli più volte dovrebbe risultare in un identico stato del server.
Ciò significa che una richiesta come:
Delete: /cars/oldest
potrebbe effettivamente essere implementato come:
Post: /cars/oldest?action=delete
Mentre
Delete: /cars/id/123456
risulterà nello stesso stato del server se lo chiami una volta o se lo chiami 1000 volte.
Un modo migliore di gestire la rimozione oldestdell'articolo sarebbe quello di richiedere:
Get: /cars/oldest
e utilizzare i IDdati risultanti per effettuare una deleterichiesta:
Delete: /cars/id/[oldest id]
Un problema con questo metodo sarebbe se un altro /carsarticolo fosse aggiunto tra quando è /oldeststato richiesto e quando è deletestato emesso.