API-versjonering med Nginx
Konfigurer Nginx til å støtte ulike API-versjoner, slik at oppgraderinger og bakoverkompatibilitet blir sømløse.
API-versjonering med Nginx er en gratis leksjon i API-gateway og reverse proxy (Nginx + Spring Cloud Gateway) på CoddyKit. Dette er leksjon 1 av 4. Du kan lese hele leksjonen gratis nedenfor – og deretter øve praktisk i nettleseren med en innebygd kodeeditor og en AI-veileder som er tilgjengelig døgnet rundt. Den er en del av læringsløpet i API-gateway og reverse proxy (Nginx + Spring Cloud Gateway), og fremdriften din synkroniseres mellom nettet og CoddyKit-appen. Kurset i API-gateway og reverse proxy (Nginx + Spring Cloud Gateway) inneholder totalt 4 leksjoner.
Hva er API-versjonering?
Når De bygger API-er, endres de ofte over tid. Nye funksjoner legges til, gamle fjernes eller logikken oppdateres.
API-versjonering er en strategi for å håndtere disse endringene uten å ødelegge eksisterende applikasjoner som er avhengige av API-et.
Den gjør det mulig for ulike versjoner av API-et å eksistere samtidig, slik at både eldre og nyere klienter støttes.
Hvorfor versjonering er viktig
Se for Dem at De oppdaterer API-et, og at alle apper som bruker den gamle versjonen plutselig slutter å fungere. Det gir en dårlig brukeropplevelse!
- Bakoverkompatibilitet: Sikrer at eldre klienter fortsetter å fungere.
- Kontrollerte oppgraderinger: Gjør det mulig for klienter å gå over til nye versjoner i sitt eget tempo.
- Risikohåndtering: Isolerer endringer og reduserer risikoen for omfattende problemer.
Vanlige tilnærminger til versjonering
Det finnes flere måter å angi en API-versjon på:
- URL-bane:
/api/v1/users - Egendefinert header:
X-API-Version: 1 - Spørringsparameter:
/api/users?version=1
For Nginx er versjonering med URL-bane ofte den enkleste og vanligste løsningen å implementere ved hjelp av location-blokker, og det er dette vi fokuserer på.
Nginx for URL-basert versjonering
Nginx bruker location-blokker til å samsvare med bestemte URL-mønstre. Dette passer perfekt for å rute forespørsler basert på et versjonsnummer i banen.
Forespørsler til /api/v1/ kan for eksempel sendes til én backend, mens forespørsler til /api/v2/ sendes til en annen.
Dermed kan De distribuere ulike versjoner av API-applikasjonen, der hver versjon leverer sin spesifikke API-versjon.
Sette opp API-versjon 1
La oss konfigurere Nginx til å rute forespørsler for /api/v1/ til en backend-server som kjører vår første API-versjon.
Vi definerer en upstream-blokk for backend-tjenesten og deretter en location-blokk for å videresende forespørslene.
http {
upstream api_v1_backend {
server 192.168.1.10:8080;
}
server {
listen 80;
server_name example.com;
location /api/v1/ {
proxy_pass http://api_v1_backend/;
proxy_set_header Host $host;
}
}
}Legge til API-versjon 2
La oss nå introdusere en ny versjon av API-et. Vi setter opp en separat upstream- og location-blokk for /api/v2/ og ruter den til en annen backend-server.
Dette viser hvordan Nginx kan dirigere trafikk til helt separate applikasjonsdistribusjoner basert på API-versjonen.
http {
upstream api_v1_backend {
server 192.168.1.10:8080;
}
upstream api_v2_backend {
server 192.168.1.11:8081;
}
server {
listen 80;
server_name example.com;
location /api/v1/ {
proxy_pass http://api_v1_backend/;
proxy_set_header Host $host;
}
location /api/v2/ {
proxy_pass http://api_v2_backend/;
proxy_set_header Host $host;
}
}
}Håndtere rot-/standardversjonen
Hva skjer hvis en klient ikke angir en versjon? De kan konfigurere Nginx til å omdirigere til den nyeste versjonen eller levere en standardversjon.
Ved hjelp av en rewrite-regel kan De internt endre URI-en slik at den peker til /api/v2/ hvis klienten ber om /api/ uten en versjon.
http {
# ... upstream blocks ...
server {
listen 80;
server_name example.com;
# Redirect /api/ to /api/v2/ internally
location = /api/ {
rewrite ^ /api/v2/ permanent;
}
location /api/v1/ {
proxy_pass http://api_v1_backend/;
proxy_set_header Host $host;
}
location /api/v2/ {
proxy_pass http://api_v2_backend/;
proxy_set_header Host $host;
}
}
}Prefikssamsvar og avsluttende skråstreker
Vær forsiktig med hvordan location-blokker samsvarer. En location /api/v1 samsvarer med /api/v1, /api/v1/ og /api/v1something.
Det er vanligvis tryggere å bruke location /api/v1/ (med en avsluttende skråstrek), siden den samsvarer med /api/v1/ og underbanene (for eksempel /api/v1/users), men ikke med /api/v10.
Direktivet proxy_pass håndterer også avsluttende skråstreker. Hvis proxy_pass http://backend/; har en avsluttende skråstrek, fjerner Nginx den delen av URI-en som samsvarte, før den videresendes.
Beste praksis for versjonering
Følg disse rådene for å gjøre API-versjoneringen smidig og effektiv:
- Dokumenter tydelig: Informer klientene om tilgjengelige versjoner og tidsplaner for utfasing.
- Vær konsekvent: Bruk samme versjoneringsstrategi på tvers av alle API-ene Deres.
- Planlegg utfasing: Gi rikelig med varsel før gamle versjoner fjernes.
- Overvåk bruken: Følg med på hvilke versjoner som fortsatt er i bruk, slik at beslutninger om utfasing blir informerte.
Nginx-versjonering: quiz
Se på følgende Nginx-konfigurasjon. Hvilken proxy_pass-destinasjon blir en forespørsel til http://example.com/api/v1/products rutet til?
server {
listen 80;
server_name example.com;
location /api/v1/ {
proxy_pass http://backend_old_api/;
}
location /api/v2/ {
proxy_pass http://backend_new_api/;
}
location / {
proxy_pass http://default_backend/;
}
}Oppsummering: API-versjonering med Nginx
De har lært hvordan API-versjonering implementeres ved hjelp av Nginx!
- Versjonering gjør det enklere å håndtere API-endringer og klientkompatibilitet.
- Nginx'
location-blokker egner seg godt for URL-basert versjonering. - De kan rute ulike API-versjoner til forskjellige backend-tjenester.
- Ved hjelp av
rewrite-regler kan De håndtere standardiserte eller uversjonerte forespørsler.
Dette gjør det mulig å videreutvikle API-ene på en smidig måte samtidig som alle brukerne fortsatt får tilgang til tjenesten.
Lær deg API-gateway og reverse proxy (Nginx + Spring Cloud Gateway) med en AI-veileder – gratis
Skriv og kjør ekte kode i nettleseren, få umiddelbar hjelp fra en AI-veileder som er tilgjengelig døgnet rundt, og fortsett der du slapp – på nettet eller i appen.
- Kurs
- 12
- Leksjoner
- 48
Ofte stilte spørsmål
Er leksjonen «API-versjonering med Nginx» gratis?
Ja – hele teksten i «API-versjonering med Nginx» er gratis å lese her på nettet. For å øve interaktivt med en innebygd kodeeditor og en AI-veileder som er tilgjengelig døgnet rundt, og for å låse opp resten av API-gateway og reverse proxy (Nginx + Spring Cloud Gateway)-kurset, kan du oppgradere til CoddyKit PRO. Kurset i API-gateway og reverse proxy (Nginx + Spring Cloud Gateway) inneholder totalt 4 leksjoner.
Hva lærer jeg i «API-versjonering med Nginx»?
Konfigurer Nginx til å støtte ulike API-versjoner, slik at oppgraderinger og bakoverkompatibilitet blir sømløse. Du øver på API-gateway og reverse proxy (Nginx + Spring Cloud Gateway) med praktisk kode som du kjører direkte i nettleseren, mens en AI-veileder som er tilgjengelig døgnet rundt, svarer på spørsmålene dine mens du jobber deg gjennom leksjonen.
Trenger jeg erfaring for å begynne med API-gateway og reverse proxy (Nginx + Spring Cloud Gateway)?
Ingen tidligere erfaring er nødvendig. API-gateway og reverse proxy (Nginx + Spring Cloud Gateway) på CoddyKit er lagt opp for både nybegynnere og viderekomne, så De kan begynne her eller helt fra start og lære i Deres eget tempo. Dette er leksjon 1 av 4.
Hvor lang tid tar leksjonen «API-versjonering med Nginx»?
De fleste CoddyKit-leksjoner tar omtrent 5–10 minutter. Hver leksjon er kort og interaktiv, slik at De gjør jevne fremskritt og kan fortsette akkurat der De slapp – både på nettet og i appen.
Kan jeg skrive og kjøre kode i denne API-gateway og reverse proxy (Nginx + Spring Cloud Gateway)-leksjonen?
Ja. Alle API-gateway og reverse proxy (Nginx + Spring Cloud Gateway)-leksjoner har en innebygd kodeeditor, slik at De kan skrive og kjøre ekte kode direkte i nettleseren og få umiddelbar tilbakemelding fra AI – uten lokal konfigurering.
Alle leksjonene i dette kurset
- API-versjonering med Nginx
- Cross-Origin Resource Sharing (CORS)
- Begrensning av forespørselsfrekvens med Nginx
- Stibasert ruting til mikrotjenester