Infrastruttura coerente
L'API REST è coerente e leggibile dall'uomo. È auto-documentante.
GET wp-json/wp/v2/postsè abbastanza chiaro cosa fa. Sono GETalcuni post.
Hai uno spazio dei nomi:, wpuna versione: v2e una raccolta di oggettiposts
Riesci a indovinare cosa: GET wp-json/wp/v2/posts/5fa? Che ne dici di: GET wp-json/wp/v2/posts/5/comments
Che ne dici di:GET wp-json/shop/v2/orders/345/lines/11/price
Uno sviluppatore può facilmente indovinarlo guardando questo, otterrà il prezzo della linea 11in ordine 345anche senza leggere la documentazione. Lo sviluppatore può anche facilmente dire che proviene dal shopplugin in quanto è spaziato dai nomi.
Che ne dici di che ne POST /wp-json/v2/posts title=New Blog Post
pensiPUT /wp-json/v2/posts title=New Title
Anche questo è abbastanza chiaro. Crea un nuovo post. A proposito, restituisce l'ID del nuovo post. Non si tratta di AJAX o dell'API REST. AJAX è semplicemente una tecnologia che accede all'API REST. Considerando che, in precedenza, si dovrà venire con un po 'di nomi di funzione Ajax astratti come:
get_price_for_lineitem( $order, $line ). Restituirà solo un numero o un oggetto JSON? Non sono sicuro, dov'è la documentazione. Oh ... era la chiamata Ajax get_order_line_priceo get_lineitem_price.
Lo sviluppatore non deve prendere queste decisioni, perché l' wp-jsonAPI esistente fornisce un buon modello di base da seguire quando si creano i propri endpoint. Certo, un plug-in o uno sviluppatore API possono infrangere queste regole, ma in generale è più facile seguire uno standard che è già stato impostato e la maggior parte degli sviluppatori preferirebbe piuttosto seguire uno schema già impostato (vedere come sono pervasivi i modelli jQuery ora).
ASTRAZIONE senza distrazione
Mi interessa come POST /wp-json/mysite/v1/widgets title=Foobarfunziona? No. Voglio solo crearne uno nuovo Widgete voglio l'ID in cambio. Voglio farlo da un modulo sul mio front-end senza aggiornare la pagina. Se faccio una richiesta a un URL, non mi interessa se si tratta di PHP, C #, ASP.NET o qualsiasi altra tecnologia. Voglio solo creare un nuovo widget.
L'API REST disaccoppia il backend dalla parte anteriore. Tecnicamente, se la tua API è abbastanza buona, puoi cambiare l'intero stack di back-end. Finché hai mantenuto la stessa struttura dell'API REST, tutto ciò che dipendeva dall'API non sarebbe interessato.
Se l'API REST è abbastanza semplice e coerente, usando un nome come Widgetsuna raccolta di oggetti e un nome / identificatore come Widget/2per indicare una singola entità, è davvero semplice scrivere quell'API in una tecnologia molto diversa in quanto è un impianto idraulico di database più o meno di base codice.
Utilizza verbi di richiesta HTTP standard.
Le API REST sfruttano il nucleo di come funziona il web e i VERB (leggi: azione) che usi per mappare le funzioni CRUD dei dati standard.
CREATE : POST
READ : GET
UPDATE : PUT/PATCH
DELETE : DELETE
Esistono più verbi HTTP, ma questi sono i concetti di base. Ogni singola richiesta su Internet utilizza questi verbi. Un'API REST si trova proprio sopra il modello su cui il web è costruito su richiesta. Non c'è bisogno di alcun livello di comunicazione o modello di astrazione nel mezzo. È solo una richiesta http standard a un URL e restituisce una risposta. Non puoi essere molto più semplice di così.
In sostanza, rende uno sviluppatore più consapevole di come funziona realmente il web e quando ti avvicini alla comprensione di come funzionano i protocolli sottostanti, finisci per creare un prodotto migliore più efficiente.