Skip to main content Link Menu Expand (external link) Document Search Copy Copied

This is a draft, expect sudden changes and come back later

Microservices proxy

tags: internal

This guide details how to build backend microservices using WeatherAPI as a proxy.

General terms

Use of the API is subject to the OLA, as described in the Operational Level Agreement.

Any links to the API generated on the backend must not use hardcoded hostnames, since the destination varies according to each environment (public, internal, staging, testing etc). Instead you must read the following HTTP headers which are included in all requests from the API:

  • X-Forwarded-Host
  • X-Forwarded-Proto

Here is a typical example of the headers sent by a request from the build server:


    "Accept-Encoding": "gzip",
    "Content-Length": "0",
    "Host": "",
    "User-Agent": "WeatherAPI/",
    "X-Forwarded-Host": "",
    "X-Forwarded-Proto": "https"



The k8s load balancer requires special configuration since it overwrites the X-Forwarded-Host and -Proto before sending the request to the backend. To compensate you must store the incoming headers in a custom header, e.g. X-External-Host. This can be added in kubeconf.yml which is generated during deployment:

kind: Ingress
  annotations: |
      proxy_set_header X-External-Host \$http_x_forwarded_host;
      proxy_set_header X-External-Proto \$http_x_forwarded_proto;



The returned request body cannot be empty; this is flagged as an error in the API.

Response headers

  • Content-Type: This must be an IANA-registered media type. If you invent your own the API conversion routines will fail


For more information, including technical details, please contact:

  • Geir Aalberg (
  • Håvard Futsæter (
—Geir Aalberg, 9 January 2020