Sommario[Nascondere][Spettacolo]
- 1. Cosa intendi per REST?
- 2. Cosa intendi per API REST?
- 3. Che cos'è esattamente l'URI?
- 4. Quali sono le caratteristiche dei servizi Web RESTful?
- 5. Quali sono i principi guida di REST?
- 6. Menziona i metodi HTTP supportati da REST.
- 7. Descrivere le restrizioni poste da un'interfaccia coerente.
- 8. Che cos'è esattamente una risorsa REST?
- 9. Cosa significa per te JAX-RS?
- 10. Cosa distingue AJAX e REST l'uno dall'altro?
- 11. Puoi elencare alcuni inconvenienti dei servizi Web RESTful?
- 12. Cosa distingue le tecniche PUT e POST l'una dall'altra?
- 13. Come si testano i servizi Web RESTful?
- 14. Descrivi un'API REST nel mondo reale.
- 15. Come funziona l'architettura di microservizi?
- 16. Che cos'è esattamente la memorizzazione nella cache?
- 17. Descrivi il carico utile.
- 18. Differenziare SOAP vs REST?
- 19. È possibile utilizzare il protocollo di sicurezza del livello di trasporto (TLS) con REST?
- 20. Metodi idempotenti: cosa sono? Come si applica al mondo dei servizi web RESTful?
- 21. Qual è la funzionalità dell'autenticazione di base HTTP?
- 22. Pensi che GraphQL sia la scelta migliore per creare un'architettura di microservizi?
- 23. Quali sono le principali distinzioni tra i metodi HTTP sicuri e idempotenti?
- 24. Cosa implica l'API JAX-RS per le classi di risorse radice RESTful?
- 25. Che cos'è esattamente Postman e perché viene utilizzato?
- 26. Come vengono mantenute sicure le API REST?
- Conclusione
L'evoluzione di REST ha reso le API incredibilmente accessibili, rivelandone al contempo tutta la forza e il potenziale. Le API REST sono facili da creare e memorizzare nella cache grazie alla loro architettura orientata alle risorse.
Inoltre, nel tempo, le API RESTful sono state i precursori di altri sviluppi significativi come il cloud computing e la progettazione basata su microservizi.
Pertanto, non dovrebbe sorprendere che gli sviluppatori di API REST siano oggi richiesti, dato il modo in cui forniscono alle aziende che utilizzano servizi RESTful un vantaggio competitivo. Le API REST sono una tendenza di design popolare.
Molte aziende IT richiedono la conoscenza dell'API REST gli sviluppatori di software e chiedi informazioni in interviste tecniche.
Ecco alcune delle domande più tipiche per i colloqui dell'API REST che ti aiuteranno a essere pronto per i colloqui in varie aziende se desideri lavorare nel campo dello sviluppo dell'API REST.
1. Cosa intendi per REST?
REST è un paradigma architetturale per la progettazione di applicazioni web basate sull'Hypertext Transfer Protocol (HTTP).
REST definisce determinati standard che i servizi Web devono soddisfare per essere considerati RESTful. Questi suggerimenti garantiscono che le richieste e le risorse vengano trasmesse in modo rapido ed efficace tra client e server utilizzando protocolli HTTP standardizzati.
2. Cosa intendi per API REST?
Un collegamento software-software noto come interfaccia di programmazione dell'applicazione consente la comunicazione e la condivisione dei dati tra programmi altrimenti indipendenti. Ad esempio, un sito Web di notizie potrebbe utilizzare l'API di Twitter per scoprire automaticamente i tweet pertinenti e integrarli nelle notizie.
Un'API che aderisce ai principi REST è nota come API REST, a volte nota come API RESTful. In un'API REST, ogni dato viene gestito come una risorsa e gli viene assegnata un'identità di risorsa (URI) standard distinta.
Ad esempio, l'API di Twitter rende ogni tweet una risorsa recuperabile disponibile per i clienti. L'API di Twitter può essere utilizzata dagli utenti per pubblicare tweet ed eseguire altre attività del sito Web.
3. Che cos'è esattamente l'URI?
A rete di computer è possibile fare riferimento a una risorsa utilizzando un URI o un identificatore di risorsa uniforme. Serve come mezzo per separare una risorsa da un'altra. Le fonti potrebbero essere o meno online.
Grazie alla loro struttura standard, gli URI semplificano la connessione anche a vari tipi di risorse. La posizione o il nome della risorsa è incluso negli URI insieme a una stringa di caratteri.
L'URI è costituito da un percorso, uno schema, una query e altri elementi ma non include il protocollo.
Utilizzando un protocollo, gli URL (Uniform Resource Locators) vengono utilizzati per trovare risorse su Internet o accessibili tramite esso.
4. Quali sono le caratteristiche dei servizi Web RESTful?
- Il paradigma Client-Server è alla base del servizio.
- Il servizio può accedere alle risorse tramite l'utilizzo di URI.
- Il servizio utilizza il protocollo HTTP per acquisire dati/risorse, eseguire query ed eseguire altre attività.
- La messaggistica è il nome del metodo utilizzato per comunicare tra il client e il server.
- Questi servizi possono anche implementare il modello architettonico REST utilizzando i servizi SOAP.
- Per ridurre le chiamate al server per lo stesso tipo di richieste ripetitive, questi servizi utilizzano anche l'idea della memorizzazione nella cache.
5. Quali sono i principi guida di REST?
Cinque criteri devono essere soddisfatti dalle API REST:
Disaccoppiamento client-server: per comunicare tra client e server è possibile utilizzare solo una serie di richieste e risposte. Solo client e server possono inviare rispettivamente richieste e risposte. Questa idea semplice consente a entrambe le parti di funzionare indipendentemente l'una dall'altra.
Interfaccia uniforme: deve esistere un protocollo uniforme per tutte le connessioni client-server. Questo protocollo per REST è HTTP. Poiché ogni applicazione richiede e invia dati utilizzando la stessa lingua, un'interfaccia coerente semplifica le integrazioni.
Stateless: il server non salva alcun record di richieste o risposte precedenti nella comunicazione stateless. Ogni richiesta e risposta forniscono tutti i dettagli necessari per completare lo scambio. La comunicazione stateless migliora la velocità, fa risparmiare memoria e riduce lo stress sul server. Inoltre, evita il potenziale fallimento di una richiesta a causa di dati incompleti.
Sistema a più livelli: i server che risiedono tra il client e il server API sono indicati come livelli. Questi server aggiuntivi eseguono una varietà di servizi, come il rilevamento dello spam e l'ottimizzazione della velocità. I livelli in REST sono modulari, il che significa che possono essere aggiunti ed eliminati senza influire sulle comunicazioni tra il client e il server API.
Memorizzazione nella cache: i client possono memorizzare nella cache qualsiasi risorsa per aumentare la velocità se le risposte del server indicano se la risorsa è memorizzabile nella cache o meno.
Codifica su richiesta: in risposta, un'API può trasmettere ai clienti il codice eseguibile del computer. L'applicazione client può quindi eseguire il codice sul proprio back-end.
6. Menziona i metodi HTTP supportati da REST.
I metodi HTTP supportati da REST sono:
- GET: questo metodo richiede una risorsa all'URL specificato. Un corpo della richiesta non deve essere incluso perché verrà ignorato. Potrebbe essere possibile memorizzarlo nella cache localmente o sul server.
- POST: questo metodo invia i dati a un servizio per l'elaborazione e il servizio dovrebbe normalmente restituire una risorsa nuova o modificata.
- PUT: la risorsa viene aggiornata all'URL della richiesta.
- DELETE: la risorsa viene eliminata all'URL della richiesta.
- Opzioni: identifica i metodi supportati.
- HEAD: vengono restituiti i metadati dell'URL della richiesta.
7. Descrivere le restrizioni poste da un'interfaccia coerente.
Per separare il client dal server, è necessaria un'interfaccia coerente.
Per ottenere un'interfaccia coerente, sono necessari i seguenti quattro vincoli:
- Identificazione delle risorse: le richieste del cliente devono utilizzare ID risorse standard per identificare le risorse (URI)
- Manipolazione delle risorse utilizzando queste rappresentazioni: i client dispongono di tutte le informazioni necessarie per poter modificare lo stato delle risorse quando ottengono una rappresentazione delle risorse dal server.
- Messaggi autodescrittivi: i messaggi includono tutti i metadati e altre informazioni necessarie al destinatario per comprenderli.
- Ipermedia come motore dello stato dell'applicazione: il canale per la comunicazione client-server è l'ipermedia, come HTML, e i client non necessitano di documentazione specifica dell'API per comprendere le risposte del server.
8. Che cos'è esattamente una risorsa REST?
Le risorse sono i componenti fondamentali di un servizio Web RESTful in un'architettura REST. Includono tutte le informazioni cruciali a cui un client API deve accedere.
Qualsiasi tipo di risorsa, come una pagina HTML, un'immagine, un video o qualsiasi altra cosa necessaria per un'attività API, è accessibile tramite il server in un sistema client-server.
Le risorse sono identificate da un Uniform Resource Identifier. Testo, JSON o XML sono tutte rappresentazioni accettabili di risorse. Ciò premesso, non vi sono limitazioni al formato della rappresentazione.
9. Cosa significa per te JAX-RS?
È più semplice creare servizi web RESTful in Java grazie all'API Java per i servizi web RESTful, spesso nota come JAX-RS. Gli sviluppatori possono descrivere le risorse e le operazioni che possono essere eseguite su di esse utilizzando le annotazioni fornite.
10. Cosa distingue AJAX e REST l'uno dall'altro?
Ajax:
- Ajax è un gruppo di tecnologie che consente l'aggiornamento dinamico di Interfaccia utente elementi senza dover ricaricare la pagina.
- Ajax rimuove la comunicazione asincrona tra il client e il server.
RIPOSO:
- REST richiede la comunicazione tra il server e il client.
- L'utilizzo delle risorse è importante per la struttura dell'URL e il modello di richiesta/risposta utilizzato da REST.
11. Puoi elencare alcuni inconvenienti dei servizi Web RESTful?
Le sessioni non possono essere mantenute poiché i servizi aderiscono alla nozione di apolidia. (Il cliente è responsabile del passaggio dell'ID sessione durante la simulazione della sessione.)
I vincoli di sicurezza non sono fondamentali per REST. I protocolli che lo utilizzano ereditano le precauzioni di sicurezza. Pertanto, è importante prestare attenzione durante l'adozione di misure di sicurezza, come l'integrazione delle autenticazioni basate su SSL/TLS.
12. Cosa distingue le tecniche PUT e POST l'una dall'altra?
METTERE:
- Non c'è cache per le risposte PUT.
- Idempotente (cioè più richieste produrranno lo stesso risultato)
- il carico utile della richiesta aggiorna o sostituisce la risorsa di destinazione.
INVIARE:
- idempotente no (cioè, più richieste produrranno multipli della stessa risorsa)
- Il server web elabora il payload della richiesta in base alla risorsa prevista.
- Se è inclusa l'intestazione di controllo della cache appropriata, le risposte POST possono essere memorizzate nella cache.
13. Come si testano i servizi Web RESTful?
Il test del servizio Web RESTful può essere aiutato da una serie di strumenti, tra cui Swagger e Postman. L'ispezione di parametri di richiesta come parametri di query, intestazioni e intestazioni di risposta è resa possibile dall'abbondanza di funzionalità di quest'ultimo.
Postman può essere utilizzato per effettuare richieste agli endpoint e mostrare i risultati. E XML e JSON possono essere creati da queste risposte.
Postman e Swagger forniscono entrambi funzionalità estremamente comparabili. D'altra parte, Swagger offre anche funzionalità come la documentazione degli endpoint.
14. Descrivi un'API REST nel mondo reale.
- I siti Web di viaggio e biglietteria possono sfruttare gli orari dei voli e i prezzi che le compagnie aeree mettono a disposizione tramite le API.
- Affinché le app di mappatura e navigazione (come Google Maps) possano utilizzarle, le agenzie di trasporto pubblico spesso rendono i propri dati pubblicamente disponibili in tempo reale tramite API.
- Le applicazioni meteorologiche utilizzano API aperte che scambiano dati meteorologici per visualizzare le informazioni meteorologiche.
- Gli sviluppatori possono accedere ai dati cartografici di Google Maps tramite una serie di API ospitate. Queste API vengono utilizzate dagli sviluppatori per incorporare mappe dinamiche nelle loro app e siti Web.
15. Come funziona l'architettura di microservizi?
- Le richieste vengono inviate da vari clienti utilizzando vari dispositivi.
- Dopo aver confermato le identità dei client, i provider di identità forniscono i token di sicurezza.
- Le richieste dei client sono gestite da API Gateway.
- Tutto il materiale del sistema viene conservato come contenuto statico.
- Lo strumento di gestione verifica l'equilibrio dei servizi sui nodi e gli eventuali guasti.
- L'individuazione del percorso di comunicazione tra i microservizi è facilitata dall'individuazione dei servizi.
- I data center e i server proxy costituiscono sistemi di rete dispersi chiamati reti di distribuzione dei contenuti.
- I servizi remoti forniscono l'accesso alle informazioni a distanza.
16. Che cos'è esattamente la memorizzazione nella cache?
La pratica di conservare temporaneamente una copia della risposta di un server da qualche parte (come la memoria del computer) per accedervi in seguito più rapidamente è nota come memorizzazione nella cache.
La memorizzazione nella cache migliora la velocità del server quando si utilizzano le API REST diminuendo la quantità di lavoro che il server deve eseguire per soddisfare la richiesta. Le applicazioni che utilizzano l'API vengono eseguite più velocemente grazie alla memorizzazione nella cache perché non devono inviare una nuova richiesta ogni volta che necessitano di una risorsa.
Il campo Cache-Control dell'intestazione della risposta HTTP contiene informazioni su quanto tempo una risorsa può essere memorizzata nella cache dal client prima che sia necessario accedervi nuovamente.
17. Descrivi il carico utile.
Il payload in REST si riferisce alle informazioni contenute nel corpo della risposta HTTP. Il cliente ha utilizzato la tecnica GET per richiedere i dati in questione.
Il documento contenente il testo del tweet e tutti i file necessari per inserire il tweet su un sito Web verranno inclusi nel payload, ad esempio, se chiedi all'API di Twitter un tweet specifico. Inoltre, il payload può essere incluso nella richiesta HTTP utilizzando il metodo POST.
18. Differenziare SAPONE Vs RIPOSO?
- A differenza di SOAP, che può gestire solo XML, REST consente una gamma più ampia di formati di risorse, inclusi XML, testo, HTML, immagini, video e altro.
- Quando la sicurezza è fondamentale per le applicazioni online, SOAP è utile. REST non può essere utilizzato quando le transazioni devono essere completate in modo sicuro poiché non è particolarmente sicuro.
- Poiché SOAP è solo un protocollo, REST può usarlo nei suoi servizi Web ma non viceversa.
- Mentre REST è solo un modello architettonico utilizzato per sviluppare servizi Web e rispetta alcune limitazioni come configurazione client-server, assenza di stato, risposta memorizzabile nella cache, sistemi a più livelli e interfaccia coerente, SOAP è un protocollo che opera su standard particolari che devono essere rigorosamente rispettati a.
- Mentre REST utilizza URI (Universal Resource Identifier), SOAP utilizza le interfacce di servizio per fornire le sue capacità alle applicazioni client. REST ha una richiesta di larghezza di banda inferiore rispetto a SOAP poiché i messaggi SOAP sono più ricchi di informazioni.
19. È possibile utilizzare il protocollo di sicurezza del livello di trasporto (TLS) con REST?
In effetti, possiamo. La comunicazione del client e del server REST è crittografata tramite TLS e il protocollo offre anche ai client un modo per autenticare i server.
Poiché è il sostituto del Secure Socket Layer, viene utilizzato per la comunicazione sicura (SSL). L'implementazione di servizi Web RESTful ha successo con HTTPS perché collabora efficacemente sia con TLS che con SSL.
Il REST eredita le caratteristiche del protocollo che implementa, cosa da notare qui. Di conseguenza, le protezioni di sicurezza dipendono dal protocollo utilizzato da REST.
20. Metodi idempotenti: cosa sono? Come si applica al mondo dei servizi web RESTful?
Quando l'URI è lo stesso, alcuni metodi HTTP in una richiesta hanno lo stesso impatto sul server indipendentemente dal fatto che vengano consegnati una o più volte. Le tecniche idempotenti sono quelle che vengono chiamate.
Ad esempio, indipendentemente dal numero di volte in cui viene eseguito un URI che utilizza il metodo GET, il server riscontrerà sempre lo stesso risultato. I metodi idempotenti includono GET, PUT e PATCH, solo per citarne alcuni.
I metodi HTTP idempotenti sono alcuni di quelli utilizzati da RESTful applicazioni web. Sono necessari per garantire la coerenza nelle attività dei servizi web RESTful.
I clienti che utilizzano le API REST possono commettere errori di codice che costringono un'API REST a effettuare richieste ripetute accidentalmente. Queste chiamate possono potenzialmente abusare delle risorse.
21. Qual è la funzionalità dell'autenticazione di base HTTP?
Quando si utilizza l'autenticazione di base come parte delle API, l'utente deve inviare il nome utente e la password, che vengono concatenati dal browser nella forma "nome utente: password" e codificati in base64.
Ad ogni richiesta HTTP dal browser, il valore codificato viene consegnato come valore per l'intestazione "Autorizzazione". Poiché le credenziali sono solo codificate, si consiglia di utilizzare questo modulo quando si inviano richieste HTTPS perché non sono sicure e possono essere intercettate da chiunque se non vengono utilizzati protocolli di sicurezza.
22. Pensi che GraphQL sia la scelta migliore per creare un'architettura di microservizi?
I microservizi e GraphQL vanno perfettamente d'accordo perché GraphQL mantiene la tua architettura di microservizi segreta ai tuoi clienti.
Dal front-end vuoi che tutti i tuoi dati provengano da un'unica API, mentre dal back-end vuoi dividerli in microservizi. La migliore tecnica di cui sono a conoscenza per ottenere entrambi è usare GraphQL.
Ti consente di dividere il tuo back-end in microservizi fornendo comunque a ciascuna applicazione una singola API e abilitando i join tra i dati di vari servizi.
23. Quali sono le principali distinzioni tra i metodi HTTP sicuri e idempotenti?
I metodi idempotenti producono lo stesso risultato quando vengono invocati una o più volte tramite la stessa richiesta. Il metodo PUT è idempotente.
Tutti i metodi sicuri sono idempotenti, ma non tutti i metodi idempotenti sono sicuri poiché i metodi sicuri non alterano le risorse. Ad esempio, GET è sicuro poiché recupera solo i dati e non altera la risorsa.
Inoltre, è idempotente, il che significa che restituirà sempre la stessa risposta quando viene invocato.
24. Cosa implica l'API JAX-RS per le classi di risorse radice RESTful?
Java Enterprise Edition fornisce classi e interfacce che aderiscono ai requisiti dell'API JAX-RS. Con l'aiuto di JAX-RS, la creazione di servizi Web Java nello stile architettonico REST è semplificata.
Nell'API JAX-RS, le classi di risorse root sono semplicemente "vecchi oggetti Java" o POJO. Per implementare le risorse web necessarie, utilizzano le annotazioni JAX-RS.
Hanno annotazioni @path o almeno uno dei loro metodi ha annotazioni @path. Possono essere riassunte come classi Java con metodi per gestire gli endpoint API.
25. Che cos'è esattamente Postman e perché viene utilizzato?
Uno strumento di sviluppo API chiamato Postman viene utilizzato per creare, testare e modificare le API. Questo strumento può essere utilizzato dagli sviluppatori per qualsiasi funzionalità richiesta per un'API. Semplifica e facilita il lavoro degli sviluppatori.
Postman semplifica la creazione di una varietà di query HTTP, tra cui GET, POST, PUT e PATCH, il salvataggio di ambienti per un uso successivo e la conversione delle API in codice in diverse lingue.
Ogni fase del ciclo dell'API è semplificata con Postman e la cooperazione è semplificata per uno sviluppo più rapido dell'API.
Inoltre, consente agli sviluppatori di gestire la documentazione, le specifiche, i casi di test, i processi e i cataloghi API.
26. Come vengono mantenute sicure le API REST?
Poiché le API REST non utilizzano misure di sicurezza rigorose come le API SOAP, i dati sensibili non devono essere inviati o recuperati utilizzandole.
Tuttavia, le affidabili API REST continuano a integrare controlli di sicurezza per trasmissioni di dati sicure e affidabili.
- Autenticazione e autorizzazione: ogni richiesta effettuata all'API deve superare questi due controlli. La verifica dell'identità del client tramite l'autenticazione e la convalida dell'autorizzazione ad accedere alle risorse richieste tramite l'autorizzazione sono due processi diversi.
- Convalida: prima che l'API conceda l'accesso alle sue risorse, le richieste devono comunque essere controllate per verificare la presenza di codice potenzialmente dannoso dopo l'autenticazione e l'autorizzazione. Un server sarebbe quindi soggetto a un attacco injection.
- Convalida: prima che l'API conceda l'accesso alle sue risorse, le richieste devono comunque essere controllate per verificare la presenza di codice potenzialmente dannoso dopo l'autenticazione e l'autorizzazione. Un server sarebbe quindi soggetto a un attacco injection.
- Crittografia: la crittografia TLS/SSL protegge la connessione tra client e server e impedisce agli hacker di intercettare richieste e risposte.
- Le tecniche di limitazione della velocità, come i limiti e la limitazione, proteggono i server da attacchi di forza bruta come DDoS che mirano a degradarli o bloccarli.
- Nessuna informazione sensibile negli URI: gli URI delle risorse non devono contenere dati protetti (come nome utente, password o token di autenticazione).
Conclusione
Congratulazioni! Diverse domande di intervista API REST di base o complesse e le rispettive soluzioni sono ora a portata di mano.
Ora che hai una buona idea di come rispondere ad alcune delle tipiche domande del colloquio con l'API REST, puoi continuare a rispondere alle interviste. Il prossimo passo dipende dai tuoi obiettivi.
Visita Serie di interviste con Hashdork per prepararsi alle interviste.
Lascia un Commento