APIs & tile services

Serving features, tiles and imagery over HTTP: filters, paging, caching and the load that follows.

An endpoint with no page limit against one with a ceiling and a cursor. every endpoint needs a ceiling that you choseGET /features2,148,003 rows, 1.4 GB, one responsethe first curious client takes the service downGET /features?limit=10001,000 rows and a next cursorthe same data, on terms you setA default limit is not a restriction on the caller — it is the only thing keeping the service up

Serving spatial data over HTTP is mostly about ceilings. An endpoint with no page limit will eventually be asked for everything, and the first curious client takes the service down — not maliciously, just by pasting the URL without parameters.

So the work is bounding: a default page size with a cursor, a maximum bounding box, a simplification tolerance tied to zoom, a cache header that means something, and a tile scheme for anything that is genuinely large. OGC API Features and the XYZ tile convention exist so that callers already know the shape of those limits, which is a good reason to follow them rather than invent your own.

Below: the concepts cover the standards and what each is for; the how-to guides build and deploy the services; and the fixes cover the load, the caching and the CORS problems that follow.

Learning paths run through this topic too — see the end of this page.

🧭 Start with the concepts

The ideas the how-to guides below assume you already have.

⚙️ Then do the task

Step-by-step walkthroughs with code you can copy and adapt.

Show every how-to guide in this topic

🔧 When it breaks

The errors this topic produces, with the cause explained rather than just the command.

Related topics

Subjects that keep coming up alongside this one, most overlap first.

Keep browsing

APIs & tile services sits in Delivery & sharing. Every topic on the site is listed on the topics index.