Come funzionano le API Web? [chiuso]

Ho sentito parlare di molte API Web come quella di Facebook, Twitter, ecc., Che aiuta i terzi ad accedere ai dati e a manipolarli. Vorrei sapere come funziona un'API Web. Quali sono le basi di un'API Web?

Se voglio creare un'API per il mio sito, in modo che le persone possano accedervi o aggiornarlo, con cosa dovrò iniziare?

Nella sua forma più semplice, crei un insieme di richieste GET / POST che chiunque può chiamare e pubblicare le informazioni su URL, parametri ed effetti. OTTIENI richieste per attività di sola lettura e richieste POST per qualsiasi cosa cambierà i dati sul server.

Aggiungi un sistema di autenticazione se necessario e disponi di una semplice API Web.

Un Web API è solo un interfaccia per consentire l'accesso al sistema (ad esempio sito) tramite normali metodi di richiesta HTTP . I dati stessi sono generalmente racchiusi in un formato standard (come JSON o XML ) per facilitarne la gestione.

Ecco un'API Web di esempio per "TextWise"

Attualmente sto sviluppando un'API per la piattaforma di virtualizzazione della mia azienda. Puoi affrontarli in diversi modi, ma il mio preferito (e il percorso più veloce per far funzionare qualcosa che le persone possono capire) è usare semplici richieste HTTP GET e restituire una risposta JSON.

Il mio URL è simile al seguente:

domain.com/method/call/subcall?key=key&data=something

Quindi scompongo le variabili HTTP GET e faccio ciò che il chiamante vuole fare con esse. Uno dei motivi principali per cui mi sono iscritto come utente beta allo sviluppo dell'API di Stack Exchange è stato il fatto che sapevo che sarebbe stata un'esperienza di apprendimento eccezionale, e in effetti lo è stata .

Di solito, restituisco due array codificati JSON, uno dei quali result, in sostanza, dice semplicemente se la chiamata ha avuto esito positivo e in caso contrario fornisce un codice di errore / stringa di errore. L'altro è di solito appena chiamato data, e il suo contenuto è descritto nella documentazione di quella particolare chiamata. Inoltre, le API basate su GET sono molto più facili da testare ed eseguire il debug.

Esistono molti altri formati, come SOAP / XMLRPC, trovo che scegliere JSON mi dia incredibile semplicità e libertà di scelta.

Ad esempio, se devo inviare molti campi e non voglio occuparmi di tonnellate di variabili GET, posso semplicemente farlo (esempio in PHP)

$to_send = base64_encode(json_encode($some_array));

Questo è facilmente decodificabile dall'altra parte, dandomi dozzine di variabili con cui lavorare, pur accettando solo 2 - 3 variabili GET tramite l'API.

Cerco solo di mantenere i miei metodi e le mie chiamate brevi e concisi e di progettarli in modo tale che ogni chiamata restituisca una risposta uniforme "funzionata o non riuscita", seguita dai dati richiesti.

Questa è in realtà una domanda molto ampia. Nel senso più elementare, un'API Web funziona quando un client (come un browser Web) invia una richiesta HTTP di qualche tipo a un server Web. Il server esamina quella richiesta per capire cosa desidera l'utente, quindi restituisce i dati in un formato (come una pagina) che il client esamina per ottenere ciò che desidera. Queste sono solo le uniche cose che le API Web hanno in comune; Mi rendo conto che questo non risponde davvero alla tua domanda, ma volevo dare una ragione per cui la domanda è così ampia.

Esistono molti modi in cui un client può formattare la sua richiesta o che un server può formattare la sua risposta, e quindi, affinché uno di essi abbia un senso, il client e il server devono concordare alcune regole di base. In generale, al giorno d'oggi ci sono due stili molto generali che vengono utilizzati per questo genere di cose.

Chiamata di procedura remota (RPC)

In un'API in stile RPC, di solito c'è solo un URL per l'intera API. Lo chiami POSTANDO un documento di qualche tipo che contiene informazioni su ciò che vuoi fare e il server restituisce il documento che ha ciò che desideri. In termini generali di calcolo, il documento di richiesta in genere ha un nome di funzione e alcuni argomenti.

Alcuni standard per questo stile di API includono XML-RPC e SOAP. Questi standard tentano di creare un formato che può essere utilizzato per descrivere le chiamate di funzione che stai effettuando o anche per descrivere l'intera API.

Trasferimento di stato rappresentativo (REST)

In un'API in stile REST, non hai così tanto un URL per l'API come spazio dei nomi : un server o una cartella all'interno di un server, in cui risiedono molti oggetti diversi e ogni URL all'interno di questo spazio dei nomi diventa parte dell'API. Invece di dire il server che si desidera utilizzare l'API, l'URL indica al server ciò che si desidera utilizzare l'API su . Quindi usi il metodo HTTP, e possibilmente il corpo della richiesta, per spiegare cosa vuoi fare a quell'oggetto: GET (recupera qualcosa che è già lì), POST (crea qualcosa di nuovo), PUT (sostituisci qualcosa che è già lì), o ELIMINA (sbarazzarsi di qualcosa che è già lì). Ci sono alcuni altri verbi che puoi usare, ma quelli sono di gran lunga i più comuni.

Finora non ho menzionato i formati standard per REST. In teoria, potresti usare praticamente qualsiasi formato. HTTP prevede già di dire cosa vuoi fare e a cosa vuoi farlo, quindi il formato del corpo della richiesta potrebbe essere praticamente qualsiasi cosa: una rappresentazione dell'oggetto che vuoi creare o sostituire. Ma in pratica, gli autori di REST tendono comunque ad accordarsi su un formato, perché sarebbe difficile dare un senso a ogni formato possibile.