Un servizio web che utilizza JSON su POST può essere classificato come RESTful?

Esistono due definizioni di REST:

1. Trasferimento dello stato di rappresentanza ("REST") come principio per la progettazione del servizio (non necessariamente servizio web! ), che suggerisce un'interfaccia client-server uniforme in cui il server non memorizza il contesto del client, ad es "il cliente ha visitato questa pagina per ultimo". Come principio generale, i servizi RESTful richiedono una risorsa specifica, ad es. un articolo, o un oggetto "ordine" - così come un'azione da eseguire su quella risorsa - "get", "tag", "paint yellow", o qualunque cosa sia necessaria, purché la stessa azione per tipi diversi di risorse ottiene lo stesso nome Fintanto che segui questi principi, il tuo servizio web può essere RESTful anche se non usa HTTP. Non vedo la risorsa specifica richiesta nel tuo protocollo , ma poi di nuovo, potrebbe essere definita dall'URL . EDIT: poiché non stai specificando la risorsa indipendentemente dall'azione, il servizio non è RESTful da questa definizione.

2. REST come formato di richiesta specifico che utilizza HTTP come protocollo portante e tipi di richieste HTTP come GET, POST o DELETE per specificare il tipo di azione da eseguire. Il tuo servizio ovviamente non è RESTful da questa definizione.

La descrizione più generale del protocollo potrebbe essere un servizio per chiamate di procedure remote (RPC) su JSON, ma che non è JSON-RPC.

Per essere chiari, non c'è nulla di sbagliato nel non essere RESTful o essere RESTful. Qualunque sia la soluzione per le tue esigenze.

REST non ha assolutamente nulla a che fare con l'utilizzo dei metodi HTTP standard. È un concetto di design che potrebbe applicarsi anche a qualsiasi protocollo di rete. Ciò che definisce REST è l'insieme di operazioni che limitano solo il recupero dello stato e l'impostazione di nuovi stati, la creazione e la cancellazione sono casi particolari di cui. L'oggetto viene creato impostando lo stato dell'oggetto con ID non ancora utilizzato (che deve quindi essere generato dal client o preparato da una query separata), eliminandolo impostando lo stato dell'oggetto su vuoto. La proprietà importante è che tutte le operazioni sono idempotenti, cioè farle due volte di fila equivale esattamente a farle una sola volta.

La domanda stessa non fornisce quindi informazioni sufficienti per decidere se il servizio è REST o meno. Ma il commento alla risposta di ciao cita i metodi "COPY" e "MOVE" e questi non si adattano a REST (l'unico modo per copiare in resto è quello di ottenere lo stato e caricarlo su una nuova risorsa e l'unico modo per spostarsi è copia e poi cancella l'originale). Ciò non significa che sia sbagliato. Nessuno ha detto che il REST è appropriato per tutte le situazioni.

Il problema è che stai creando un'altra interfaccia. Questo è piuttosto simile a RPC.

Non sto dicendo che RPC è sbagliato. RPC sembra essere più facile da comprendere per i programmatori in modo naturale. Puoi probabilmente fare tutto ciò che puoi fare in REST in RPC, ma devi abituarti a pensare in termini di spostamento delle risorse piuttosto che come funzioni di chiamata.

Con un'API RESTful, se voglio cancellare un record, invio una richiesta DELETE a / thing / 3 e viene cancellata. Se voglio prenderlo, uso un GET. È uno standard su cui non devo pensare o cercare.

Una cosa carina di REST è che puoi semplicemente utilizzare il browser per guardare l'API e ottenere alcuni dati per vedere come sono. Non puoi con il tuo.

Con il tuo, devo sapere cosa mettere nel parametro action . Forse inserisco la parola DELETE, ma devo cercare di farlo.

Con REST, so che un 404 significa che il record non esiste. Con il tuo, devo guardare il parametro di successo e quindi cercare qualche codice di errore.

Perché creare ancora un'altra interfaccia quando ne esiste già una?