Das API-Gateway
Spring Cloud Gateway als zentrale Eingangstür: Routing und Querschnittsbelange wie Auth und Rate Limiting an einem Ort.
Deutsche Übersetzung in Arbeit
Diese Lektion ist noch nicht ins Deutsche übersetzt und wird daher auf Englisch angezeigt. Der Rest der Seite ist vollständig lokalisiert.
Auf dieser Seite
If a client had to know the address of every microservice - catalog here, lending there, notifications elsewhere - and handle auth against each, the client would be a mess and your internal structure would leak to the world. An API gateway fixes this: it's the single front door that every request enters through.
One entry point
Spring Cloud Gateway sits in front of your services. Clients talk only to it; it routes each request to the right service and applies cross-cutting concerns in one place:
spring:
cloud:
gateway:
routes:
- id: catalog
uri: lb://catalog-service # load-balanced via discovery
predicates:
- Path=/api/books/** # this path -> catalog service
- id: lending
uri: lb://lending-service
predicates:
- Path=/api/loans/** # this path -> lending serviceA request to /api/books/** is forwarded to catalog-service; /api/loans/** to
lending-service. The client sees one API; the decomposition stays hidden.
Cross-cutting concerns in one place
Because every request passes through it, the gateway is the natural home for concerns you'd otherwise duplicate in each service:
- Authentication — validate the JWT once at the edge.
- Rate limiting — throttle abusive clients.
- CORS, request logging, and header manipulation.
- Routing & load balancing — send traffic to healthy instances.
Visitors to a large company don't wander the floors hunting for the right department. They check in at one reception desk, which verifies their ID, issues a badge, and directs them to the right office. The API gateway is that reception: a single, controlled entry point that authenticates callers and routes them onward - so each department (service) doesn't run its own front door.
The gateway is where edge concerns live
Put authentication, rate limiting, and CORS at the gateway rather than reimplementing them in every service. Services behind the gateway can then trust that requests are already authenticated and well-formed, keeping each service focused on its own job.
BookVault is split into catalog and lending services. Sketch, in words, how the gateway routes
GET /api/books/123 and POST /api/loans, and name one cross-cutting concern you'd handle at
the gateway instead of in both services.
What is the primary role of an API gateway like Spring Cloud Gateway?
Key takeaways
- An API gateway (Spring Cloud Gateway) is the single entry point clients use; it routes each request to the right service.
- Routes match predicates (like a path prefix) to a target service, often load-balanced via discovery.
- Cross-cutting concerns - authentication, rate limiting, CORS, logging - live at the gateway instead of in every service.
- The gateway hides the internal service decomposition from clients, which see one unified API.
- Services behind it can trust requests are already authenticated and well-formed.