Because someone else already runs the complex system you need — so you call their webservice for the data or function rather than rebuilding it yourself.

A webservice is a machine-to-machine interface a provider exposes over the internet: you send it an HTTP request and it sends back structured data (usually JSON or XML). The point is reuse — most of what an app needs already exists somewhere as a service.

Take an online travel agency that wants to find the cheapest trip to a destination. It does not own any flights, hotels, or rental cars. Instead it plugs into existing providers — flights from airlines like Lufthansa, rental cars from Hertz, books from Amazon — and stitches their offers together. Building and maintaining a global flight-pricing system yourself would be absurd when the airlines already publish one.

The same logic drives most integrations:

• Weather — show forecasts from a weather service instead of running your own meteorology.
• Payments — let Stripe or PayPal handle card data and fraud rather than touching it yourself.
• Maps — embed Google Maps or OpenStreetMap instead of mapping the planet.
• SMS / email — hand notifications to a specialised delivery service.

Tip: The trade-off is dependency — when their service is down or changes, your app feels it. That is why a stable, well-defined interface (and good error handling) matters.

Go deeper:

• Web service (Wikipedia) — the general concept: machine-to-machine communication over the internet using XML/JSON.
• REST (Wikipedia) — the architectural style most modern public APIs (including transport.opendata.ch) follow.

A website outputs HTML meant for human eyes; a machine can't reliably extract the data from it, so providers expose a separate webservice that returns clean, structured data.

Imagine you're booking a Mallorca package — flight, hotel, bus tours — and want to compare prices across Swiss, a hotel chain, and a tour operator. The problem: each company only gives you its public web page. That page is built for a person: prices are buried inside layout, styling, and ads, and the markup changes whenever they redesign. Writing code to "read" that page (called screen scraping) is fragile and breaks constantly.

A webservice solves this by offering a second, machine-facing door to the same data. Instead of an HTML page you get a predictable response like JSON, with named fields you can read directly:

{ "from": "ZRH", "to": "PMI", "price": 129.00, "currency": "CHF" }

So the distinction is the audience: the website serves humans, the webservice serves other programs. That is the gap external webservices fill.

Tip: This is why webservices are described as "stable, exact interfaces" — unlike a web page, the response shape is a contract other systems can depend on.