DEV Community: Wentao Li

How Fresh Is a Chinese Airport METAR? A Python REST Check

Wentao Li — Sun, 25 Oct 2026 12:35:57 +0000

A weather API can answer in milliseconds and still return an observation made much earlier. For an airport dashboard, the useful question is not just “did the request succeed?” It is “when was this report observed, and how old was it when my application received it?”

Here is a small Python check for Beijing Capital (ZBAA) and Shanghai Pudong (ZSPD). I work on Skyviewor, the China airport METAR/SPECI API used below. The code makes one live request and prints the raw reports with their timestamps; the example does not claim a particular delivery latency.

python -m pip install httpx
export SKYVIEWOR_API_KEY='YOUR_API_KEY'

import os
from datetime import datetime, timezone

import httpx

airports = "ZBAA,ZSPD"
with httpx.Client(timeout=15.0) as client:
    response = client.get(
        "https://data.skyviewor.io/v1/metar",
        params={"airports": airports, "mode": "raw"},
        headers={"Authorization": f"Bearer {os.environ['SKYVIEWOR_API_KEY']}"},
    )
    response.raise_for_status()
    received_at = datetime.now(timezone.utc)
    reports = response.json().get("data", [])

for report in reports:
    observed_at = datetime.fromisoformat(report["obs_time"].replace("Z", "+00:00"))
    source_arrival = datetime.fromisoformat(report["arrived_at"].replace("Z", "+00:00"))
    print(report["icao"], report["report_type"], report["raw_metar"])
    print("  observation age:", received_at - observed_at)
    print("  source arrival after observation:", source_arrival - observed_at)

if not reports:
    print("No current report was returned for the selected airports.")

There are three different clocks here:

Clock	What it tells you
`obs_time`	When the airport observation was made.
`arrived_at`	When the upstream data source received that report.
`received_at`	When this particular Python request finished.

The first difference in the script is the age of the observation at your client. The second describes observation to source arrival. It is not a measurement of Skyviewor’s forwarding time or your network round trip. For precise client timing, also record the instant before client.get() and compare it with received_at. A single sample does not establish a latency percentile.

An HTTP 200 only means the query worked. It does not mean a new METAR was issued for every airport on that request. Keep both METAR and SPECI, and identify a report by (icao, obs_time, raw_metar) when storing results: a correction can share an observation time while changing the text. Treat an absent report as missing data, rather than inventing clear weather.

For a production service, log the request status and these timestamps separately. Handle 401/403 as a key or access problem and back off on 429; a tight retry loop will not make the airport issue reports faster. The complete HTTP guide and downloadable Python script include the response shape and an airport list. Skyviewor provides low-latency REST access for 55 supported Chinese airports.

If you want to run the request with your own key, start a Skyviewor trial. Trial eligibility and timing are shown during setup.

Low-Latency China METAR Push: Heartbeats and Reconnect Recovery

Wentao Li — Sun, 25 Oct 2026 12:00:37 +0000

If an airport feed must react when a new METAR or SPECI reaches the service, repeated HTTP polling wastes requests and still leaves a polling interval. A WebSocket lets Skyviewor actively push updates for subscribed Chinese airports. The hard part of a useful client is what happens when no report arrives, or when the connection drops.

I work on Skyviewor. This article is about the state machine behind our downloadable Python client, not a claim that every airport publishes at a fixed interval or that every update arrives within a fixed number of seconds.

A quiet socket can be healthy

The connection opens at wss://data.skyviewor.io/v1/ws/metar?airports=ZBAA%2CZSPD with an Authorization: Bearer ... header. New reports arrive as new_metar_arrived messages. There may be no such message for a while because airports publish observations on their own schedule.

The client therefore sends the application message {"action":"ping"} every 20 seconds and expects a {"type":"pong"} within 15 seconds. That checks whether this API session responds; it does not count as a weather update. A library's WebSocket protocol ping is separate from the required application heartbeat. If the application heartbeat or another valid subscription operation stops for 60 seconds, the server can close the session with code 4000.

async def heartbeat(websocket, pong):
    while True:
        started = asyncio.get_running_loop().time()
        pong.clear()
        await asyncio.wait_for(websocket.send('{"action":"ping"}'), 10)
        await asyncio.wait_for(pong.wait(), 15)
        await asyncio.sleep(max(0, 20 - (asyncio.get_running_loop().time() - started)))

async def receive(websocket, pong):
    async for raw in websocket:
        message = json.loads(raw)
        if message.get("type") == "pong":
            pong.set()
        elif message.get("type") == "new_metar_arrived":
            process_reports(message.get("data", []))
        elif message.get("type") == "error":
            raise RuntimeError("Subscription error")

This excerpt needs asyncio, json, and your own process_reports function. The linked client includes the connection setup and runnable imports. Keep health and business delivery as separate metrics: a successful pong proves responsiveness, while only new_metar_arrived proves a subscribed report was pushed.

Recover state after reconnecting

The stream does not replay every message missed while offline and does not provide an initial snapshot. In a production client, start reading and buffering events after opening the connection, then request GET /v1/metar/latest?airports=ZBAA,ZSPD over HTTP. Merge the snapshot with buffered events before exposing state to your application. Do not let an older snapshot overwrite a newer live report. Deduplicate by (icao, obs_time, raw_metar) so a corrected report with different text is retained. The downloadable demo prints the snapshot and following events; it does not implement this application-state merge for you.

connect and start reader
  -> buffer live updates
  -> fetch latest state over HTTP
  -> merge snapshot + buffered updates
  -> continue processing live updates

on heartbeat timeout or disconnect
  -> cancel and await reader + heartbeat
  -> close old socket
  -> wait with capped backoff and jitter
  -> open one replacement connection and repeat

Make that one reconnect loop per logical client. Skyviewor's default key limit is three concurrent WebSocket connections, shared across all your processes. A short release race or a lost connection can produce handshake 429; retry serially with a finite attempt budget. Stop on 401/403 until the key or access is fixed. The full guide and runnable Python client show the bounded retries and a three-minute demo run.

Low latency here means updates are pushed when they reach the service rather than waiting for your next polling request. Measure observation time, source arrival, and client receipt separately before making a numerical latency claim about your own workload.

To try the stream with your own key, start a Skyviewor trial. The guide above has the runnable client and setup steps.