Lo scambio di dati tra più piattaforme è più che mai cruciale nell'era delle integrazioni. Considerate un negozio online senza integrazioni. Il vostro sito web dovrebbe sviluppare sistemi per gestire gli account degli utenti, le iscrizioni via e-mail, l'elaborazione dei pagamenti, le spedizioni e altre attività oltre alla gestione degli elenchi dei prodotti. Sarebbe più efficace affidare questi compiti ad altri fornitori, poiché questa non è un'opzione scalabile.
Leinterfacce di programmazione delle applicazioni, o API web, sono ciò che i programmi software utilizzano per comunicare tra loro. Le API offrono un protocollo coerente per lo scambio di dati tra due programmi. Con l'aiuto delle API web, il vostro negozio online può comunicare con il software di consegna, le applicazioni client, le applicazioni di pagamento e qualsiasi altra connessione necessaria.
Esistono vari modi per creare un'API; tuttavia, se volete aggiungere connessioni software ai vostri servizi, c'è una tecnica unica che dovreste conoscere: I servizi web API REST. In questo articolo parleremo di esempi di API REST, di cosa sono le API REST, di come funzionano le API REST, di cosa vengono utilizzate le API REST, della loro storia, dei loro elementi e di altro ancora.
Che cos'è esattamente un'API REST?
I servizi web API REST o Representational State Transfer sono la pratica più comune per collegare i componenti nei framework di microservizi, perché offrono un modo versatile e portatile di incorporare le applicazioni. REST è un design API molto diffuso che viene utilizzato per interagire con gli stakeholder interni ed esterni in modo standardizzato e prevedibile.
Gli utenti delle applicazioni web utilizzano spesso servizi web API REST per comunicare tra loro. Ad esempio, l'acquisizione e la revisione dei dettagli dell'account in un programma di social media. I browser API REST possono essere visti come la sintassi del web. I clienti online utilizzano le API Web per fornire e gestire l'accesso alle operazioni digitali, dato l'aumento dell'utilizzo del cloud.
Progettare API web che consentano ai clienti di connettersi, amministrare e interagire con i servizi web digitali in modo dinamico in un contesto disperso è una decisione sensata. Siti web come Google, eBay, Facebook, Amazon e Twitter utilizzano servizi web RESTful. Le applicazioni client possono ora utilizzare REST per accedere a questi servizi Web.
La tecnologia REST è preferita ad altre tecnologie correlate. Questo perché i servizi web REST consumano meno larghezza di banda, il che li rende ideali per un'attività online efficiente. I servizi web REST possono essere sviluppati anche con linguaggi di programmazione come JavaScript o Python.
Come funzionano le API REST?
Per sapere come funzionano le API REST, dobbiamo definire alcuni termini chiave:
Cliente
L'utente di un'API viene definito "client". Il client invia query alle API web per ottenere dati o applicare modifiche al programma. Il browser Internet è un client; comunica con varie API Web per ottenere il contenuto della pagina. Il computer riceve le informazioni richieste, che vengono poi visualizzate sul display.
I metodi HTTP più diffusi sono i seguenti:
- Utilizzare la richiesta GET per restituire i dati o le risorse richieste.
- Utilizzare la richiesta POST per creare una nuova risorsa
- Utilizzare la richiesta PUT per apportare modifiche o continuare ad aggiornare una risorsa esistente.
- Utilizzare il comando DELETE per sbarazzarsi di una risorsa.
Ad esempio, una richiesta HTTP all'API di Youtube può essere una richiesta GET per un particolare video o post o una richiesta POST per pubblicare una nuova foto. È possibile utilizzare il metodo di richiesta POST per pubblicare nuovi post. Analogamente, una piattaforma di servizi web per i clienti che si integra con un'implementazione di un assistente automatico può utilizzare l'istruzione PUT per aggiornare o eliminare un saluto personalizzato.
Richiesta Get
- È possibile memorizzare nella cache le richieste GET. La cronologia del browser include le richieste GET.
- È possibile inserire le richieste GET nei preferiti.
- Non utilizzare mai le richieste GET quando si lavora con materiale critico.
- Le richieste GET sono limitate in lunghezza.
- Solo le richieste di dati vengono effettuate tramite richieste GET.
Il metodo POST
La richiesta POST è un metodo per inviare informazioni a un server per aggiungere o aggiornare risorse. Il corpo di una richiesta HTTP contiene i dati che vengono pubblicati sul lato server:
- Le richieste del metodo POST non vengono mai inserite in una cache.
- Le richieste POST non vengono memorizzate nella cronologia del browser.
- Le richieste POST non possono essere inserite nei segnalibri.
Corpo della risposta
Il corpo della risposta è uno degli elementi importanti delle API RESTful. I dati richiesti sono inclusi nel corpo della risposta. Il corpo della risposta può includere dati relativi alle porte di uscita e alla logica di uscita.
Risorse
Qualsiasi dato che le API web possono fornire all'utente è una risorsa. Ad esempio, un individuo, una pagina, un'immagine o un commento possono essere considerati risorse nell'API di Facebook. L'identificatore di risorsa è un termine speciale dato a ciascuna risorsa.
Server Web
Il programma che accetta il corpo della richiesta del cliente utilizza un server web, che ospita le risorse richieste dal consumatore. Il server può comunicare con i clienti attraverso un'API senza offrire ai clienti l'accesso immediato alle informazioni contenute nei suoi database. Quando un utente accede ai servizi web RESTful per inviare un corpo di richiesta, il server invia al browser una rappresentazione normalizzata dello stato della risorsa.
Ciò significa che il server in qualche modo non invia l'esatta risorsa al client, ma riflette piuttosto la sua condizione, cioè la situazione della risorsa in uno specifico momento. Per favorire la comprensibilità, le risposte vengono restituite in un formato leggero.
Il formato JSON (JavaScript Object Notation) è ampiamente utilizzato in quanto è leggibile sia dalle persone che dalle macchine e contribuisce in modo eccellente a promuovere l'accessibilità del Web. JSON è utilizzato principalmente per l'invio del corpo della richiesta nelle applicazioni web e nelle applicazioni client. È una forma compatibile con una varietà di codifiche. I formati di dati API diversi da JSON comprendono XML, YAML, CSV, HTML e testo semplice. Gli utenti delle API possono scegliere qualsiasi formato di dati desiderino utilizzando tipi di media personalizzati.
Storia delle API REST
Molti programmatori hanno dovuto lavorare con SOAP prima che REST incorporasse le API. La creazione, l'utilizzo e il debug di SOAP erano compiti notoriamente difficili. Fortunatamente, REST è stato sviluppato da un team di programmatori sotto la direzione di Roy Fielding, modificando per sempre l'ambiente delle API.
Ecco una cronologia dello sviluppo delle API REST nel tempo:
Prima di REST
I programmatori scrivevano manualmente un file XML contenente una chiamata di procedura remota (RPC) all'interno del contenuto per connettere le API web utilizzando SOAP. Successivamente, i progettisti inviavano il loro pacchetto SOAP all'endpoint specificato.
Nel 2000
Un team di programmatori guidato da Roy Fielding scelse di sviluppare un framework che permettesse a qualsiasi server di comunicare con qualsiasi altro server. Egli stabilì le restrizioni per le API REST. Poiché queste linee guida sono universali, lo sviluppo di software è più semplice.
Nel 2002
eBay ha sviluppato la sua API RESTful nel 2002, aprendo il suo mercato a qualsiasi sito web che potesse trarne vantaggio. Per questo motivo, un altro titano dell'e-commerce, Amazon, si è interessato alla questione e, nel 2002, ha rilasciato la sua API RESTful.
Nel 2004-2006
I servizi web RESTful di Flickr sono stati rilasciati nel 2004, consentendo agli autori di aggiungere rapidamente fotografie ai loro siti web e ai post sui social media. Quando Twitter e Facebook hanno notato che un numero significativo di programmatori stava analizzando i siti web e creando API "Frankenstein", entrambi hanno reso pubbliche le loro API circa due anni dopo.
Nell'anno 2006-oggi
I servizi web RESTful sono ormai ampiamente accettati dai programmatori, che li utilizzano per migliorare le prestazioni delle loro applicazioni e dei loro siti. AppMaster facilita la collaborazione e semplifica la costruzione di API, consentendo di farlo più rapidamente.
A cosa servono le API REST?
Uno dei principali vantaggi dei servizi web RESTful è che offrono una grande flessibilità, consentendo di utilizzare le API RESTful in modo più efficace. Di seguito sono riportati alcuni esempi di utilizzo delle API REST.
Applicazioni basate sul cloud
Grazie alla statelessness delle sue chiamate, le API REST sono vantaggiose nelle applicazioni cloud. I moduli stateless possono essere facilmente reinstallati e crescere per soddisfare i requisiti di capacità se qualcosa va storto. Un programma software che combina componenti locali e basati su Internet è un'applicazione cloud. Questo paradigma utilizza server distanti a cui si accede tramite un browser web e servizi web in corso su Internet per eseguire le istruzioni.
L'ubicazione tradizionale degli host delle applicazioni cloud è un sistema informatico distante gestito da un operatore di rete di cloud computing di terze parti. La posta, la condivisione e l'archiviazione di documenti, l'inserimento di ordini, il controllo dell'inventario, Microsoft Word, la gestione delle relazioni con i clienti(CRM), la raccolta di informazioni, la finanza e la contabilità sono esempi di attività svolte con applicazioni basate sul cloud.
Le interfacce di programmazione delle applicazioni(API) REST possono essere utilizzate per collegare fonti esterne di informazioni e risorse di archiviazione. I programmatori possono realizzare applicazioni cloud più piccole utilizzando le API REST per trasferire i dati ad altri programmi per la gestione o l'analisi dei calcoli e restituire i risultati al programma software. Le API testate garantiscono un'uniformità attiva che può accelerare la produzione e produrre risultati concreti.
Un ottimo esempio di applicazione cloud è rappresentato da Google Docs o Office 365. Tutto ciò che serve per Google Docs o Office 365 è un computer in grado di eseguire i motori di ricerca e i servizi web di Internet. Le reti informatiche forniscono l'interfaccia utente e le operazioni, compresa l'archiviazione delle informazioni. Numerose applicazioni cloud distinte possono essere ospitate dalla vostra azienda utilizzando host di applicazioni cloud.
Servizi cloud
Poiché è necessario gestire il modo in cui viene elaborato l'URL per connettersi a una risorsa tramite un'API, le API REST sono utili anche per i servizi web cloud. L'architettura dei servizi web RESTful diventerà probabilmente uno standard in futuro grazie alle applicazioni cloud. I programmatori utilizzano i servizi web RESTful per connettersi ai servizi cloud utilizzando Internet. Lo sviluppatore crea un codice che utilizza l'API del fornitore di servizi Internet, fornisce gli input e le variabili necessarie e poi controlla la risposta per assicurarsi che l'azione funzioni come previsto.
Gli utenti finali possono accedere alle applicazioni client o ai servizi web offerti dai servizi web cloud, come l'infrastruttura di calcolo, i sistemi di archiviazione o i sistemi di tracciamento, utilizzando un servizio cloud come i servizi web RESTful. Le API delineano le capacità e le operazioni di un'applicazione e le specifiche necessarie per eseguirle. Per mantenere la privacy e la sicurezza del cliente, le API dipendono spesso dall'interoperabilità REST o dal Simple Object Access Protocol (SOAP) e da meccanismi di autorizzazione come OAuth 2.0.
Una serie di servizi web sono definiti "servizi cloud" e vengono messi a disposizione di aziende e consumatori online su richiesta. Questi servizi web sono stati creati per offrire un accesso rapido ed economico a strumenti e applicazioni senza la necessità di hardware o infrastrutture. La maggior parte del personale utilizza i servizi web cloud per qualsiasi cosa, dalla posta elettronica alla collaborazione documentale.
Uso del web
Queste API web possono essere ottenute da un progetto web dell'utente, da un'applicazione iPhone, da un dispositivo IoT o da un Windows Mobile, poiché REST non dipende dalla funzionalità lato client. È possibile creare l'architettura per la propria azienda senza essere vincolati a un framework specifico per il lato client.
Un esempio di API REST
Vediamo un esempio di API REST. Fare clic sul link sottostante per chiedere al database Open Trivia una domanda di intelligence arbitraria: Tali servizi web REST sono stati utilizzati per fornire un'API web pubblica. Il computer visualizzerà una sola domanda del quiz e le relative risposte in formato JSON.
Utilizzando un qualsiasi browser HTTP, come url, si può eseguire la seguente interrogazione e ricevere una risposta nel corpo della risposta: https://opentdb.com/api.php?amount=1&category=18
Il corpo della risposta del file XML del servizio web conterrà tutte le informazioni del dipendente.
Tutti i dialetti di programmazione e gli strumenti di sviluppo più diffusi dispongono di librerie client HTTP, come retrieve in JavaScript, Node.js e Deno e file get contents() in PHP. Una risposta JSON può essere letta e utilizzata perché è leggibile dalla macchina prima di essere visualizzata in HTML o in un altro stile.
Le API Rest e REST
Nel corso del tempo si sono sviluppati molti metodi di trasmissione dei dati. Potreste esservi imbattuti in scelte come CORBA, SOAP o XML-RPC. La maggior parte di essi ha sviluppato linee guida rigorose per i messaggi. Roy Fielding ha delineato per la prima volta REST nel 2000, che è molto più semplice degli altri.
Si tratta di una raccolta di suggerimenti e limitazioni per i servizi web REST piuttosto che di una norma. Si tratta dei seguenti vincoli architettonici:
Partizione client-server
Nell'architettura REST, i client e i server web possono comunicare solo in una direzione: il client richiede il controller di dominio e il controller o il server risponde alla richiesta. I server web non possono inviare richieste e i clienti non possono reagire; il consumatore avvia tutte le connessioni.
I servizi web REST mantengono isolati i clienti e i server, facilitando l'interazione tra loro. I computer client possono svilupparsi senza temere di avere un impatto su un altro hosting e i materiali dei server possono essere modificati senza avere un impatto inconsapevole sui clienti.
Interfaccia uniforme
Secondo questa strategia, tutte le interrogazioni e le reazioni devono attenersi a una procedura proweb standard o allo stile dei loro messaggi. Le applicazioni e i server sono sviluppati in diversi linguaggi di programmazione che non sono in grado di interagire tra loro con un mediatore. Un'interfaccia uniforme è un dialetto che qualsiasi cliente può utilizzare per interagire con qualsiasi API REST.
La traduzione delle richieste e delle reazioni tra le applicazioni con un'interazione normalizzata sarebbe solo possibile. Le differenze minime si mescolerebbero e perderebbero informazioni, e le soluzioni dovranno aggiornare le loro procedure di richiesta quando le API web modificheranno le loro. Un'interfaccia coerente elimina questa prospettiva.
ACCESSO A https://www.googleapis.com/youtube/v3/channels?part=contentDetails
Come tutte le applicazioni client REST, questa proposta include due dati. La tecnica HTTP è GET. Descrive l'azione che il client desidera eseguire sulle risorse. Un utente può eseguire quattro metodi HTTP di base:
HTTP, o Hyper-Text Transfer Protocol, è il linguaggio universale per la maggior parte delle API REST. HTTP non è stato progettato pensando a REST. Inoltre, REST ha accettato questa trasmissione di dati come criterio per le applicazioni REST-aware. Per utilizzare HTTP con le API REST, il client invia una richiesta in un formato che forse conoscete. Una richiesta di segnale video all'API di YouTube, ad esempio, ha questo aspetto:
- Utilizzare il comando GET per ottenere una risorsa.
- Utilizzare il comando POST per creare una nuova risorsa
- Usare il comando PUT per apportare modifiche o continuare ad aggiornare una risorsa esistente.
- Utilizzare la richiesta DELETE per sbarazzarsi di una risorsa.
I metodi HTTP specificano l'azione prevista per una specifica risorsa. I metodi HTTP sono noti anche come verbi HTTB.
L'URL è HTTP
L'identificatore uniforme di risorse, o URI, che identifica la risorsa desiderata è contenuto nell'URL. L'URL è anche un endpoint in questo scenario, poiché è il punto in cui l'API RESTful entra in contatto con l'utente del servizio.
Stringa di query: L'URL include una query string. La stringa di query viene utilizzata per definire i parametri, ai quali vengono assegnati dei valori.
Dopo aver ricevuto e verificato la richiesta, il server web restituisce i dati sulla risorsa desiderata. In genere, i dati vengono restituiti in una struttura nota come JSON (JavaScript Object Notation). JSON presenta tutti i componenti di una risorsa in un formato portatile che gli umani possono leggere facilmente.
Principi dell'interfaccia uniforme
L'interfaccia uniforme deve seguire i seguenti parametri:
HATEOAS: Hypermedia come motore dello stato dell'applicazione
L'ipermedia è il motore dei servizi web RESTful. Ciò indica che l'ipermedia è tutto ciò che il cliente vuole comprendere per riconoscere la risposta del fornitore.
- Al cliente deve essere fornito solo il primo URI dell'applicazione client. L'applicazione client deve guidare continuamente tutti gli altri materiali e attività utilizzando collegamenti ipertestuali.
- I servizi web RESTful non richiedono il linguaggio di interrogazione dell'input (IDL), che differisce da altre API
Un tipo di media è un nome per il formato dei dati di una rappresentazione. Il tipo di media identifica una definizione che delinea il modo in cui una rappresentazione deve essere trattata. Un'API web che utilizza REST sembra un ipertesto. Ogni elemento di dati che può essere indirizzato porta una posizione, sia direttamente (come attraverso le proprietà di collegamento e identità) sia implicitamente (ad esempio, derivata dalla struttura di descrizione del tipo di media).
Messaggi autodescrittivi
Ogni comunicazione tra il lato client e il lato server deve fornire dati sufficienti per l'esecuzione della comunicazione. Di conseguenza, la richiesta dal lato client al lato server deve specificare la risorsa a cui si sta cercando di accedere e i suoi obiettivi specifici.
Inoltre, le rappresentazioni delle risorse devono essere autodescrittive; l'utente non deve sapere se una risorsa è una persona o un'apparecchiatura. Deve invece rispondere seguendo il tipo di media collegato all'aiuto.
Pertanto, è indiscutibile che svilupperemo molti tipi di media unici, spesso un tipo di media per ogni risorsa. Ogni forma di media specifica un paradigma di produzione standard. Per esempio, l'HTML definisce il modo in cui viene mostrato l'ipertesto e come il browser gestisce ogni componente.Identificazione delle risorse
Le risorse a cui si fa riferimento nelle comunicazioni posteriori tra il cliente e il server devono essere riconoscibili attraverso le rappresentazioni. Il rispetto del sistema URI (Uniform Resource Identifier) ha permesso di ottenere questo risultato. In altre parole, la comunicazione dal server al cliente potrebbe includere una versione HTML del documento e alcune informazioni, piuttosto che il file reale dalla memoria del server.
L'utente può capire facilmente la versione HTML perché segue lo schema URI. Il cliente deve modificare le risorse fornendo al server una rappresentazione di come la risorsa dovrebbe apparire alla fine. In questo modo, l'utente può costruire, recuperare, modificare e rimuovere le risorse. Se il cliente ha l'autorizzazione necessaria per modificare i dati, il server deve soddisfare la richiesta.
Start FreeTry AppMaster no-code today!Platform can build any web, mobile or backend application 10x faster and 3x cheaper
Senza stato
Con un'API RESTful, tutte le richieste del client devono essere transitorie. Di conseguenza, ogni query e il corpo della risposta includono tutti i dati necessari per concludere il contratto, rendendo ogni connessione autonoma. Il server non tiene traccia delle richieste HTTP precedenti, ma tratta ogni richiesta effettuata dal client come una domanda completamente nuova.
Poiché il server non deve eseguire alcuna operazione supplementare per ottenere i dati storici, i trasporti stateless riducono significativamente la quantità di memoria necessaria per il server e aumentano la probabilità che la risposta sia accettabile. Ciò garantisce la scalabilità di queste interazioni: i programmatori non devono preoccuparsi di utilizzare una quantità di memoria maggiore o di sovraccaricare il server quando il loro software si espande e fa richieste HTTP.
Stratificato
Finora abbiamo definito le query delle API Web come un semplice scambio client-server, anche se questo è un po' troppo semplice. Tra queste due organizzazioni, spesso ci sono più server. Queste piattaforme, o livelli, sono presenti per gestire e disperdere il traffico, aggiungere protezione e svolgere vari altri compiti cruciali.
Secondo questo concetto, i messaggi inviati tra un utente e un server di destinazione devono essere strutturati e gestiti in modo simile, indipendentemente dai livelli che esistono in mezzo. I livelli aggiuntivi non dovrebbero avere nulla a che fare con le interazioni con i clienti. I programmatori che si attengono a questa regola possono cambiare i sistemi di server senza intaccare il processo fondamentale di richiesta-risposta.
Cache
La cache si verifica quando un cliente naviga su un sito web quando il contenuto viene salvato sul computer del cliente. Il materiale memorizzato nella cache viene caricato rapidamente dalla memoria interna anziché essere scaricato nuovamente dal server quando l'utente visita il sito in questione in un secondo momento. La maggior parte dei siti di grandi dimensioni utilizza il caching per ridurre il carico delle pagine e conservare lo spazio del server e la larghezza di banda.
Il caching dei dati viene preso in considerazione quando si sviluppano le API REST. La risposta che un server fornisce a un cliente deve indicare se e per quanto tempo la risorsa data può essere memorizzata.
Codice a richiesta
L'ultimo principio di REST non è necessario. Se richiesta, la risposta di un'API può includere codice software da utilizzare per i clienti. In questo modo, il cliente può eseguire l'applicazione o il programma del cliente nel suo backend.
Un'API è considerata RESTful se è conforme a questa serie di linee guida. Queste linee guida, tuttavia, lasciano ai programmatori molta libertà di modificare le caratteristiche della loro API RESTful. Le API REST si differenziano dal Simple Object Access Protocol, un'altra tecnica di API web molto diffusa, per la loro maggiore flessibilità (SOAP).
Consenso sugli endpoint
Prendete in considerazione questi endpoint:
- /utente/123
- /utente/id/123
- /user/123\s/user/id/123\s
- /utente/?id=123
Sono tutti metodi legittimi per il client 123 per recuperare i dati. Quando ci sono procedure più complicate, il numero di possibilità aumenta. Ad esempio, in ordine inverso, partendo dalla voce 51, si possono visualizzare 10 persone con un cognome che inizia per "A" e che lavorano per l'azienda.
Alla fine, non importa come si strutturano gli URL; conta l'uniformità in tutta l'API RESTful. Nei sistemi software di grandi dimensioni con molti programmatori, questo non può essere facile. Le modifiche alle API RESTful sono inevitabili, ma gli URL degli endpoint non devono mai essere rifiutati, perché così facendo le applicazioni che si basano su di essi smetteranno di funzionare.
Versione delle API REST
Il versionamento delle API è una pratica comune per prevenire le incompatibilità. A titolo di esempio, /2.0/user/123 sostituisce /user/123. Sia il vecchio che il nuovo endpoint possono continuare a funzionare. Di conseguenza, questo costringe a mantenere le API importanti del passato. Le versioni precedenti possono essere ritirate, ma la procedura deve essere attentamente studiata.
Autenticazione dell'API REST
Qualsiasi dispositivo può scaricare un quip senza autorizzazione utilizzando l'API di richiesta. Le API che leggono informazioni private o che consentono di modificare e rimuovere le query non supportano questa procedura. I programmi lato client all'interno dello stesso dominio dei servizi web RESTful inviano e ricevono i cookie allo stesso modo delle richieste HTTP. (Si noti che l'opzione di riavvio dei privilegi deve essere specificata nei siti precedenti per Fetch()). Una query API può essere verificata per confermare che un utente abbia effettuato l'accesso e disponga dei permessi richiesti.
Autenticazione di base HTTP: I programmi di terze parti devono utilizzare soluzioni di approvazione diverse. Alcuni metodi di autenticazione popolari sono la verifica di base per:
- HTTP. Una stringa nome utente: password codificata in base64 viene fornita nel campo della query come parte di un'intestazione di approvazione HTTP.
- Chiavi API: Fornendo una chiave API RESTful, che può avere permessi speciali o essere limitata a un singolo sito, si rende disponibile un'API ad applicazioni di terze parti. Ogni messaggio contiene la chiave nella stringa di query o nell'intestazione HTTP. (La stringa di query è un componente dell'URL).
- OAuth: prima di effettuare qualsiasi richiesta, un ID cliente ed eventualmente un segreto cliente vengono inviati a un server OAuth per ottenere una credenziale. Fino alla sua scadenza, l'identità OAuth viene trasmessa insieme a ogni richiesta API.
- Token Internet in JSON (JWT): L'intestazione della richiesta e l'intestazione della risposta trasmettono in modo sicuro le credenziali dell'utente firmate digitalmente. I JWT consentono al server di criptare i privilegi di accesso, eliminando la necessità di interrogare un database o di utilizzare un altro meccanismo di autenticazione.
Lo scenario di utilizzo influisce sulle modalità di autenticazione di un'API:
- A volte, un programma di terze parti viene gestito come qualsiasi altro client connesso con gli stessi privilegi e diritti. Ad esempio, un'API cartografica potrebbe fornire a un programma richiedente le istruzioni tra due punti. Deve verificare che il programma sia un utente legittimo, ma non deve verificare le credenziali del client.
- In altre situazioni, il programma di terze parti chiede informazioni personali a un utente specifico, come il contenuto della posta elettronica. Le API REST devono riconoscere il client e le sue autorizzazioni, ma non devono preoccuparsi del programma chiamante.
Sicurezza delle API REST
I servizi Web REST aggiungono un ulteriore modo di interagire con il software e di influenzarlo. Anche se il vostro host non è un obiettivo elevato di hacking, un utente scorretto potrebbe inviare centinaia di richieste al secondo e farlo crollare. Questo articolo non tratta della sicurezza, ma le migliori procedure standard lo prevedono:
Utilizzare HTTPS
Utilizzare un meccanismo di autenticazione forte
Si possono usare i CORS per limitare le chiamate dei clienti a particolari aree.
Fornire le funzionalità necessarie, vale a dire non
Generare scelte DELETE che non sono necessarie; verificare tutti gli URL degli endpoint e le informazioni del corpo.
Bloccare i link provenienti da settori o indirizzi IP non identificati, evitando di assoggettare i voucher API nel JavaScript lato client.
I pacchetti di dimensioni anomale vengono bloccati.
Pensate alla restrizione della velocità, in cui le richieste dallo stesso indirizzo IP o credenziale API sono limitate a N query al minuto.
Risposta con il codice di stato HTTP corretto, query di log dell'intestazione della cache e indagine non riuscita.
Richieste multiple e dati non necessari
L'implementazione di servizi web RESTful ha delle limitazioni. È possibile che una risposta contenga più informazioni di quelle richieste o che siano necessarie più richieste per ottenere tutte le informazioni. Pensate ai servizi web RESTful che consentono agli utenti di accedere alle informazioni sul creatore e sui libri; il client potrebbe:
- Chiedere le informazioni sui primi 10 libri, elencati in ordine di acquisto (prima i più venduti). La risposta include una raccolta di libri, insieme all'ID di ogni scrittore.
Per recuperare le informazioni di ogni scrittore, creare fino a 10 query /author/id.
Per ogni risposta alla query principale devono essere generate N query API, il cosiddetto "problema N+1".
Se si tratta di una situazione di uso frequente, i servizi web RESTful potrebbero essere modificati per includere tutte le informazioni sullo scrittore per ogni libro prodotto, compresi nome, sesso, nazionalità, biografia e così via. Si possono fornire anche più informazioni sui libri precedenti, anche se ciò aumenterebbe notevolmente il carico di risposta. L'API può essere modificata per rendere facoltative le informazioni sull'autore. Author details=full per evitare risposte inutilmente grandi. Il numero di opzioni che i progettisti dell'API devono supportare potrebbe essere eccessivo.
Conclusione
Ora si conoscono a fondo le API REST, il loro funzionamento, gli esempi di API REST, l'utilizzo delle API REST, i vincoli architetturali e altri argomenti trattati in questo tutorial. Per i programmatori l'apprendimento delle API può essere difficile e intimidatorio, ma la piattaforma no-code AppMaster ha creato una nuova libreria di API REST accessibile, dove è possibile approfondire la conoscenza di una serie di API REST per supportare il proprio ulteriore sviluppo professionale.
In AppMaster cerchiamo di aumentare l'accessibilità e l'usabilità delle API. Vogliamo che impariate a conoscere, sperimentare e realizzare i vantaggi dell'uso di software API nella vostra carriera e vita personale. Per aiutarvi a progettare più velocemente API web migliori, AppMaster migliora la collaborazione e automatizza ogni fase del ciclo di vita delle API. Continuate a creare, progredire e ampliare la vostra conoscenza delle API REST.
