An API Gateway is responsible for managing the public interface presented to external customers. It should handle low level issues like:
- protocol compliance
- blacklisting
- rate limiting
- quotas
- versioning
- request normalization
It can interface with:
- a discovery system to know which internal web services should handle what public endpoints
- a routing system to know how to translate public routes to internal routes
- an authorization system to know how to translate external API tokens to internal authorization credentials, so that individual web services don't have to repeatedly ask for those themselves.
In short it should handle common issues across the public surface area of API. It should not have any knowledge of the specific business logic details of a particular web service or a particular route.
Individual web services need to validate their own inputs. Only individual services know what parameters are valid and what types those parameters can assume. However, if the web services use JSON payloads, the API Gateway can do basic JSON validation and perhaps even check payloads against JSON Schemas for them on a per-URL basis.
An API Gateway can handle authentication, as it usually can be connected to an Identity Provider, has knowledge of various authentication protocols, and can be configured to provision authorization tokens. Though often folks have their own authentication schemes and workflows that go beyond what an API Gateway provides out of the box.
An API Gateway should certainly validate authorization tokens provided by external callers, and should help simplify some aspects of access control that individual web services face by enhancing payloads with roles or rights the authorization token is entitled to. But individual services are still responsible for granular checks of those roles, and business logic security.
An API Gateway is often configured at the edge or in a DMZ, as it faces untrusted traffic and has a responsibility to transform it into a more syntactically normalized form. Web services are still responsible for semantics.
If an HTML-generating web application consumes APIs, there is a policy decision about whether that application consumes only public-facing APIs, or also can consume internal APIs directly from internal web services. There are pros and cons to both sides. The architecture emerges from that decision.