Kong Gateway

techhadoop

In Kong Gateway, the Service and Route are core entities that determine how external requests are proxied to your upstream APIs or services.

Here’s how they work together:

1. Service (What you proxy to)

A Service in Kong represents an upstream API or backend application you want to expose via Kong.

Example:

{
  "name": "example-service",
  "url": "http://my-upstream-api:8080"
}
  • This defines where Kong should send requests once they are matched.
  • It includes details like host, port, path, or protocol.

2. Route (How requests are matched)

A Route defines the rules that determine which requests should be forwarded to a Service.

Example:

{
  "paths": ["/api/v1"],
  "methods": ["GET", "POST"],
  "service": { "id": "example-service-id" }
}
  • It maps incoming requests (based on path, method, host, headers, etc.) to a specific Service.
  • One service can have multiple routes (e.g., /v1/users, /v1/orders, etc.).

The Flow

Client --> Kong Gateway --> [Route matched] --> [Service invoked] --> Upstream API
  1. Kong receives a request.
  2. It checks the Route rules (e.g., path, host).
  3. If a match is found, it forwards the request to the associated Service.
  4. The upstream service processes it and returns the response via Kong.

Plugins

You can attach plugins (like rate-limiting, auth, logging) at:

  • Global level (applies to all requests)
  • Service level (applies to all routes of a service)
  • Route level (applies only to that route)

Quick Example via curl

# Create a service
curl -i -X POST http://localhost:8001/services \
  --data name=example-service \
  --data url=http://httpbin.org

# Create a route to that service
curl -i -X POST http://localhost:8001/services/example-service/routes \
  --data paths[]=/test

Now, accessing http://localhost:8000/test will proxy to http://httpbin.org.

Example 2:

Absolutely. Let’s break down how Services and Routes work in Kong Gateway, with a clear explanation, flow, and examples.

🔹 What Is a Service in Kong?

A Service in Kong Gateway represents an upstream API or microservice. This is the destination Kong forwards requests to. You define a service with details like the host, port, and protocol (HTTP, HTTPS, TCP, etc.).

Example:

{
  "name": "user-service",
  "url": "http://user-api.internal:8080"
}

Or more explicitly:

{
  "name": "user-service",
  "host": "user-api.internal",
  "port": 8080,
  "protocol": "http"
}

🔸 What Is a Route in Kong?

A Route defines how incoming client requests are mapped to a Service. Routes define rules and match criteria like:

  • Path (e.g., /users)
  • HTTP method (e.g., GET, POST)
  • Host (e.g., api.myapp.com)
  • Headers
  • SNI (for SSL)
  • TCP/UDP port

Example:

{
  "paths": ["/users"],
  "methods": ["GET", "POST"],
  "service": { "id": "uuid-of-user-service" }
}

🔄 How Do They Work Together?

  1. A client sends a request to Kong (e.g., GET https://api.myapp.com/users).
  2. Kong matches the request to a Route based on the defined criteria.
  3. The Route is linked to a Service.
  4. Kong forwards the request to the upstream Service.
  5. The response is returned to the client.

🔁 Flow Diagram (Simplified)

Client
  |
  v
[Request: GET /users]
  |
  v
[Kong Gateway]
  |
  ├─► Match Route: "/users" → user-service
  |
  └─► Forward to: http://user-api.internal:8080
              |
              v
      [Upstream Service Response]
              |
              v
          [Kong Gateway]
              |
              v
            Client

🧪 Practical Example Using curl

1. Create Service

curl -i -X POST http://localhost:8001/services \
  --data name=user-service \
  --data url='http://user-api.internal:8080'

2. Create Route

curl -i -X POST http://localhost:8001/services/user-service/routes \
  --data paths[]='/users'

Now, when you call:

curl http://localhost:8000/users

Kong will route it to:

http://user-api.internal:8080

Advanced Matching Capabilities

Routes can also match based on:

  • hosts (virtual hosts like api.myapp.com)
  • methods (GET, POST, etc.)
  • headers (e.g., X-Version)
  • snis (for SSL/TLS)
  • sources/destinations (for TCP streams)

Best Practices

  • Keep one route per API path unless multi-match is needed.
  • Use tags to categorize services/routes for environments.
  • Apply plugins at service or route level depending on scope:
    • Service-level plugin: applies to all routes to that service.
    • Route-level plugin: applies only to that specific route.

Would you like a visual diagram in PNG or SVG format, or a Postman collection to test this setup?

Leave a comment