Diversi sviluppi, tra cui il cloud computing e l'architettura basata sui microservizi, sono stati resi possibili dalle APIRESTful. Esse hanno reso semplice la comunicazione e l'elaborazione online. Pertanto, ogni sviluppatore deve capire cos'è REST, come funziona, i suoi vantaggi e come creare servizi sicuri per stare al passo con i tempi. Poiché può aiutare a creare soluzioni scalabili, semplici da mantenere e che consentono ai loro prodotti di raggiungere l'intero globo grazie alla potenza di Internet, molte aziende preferiscono gli sviluppatori che conoscono REST.
Come prepararsi alle domande di colloquio relative alle API RESTful?
Le domande più frequenti che riguardano i servizi web RESTful durante i colloqui sulle API REST e le richieste di informazioni sulla libreria JAX-RS e sui servizi web RESTful costruiti con il framework Spring MVC sono riportate nella sezione seguente. Prima di sostenere o programmare un colloquio, è fondamentale prepararsi a tutte le domande del colloquio REST API.
Che cos'è REST?
REST, che descrive il Representational State Transfer, è responsabile dello sviluppo di applicazioni per siti web basate sul protocollo HTTP. REST specifica diverse regole che l'utilità del sito web deve rispettare per crederci. I suggerimenti assicurano metodi HTTP standardizzati tra il server e l'utente per la trasmissione virtuale delle informazioni.
Che cos'è un'API REST?
L'API REST rende sicuro lo scambio di informazioni online tra due sistemi informatici. Per completare una serie di attività, la maggior parte delle applicazioni aziendali scambia dati con altri programmi interni ed esterni. Ad esempio, quando il sistema contabile interno condivide le informazioni sui dipendenti con il sistema bancario esterno per generare le buste paga. È possibile farlo con API REST, poiché queste informazioni sono personali e gli standard software API REST sono sicuri, efficienti e affidabili.
L'API RESTful è nota come API che è collegata a REST in qualche modo. Tutti i dati sono considerati risorse in REST API e sono determinati da una precisa unità standard costante chiamata (URI). L'API di Twitter crea un tweet come risorsa a cui l'utente può accedere e recuperare. Utilizzando l'API di Twitter, gli utenti possono pubblicare facilmente i tweet.
Quali sono i principi di REST?
Client-server consente una sequenza di risposte che vengono utilizzate per trasmettere tra il consumatore e il server. Entrambi possono inviare e accettare risposte l'uno dall'altro. Questa chiara visione del metodo client-server consentirà a entrambe le forze di operare senza essere assistite l'una dall'altra.
Sistema a strati
Tra il client e il server API, i server sono stratificati. Questi diversi server svolgono diversi compiti, come il rilevamento dello spam e il miglioramento delle prestazioni. I messaggi inviati tra il client e il server API (Application Programming Interface) non sono influenzati dall'aggiunta o dalla rimozione di livelli, perché REST (representational state) utilizza un'architettura modulare.
Interfaccia uniforme
Il client e il server devono sempre utilizzare lo stesso protocollo per tutte le comunicazioni. Questo protocollo è HTTP REST. Poiché ogni applicazione utilizza lo stesso linguaggio per richiedere e fornire dati, un'interfaccia uniforme facilita le integrazioni.
Senza stato
Nella comunicazione stateless, il server non tiene traccia delle risposte già inviate. Ogni risposta possiede l'input completo necessario per concludere la transazione. Questo migliora l'interpretazione, riducendo il carico del server e l'utilizzo della memoria. Inoltre, elimina la possibilità che una richiesta fallisca a causa di informazioni incomplete.
Cache
I client possono memorizzare nella cache qualsiasi risorsa per aumentare le prestazioni, utilizzando le risposte dei server che indicano se una risorsa è memorizzabile nella cache o meno. REST contiene anche la seguente condizione opzionale.
Codice su richiesta
La risposta di un'API può contenere codice eseguibile che gli utenti possono eseguire. In questo modo, l'applicazione client può eseguire il codice sul proprio back-end.
Qual è la differenza tra AJAX e REST?
La differenza tra AJAX e REST è la seguente:
| AJAX | REST |
| Gli oggetti XMLHttpRequest sono utilizzati in Ajax per inviare richieste al server. Tuttavia, il codice JavaScript fornisce le risposte per modificare dinamicamente la pagina corrente. | L'utilizzo delle risorse è importante per la struttura dell'URI e il modello di richiesta/risposta. utilizzato da REST. |
| Ajax è un gruppo di tecnologie che consente l'aggiornamento dinamico dell'interfaccia utente senza che la pagina venga ricaricata. | Gli utenti possono richiedere dati o informazioni ai server utilizzando lo stile di architettura software REST. |
| Ajax elimina la comunicazione asincrona tra il server e l'utente. | REST richiede una comunicazione tra il server e l'utente. |
Come funziona l'architettura a microservizi?
Un metodo architettonico per lo sviluppo di applicazioni cloud è chiamato microservizi. Ogni applicazione è composta da una serie di servizi, ognuno dei quali viene eseguito in un processo separato e interagisce con gli altri tramite API. Un metodo di creazione delle applicazioni noto come "architettura a microservizi" è diventato nel tempo una best practice. I componenti dell'architettura a microservizi si basano sulle esigenze dell'azienda.
- I clienti
Le richieste vengono inviate da numerosi utenti che utilizzano vari dispositivi.
- Fornitori di identità
Verificano l'identità degli utenti o dei clienti e forniscono token di sicurezza.
- Gateway API
Le richieste dei clienti vengono gestite tramite il gateway API.
- Contenuto statico
Tutto il materiale del sistema è contenuto in contenuti statici.
- Gestione
Determina i guasti e bilancia i servizi tra i nodi.
- Scoperta del servizio
Strumento per determinare il percorso di comunicazione tra i microservizi.
- Rete di distribuzione dei contenuti
Una rete distribuita di server proxy e centri dati associati.
- Servizio remoto
Le informazioni memorizzate su una rete di dispositivi IT possono essere consultate a distanza con l'aiuto di un servizio remoto.
Quali sono i metodi HTTP supportati da REST?
I metodi HTTP supportati da REST sono:
- GET - il metodo più utilizzato nei siti web e nelle API, GET riceve le risorse da uno specifico server di dati.
- POST - attraverso il metodo POST, i dati vengono inviati al server API per aggiornare la risorsa. Quando il server riceve i dati, li memorizza nel corpo della richiesta HTTP.
- PUT - invia i dati all'API per creare e aggiornare le risorse.
- DELETE - come suggerisce il nome, questo metodo è utilizzato per eliminare le risorse in URL specifici.
- OPZIONI - dettaglia le tecniche supportate.
HEAD - vengono restituiti i metadati sull'URL della richiesta. Esaminiamo la situazione dal punto di vista di un singolo record. Supponiamo che ci sia un record per un lavoratore con il numero di dipendente 1. Le seguenti attività indicherebbero ciascuna qualcosa di diverso.
POST - poiché stiamo recuperando informazioni per il dipendente 1, che è già stato creato, questo non è applicabile.
GET - si utilizzerebbe per recuperare le informazioni del dipendente tramite l'API web RESTful e il numero del dipendente sarebbe 1.
PUT - utilizzando l'API web RESTful, PUT verrebbe utilizzato per aggiornare le informazioni del dipendente in modo che riflettano il dipendente n. 1.
DELETE - questa funzione viene utilizzata per rimuovere le informazioni del dipendente con il numero di dipendente 1.
Qual è la differenza tra PUT e POST?
La differenza tra PUT e POST è la seguente:
- PUT - identifica in modo preciso e particolare un file o una risorsa in un URI (uniform resource identifier) fornito. PUT modifica un file esistente se esiste in quell'URI (uniform resource identifier). PUT forma un file se ne esiste già uno. Inoltre, PUT è idempotente, il che significa che non ha alcun impatto sui file, anche se viene utilizzato con una certa frequenza.
- POST - invia i dati a un URI (uniform resource identifier) distinto e si aspetta che il file di risorse lì presente gestisca la richiesta. In questo momento, il server del sito web può decidere cosa fare con i dati nel contesto del file selezionato. Inoltre, la strategia POST non è idempotente, il che significa che se viene utilizzata più di una volta, riprenderà a generare nuovi file.
Qual è la differenza tra SOA monolitica e architettura a microservizi?
Le applicazionimonolitiche hanno un tasso di sviluppo molto lento e sono costituite da unità interconnesse e indivisibili. Servizi più piccoli e minimamente connessi costituiscono la SOA, che ha anch'essa uno sviluppo limitato.
Imicroservizi sono servizi autonomi incredibilmente piccoli e liberamente collegati, con un rapido ciclo di sviluppo iterativo.
Che cos'è l'URI?
Un identificatore uniforme di risorse viene definito URI. Un URI in REST è una stringa che designa una risorsa del server web. Ogni risorsa ha un URI distinto che, se usato in una richiesta HTTP, consente ai client di indirizzarla e di eseguire azioni su di essa. L'indirizzamento è il processo di indirizzare il traffico verso una risorsa utilizzando il suo URI.
Il formato dell'URI è:
<protocollo>://<nome del servizio>/<tipo di risorsa>/<ID della risorsa>.
Esistono due tipi di URI
1. URL - le informazioni sul reperimento di una risorsa dalla sua posizione sono disponibili nell'Uniform Resource Locator.
Gli URL contengono informazioni sul nome host della rete (sampleServer.com) e sul percorso del contenuto (/samplePage.html) e iniziano con un protocollo (ad esempio FTP, HTTP, ecc.). Può anche contenere criteri di ricerca.
2. URN - Utilizzando un nome distintivo e duraturo, un nome di risorsa uniforme identifica la risorsa.
La posizione della risorsa su Internet non è necessariamente specificata dall'URN. Gli URN servono come modello per altri parser per l'identificazione delle risorse.
Ogni volta che un URN identifica un documento, può essere rapidamente convertito in un URL utilizzando un "resolver", in modo da poterlo scaricare.
Quali sono le caratteristiche dei servizi web RESTful?
Queste caratteristiche sono presenti in ogni servizio web RESTful:
- Il modello di comunicazione client-server è alla base del servizio.
- Il servizio utilizza il protocollo HTTP per recuperare dati/risorse, eseguire query e svolgere altre attività.
- La "messaggistica" è il metodo utilizzato per comunicare tra il client e il server.
- Il servizio può accedere alle risorse utilizzando gli URI.
- Aderisce all'idea di statelessness, in cui la richiesta e la risposta del client non dipendono da altri, e quindi offre la certezza assoluta di ottenere i dati necessari.
- Per ridurre le chiamate al server per lo stesso tipo di richieste ripetitive, questi servizi utilizzano anche l'idea del caching.
- Questi servizi possono anche implementare il modello architettonico REST utilizzando servizi SOAP.
Cosa sono i codici di stato HTTP?
I codici standard utilizzati nello stato HTTP corrispondono agli stati di completamento delle attività del server. Ad esempio, lo stato HTTP 404 indica che il server non dispone della risorsa richiesta.
Vediamo i codici di stato HTTP e capiamone il significato:
- 200 - OK, il successo è evidente.
- 201 - quando una richiesta POST o PUT crea con successo una risorsa, il codice di risposta è 201 - CREATED. Utilizzando l'intestazione location, si restituisce l'URL della risorsa appena generata.
- 304 - nel caso di richieste GET condizionate, viene utilizzato il codice di stato 304 NOT MODIFIED per risparmiare la larghezza di banda della rete. I corpi delle risposte devono essere nulli. Date, luoghi e altre informazioni devono essere contenute nelle intestazioni.
- 400 - BAD REQUEST indica che è stato fornito un input non valido, ad esempio dati mancanti o un errore di validazione.
- 401 - FORBIDDEN indica che l'utente non ha accesso al metodo utilizzato, ad esempio l'eliminazione dell'accesso senza diritti di amministratore.
- 404 - ERRORE indica che il metodo richiesto non può essere trovato.
- 409 - CONFLITTI L'esecuzione del metodo indica un problema di conflitto, come l'inserimento di voci duplicate.
- 500 - Il codice INTERNAL SERVER ERROR indica che il server ha lanciato un'eccezione durante l'esecuzione del metodo.
Può dirmi quali sono gli svantaggi dei servizi web RESTful?
Gli svantaggi dei servizi web RESTful sono:
- Le sessioni nei servizi web RESTful non possono essere mantenute, poiché l'assistente si attiene al concetto di statelessness.
- Le restrizioni di sicurezza e protezione non sono essenziali per REST. Alcuni protocolli vengono utilizzati per salvaguardare la sicurezza. Ciò fornirà un avviso che potrà essere utilizzato per determinare quali standard di protezione e sicurezza scegliere, ad esempio le autenticazioni SSL/TLS.
Differenziare tra SOAP e REST?
La differenza tra SOAP e REST è la seguente:
| SOAP | REST |
| Per implementare i servizi web si utilizza un protocollo chiamato SOAP. | REST è un modello di progettazione architettonica per sviluppare servizi Web. |
| Le linee guida fornite da SOAP devono essere rigorosamente rispettate. | REST delinea dei criteri che, tuttavia, non devono essere rispettati completamente. |
| Poiché il client e il server SOAP sono più strettamente correlati, è paragonabile ai programmi desktop con contratti rigorosi a questo riguardo | Il client REST è più adattabile di un browser ed è indipendente dal design del server, purché rispetti gli standard di comunicazione necessari. |
| SOAP supporta solo il trasferimento XML tra il client e il server | REST fornisce più tipi di dati, tra cui XML, JSON, MIME, testo, ecc. |
| Le letture SOAP non possono essere memorizzate nella cache | Le query di lettura REST possono essere memorizzate nella cache |
| Le interfacce di servizio sono utilizzate da SOAP per esporre la logica delle risorse. | La logica delle risorse è esposta da REST tramite URI |
| SOAP è più lento | REST è più veloce |
| Essendo un protocollo, SOAP stabilisce i propri protocolli di sicurezza. | REST adotta solo precauzioni di sicurezza basate sul protocollo di implementazione. |
| Sebbene SOAP non sia scelto di frequente, viene utilizzato quando sono richiesti il trasporto di dati statici e una maggiore affidabilità. | Al giorno d'oggi, REST è spesso preferito dagli sviluppatori perché offre maggiore scalabilità e manutenibilità. |
Quali sono i componenti principali della risposta HTTP?
La risposta HTTP ha quattro componenti principali, che sono i seguenti:
- Codice di stato della risposta - visualizza il codice di stato del server in risposta alla richiesta di risorse. Esempio: Un errore sul lato client è rappresentato da 400, mentre una risposta corretta è rappresentata da 200.
- Versione HTTP - la versione del protocollo HTTP è indicata dalla versione HTTP.
- Intestazione della risposta - i metadati del messaggio di risposta sono contenuti in questa sezione. I dati possono essere utilizzati per fornire elementi come la lunghezza del contenuto, il tipo, la data di risposta, il tipo di server, ecc.
- Corpo della risposta - la risorsa o il messaggio effettivamente restituito dal server è contenuto nel corpo della risposta.
Quali sono le differenze tra WebSocket e REST?
Di seguito sono riportate alcune differenze tra WebSocket e REST:
REST si basa su operazioni CRUD, mentre WebSocket è un protocollo di basso livello basato sui concetti di socket e porta, che sono il meccanismo di trasporto fondamentale.
Mentre le applicazioni RESTful devono progettare le loro operazioni basandosi su verbi e HTTP, WebSocket richiede l'uso di informazioni sull'indirizzo IP e sulla porta, che sono dettagli di livello inferiore per qualsiasi applicazione. WebSocket è un protocollo stateful, mentre REST è costruito su un protocollo stateless, il che significa che né il client né il server devono essere a conoscenza l'uno dell'altro.
A differenza di REST, basato su HTTP, che può scalare orizzontalmente, le connessioni WebSocket possono scalare verticalmente su un singolo server. La comunicazione basata su REST è relativamente più costosa, mentre quella basata su WebSocket è meno costosa.
Possiamo implementare la sicurezza del livello di trasporto (TLS) in REST?
Sì, è possibile! La comunicazione client-server in REST è crittografata tramite TLS, che fornisce anche all'utente la possibilità di accertare il server. Poiché sostituisce il Secure Socket Layer (SSL), è una forma di comunicazione sicura tra utente e server. Poiché HTTPS funziona bene con Secure Socket Layer (SSL) e Transport Layer Security (TLS), è utile per creare servizi web RESTful. A questo proposito, è importante notare che REST è legato al protocollo che utilizza. Pertanto, le protezioni di sicurezza si basano sul protocollo REST.
Qual è la dimensione massima del payload che può essere inviato con i metodi POST?
L'entità del carico utile che può essere trasmesso con il metodo post è teoricamente illimitata. Tuttavia, è importante ricordare che i payload più grandi consumano più larghezza di banda e richiedono più tempo per essere elaborati, incidendo sulla reattività del server.
Elenco delle annotazioni chiave presenti nell'API JAX-RS
- Path - indica il percorso relativo dell'URI (Uniform Resource Identifier) della risorsa REST.
- GET - questo designatore per il metodo di richiesta corrisponde a HTTP GET. Gestiscono le query GET.
- POST - questo designatore per il metodo di richiesta corrisponde a HTTP POST. Gestiscono le richieste POST.
- PUT - questo designatore per il metodo di richiesta corrisponde alle richieste HTTP PUT. Si occupano delle richieste PUT.
- DELETE - è definito come il designatore del metodo di richiesta utilizzato per le richieste HTTP DELETE. Gestiscono le richieste DELETE.
- HEAD - questo designatore per il metodo di richiesta corrisponde alle richieste HTTP HEAD. Gestiscono le richieste HEAD.
- PathParam - gli sviluppatori possono usare questo parametro di percorso dell'Uniform Resource Identifier (URI) per estrarre i parametri dagli URI per le classi/metodi di risorse.
- QueryParam - le classi/metodi di risorse possono usare le query estratte dall'Identificatore uniforme di risorse (URI) dallo sviluppatore usando questo parametro di query dell'Identificatore uniforme di risorse (URI).
- Produce - qui vengono specificate le presentazioni di risorse MIME che vengono create e inviate all'utente come risposta.
- Consuma: specifica le presentazioni di risorse MIME che il server accetterà o utilizzerà quando le riceverà dall'utente.
Definire RestTemplate in Spring
La classe principale per l'accesso degli utenti ai servizi RESTful si chiama RestTemplate. Utilizzando le restrizioni REST, viene effettuata la comunicazione con il server. È paragonabile a diverse sezioni di template offerte da Spring, come JdbcTemplate e HibernateTemplate. RestTemplate dà ai metodi la possibilità di comunicare utilizzando il modello URI (Uniform Resource Identifier), i parametri del percorso URI (Uniform Resource Identifier), i tipi di richiesta/risposta, gli oggetti di richiesta, ecc. Fornisce dettagli di implementazione di alto livello per i metodi HTTP come GET, POST, PUT, ecc.
Questa sezione di Spring 4.3 offre annotazioni spesso utilizzate come @GetMapping, PutMapping, @PostMapping, ecc. Prima di ciò, Spring offre l'interpretazione @RequestMapping per specificare i metodi utilizzati.
A cosa serve @RequestMapping?
- Le richieste vengono mappate a particolari metodi di gestione utilizzando l'annotazione.
- Dispatcher Servlet gestisce tutte le rotte delle applicazioni web in entrata in Spring. Utilizzando i gestori di richieste, decide quale controllore tra tutti è destinato a gestire la richiesta quando la riceve. Tutte le classi con l'annotazione @Controller vengono analizzate dal Servlet Dispatcher.
Le annotazioni @RequestMapping, definite all'interno dei metodi e delle classi del controllore, sono essenziali per il processo di instradamento delle richieste.
Elencare gli strumenti o le API per sviluppare o testare API web
Con l'aiuto di vari strumenti come Postman, Swagger, ecc. si possono testare i servizi web RESTful. Postman ha molte caratteristiche, tra cui la possibilità di inviare richieste agli endpoint, visualizzare le risposte che possono essere convertite in JSON o XML e analizzare i parametri delle richieste, come le intestazioni e i parametri delle query, nonché le intestazioni delle risposte. Come Postman, Swagger offre una serie di funzionalità e la possibilità di documentare gli endpoint. Possiamo anche testare le prestazioni e il carico delle API utilizzando strumenti come Jmeter.
Che cos'è la cache?
Quando una risposta del server viene messa in cache, viene salvata in modo da poterne utilizzare una copia fresca ogni volta che è necessario, invece di dover generare nuovamente la stessa risposta. Questa tecnica non solo alleggerisce il carico del server, ma ne migliora anche le prestazioni e la scalabilità. La risposta può essere messa in cache solo dal client e solo per un breve periodo.
Di seguito sono riportate le intestazioni delle risorse e una descrizione concisa, in modo che la procedura di caching possa identificarle:
- Data e ora di creazione della risorsa
- Data e ora dell'aggiornamento della risorsa, che di solito conserva le informazioni più recenti.
- Intestazione per il controllo della cache
- Data e ora in cui la risorsa in cache smetterà di funzionare
- L'età che stabilisce il punto di partenza per quando la risorsa è stata recuperata.
Quali sono le migliori risorse per imparare le API REST?
Ci sono molte risorse disponibili per imparare le API REST per lo sviluppo di siti web e applicazioni mobili. Le 5 migliori sono elencate di seguito:
Servizi Web RESTful
Per iniziare lo sviluppo di un'applicazione con il consumo di API, questa guida intitolata RESTful Web Services di Leonard Richardson sarà una grande risorsa a questo proposito. Soprattutto se siete principianti e volete capire le basi dei servizi web REST (Representational State Transfer). La risorsa rivela come funziona il Trasferimento di Stato Rappresentazionale (REST) e molti altri servizi essenziali legati al web con esempi. Non si basa su alcun linguaggio di programmazione, quindi la comprensione delle API RESTful non sarà vincolata ad alcun linguaggio di programmazione.
Esercitazione sulle API REST
REST API Tutorial è un'ottima risorsa online per imparare il Representational State Transfer (REST) se non si è amanti dei libri o della lettura. Questa risorsa vi aiuterà a imparare REST dall'inizio alla fine, coprendo tutti gli aspetti fondamentali. Questo tutorial inizia con l'introduzione del Representational State Transfer (REST), poi seguirà il percorso di esempi riguardanti le strategie e le conoscenze relative all'HTTP e così via.
Manuale di progettazione delle API REST
Anche questo è un ottimo libro di risorse per la guida al Representational State Transfer (REST), in quanto l'autore del libro Mark Masse trasmette le sue esperienze e le strategie che ha adottato e che gli sono state utili per la costruzione di applicazioni utilizzando API REST. In questa risorsa, ha discusso le pratiche per la creazione degli URI dell'applicazione, gli approcci per la trasmissione dei metadati tramite le intestazioni HTTP e quali tipi di supporti possono essere utilizzati. Inoltre, ha spiegato come coinvolgere l'innovazione nella progettazione dei metodi di invio e dei codici di stato delle risposte HTTP.
Newsletter settimanale degli sviluppatori di API
Esiste una fantastica risorsa chiamata API developer weekly newsletter; si tratta di una risorsa aggiornata per l'apprendimento delle API RESTful, in quanto è altamente concentrata sulla tecnica, la struttura, l'espansione e l'architettura delle API per le applicazioni basate sul web e le applicazioni mobili. La newsletter è pensata appositamente per sviluppatori, project manager e architetti.
REST assicurato
Si tratta di un fortunato strumento di test REST open-source per chi ha esperienza con un linguaggio di programmazione chiamato Java. Questa risorsa facilita la procedura di test e validazione dei processi API RESTful. REST-Assured elimina anche la necessità di creare codice boilerplate per testare reazioni complesse e aiuta la sintassi BDD.
In breve
Per concludere, l'articolo di cui sopra condivide le domande dei colloqui sulle API REST. Copre tutte le domande dei colloqui sulle API REST per coloro che stanno per candidarsi o si sono candidati per lavori simili che richiedono la conoscenza delle API REST. Queste sono le domande più comuni che un intervistatore può porre durante il colloquio di lavoro. Inoltre, consultate le risorse citate prima di sostenere un colloquio finale.
Inoltre, se volete creare un'applicazione per un sito web o un'applicazione mobile, AppMaster può essere la vostra scelta definitiva. Si tratta di una piattaforma no-code che vi permetterà di costruire tutti i tipi di applicazioni con semplici metodi drag-and-drop e non richiede alcuna esperienza o conoscenza di codifica precedente. Date un'occhiata alle offerte di oggi.
