RESTful API
design & development
in Vienna

An API that needs to exchange data with the national government of Austria has to speak a specific dialect. Invoices sent electronically to a national government body are expected in the ebInterface format, an Austrian XML standard built for exactly this purpose. Alternatively they can be delivered through PEPPOL, the wider European network for structured electronic documents. A generic invoice export, however well formed, will not be accepted through either channel without mapping its fields to the structure the receiving system expects.

Building that mapping is more than a formatting exercise. Fields that a general accounting API treats as optional, such as a reference number tied to the purchase order or the framework agreement behind it, are often mandatory for an invoice addressed to a national government agency. Skipping one of these fields does not produce a soft warning. It produces a rejected submission, discovered only once the supplier is already waiting to be paid.

A second, unrelated requirement touches any API that moves sales data out of an Austrian point of sale. The cash register security rules of the country, known as the RKSV, require each receipt to carry a digital signature. That signature is generated by the register itself, chained to the previous receipt, so that a gap or an altered entry is detectable. If an API pulls transaction data from that register to feed a reporting tool, a loyalty system or an external accounting package, it has to treat the signed receipt as the record of truth rather than reconstructing totals from a different source.

This matters most when a business wants to automate something that sounds simple, such as syncing daily sales into a dashboard or a central ledger. The temptation is to pull raw transaction rows from whichever database is easiest to reach. The safer approach reads from the same signed chain the cash register produces. The numbers an API reports can then never drift from the numbers the register itself would show under an inspection.

None of this is exotic engineering. Both requirements are well documented. Both have existing libraries and reference implementations a development team can build against, rather than reverse engineer from scratch. The risk is not technical difficulty. It is treating an integration built for a generic client the same way as one addressed to a national government system or wired into a fiscal register, when the two demand different handling from the first line of code.

The choice between a REST API and a GraphQL API is not a matter of which is newer or more fashionable. Each solves a different problem well. Picking the wrong one for a given integration shows up months later as either a bloated set of endpoints or a client struggling with a query language it did not need. The right starting question is who will be calling the API, and how varied their data needs are.

REST tends to win when many different, loosely coordinated clients will consume the same API. Think of a public integration used by partners, or a service exposed to third parties who each build against it independently. Its endpoints are predictable. Its shape rarely surprises anyone. Its responses cache well at the network level, and its learning curve is shallow for an integrator who has never touched the system before. Documentation, tooling and monitoring built around REST are mature and widely understood.

GraphQL earns its complexity when a small number of tightly coupled clients need very different shapes of the same underlying data. Often these clients are built and maintained by the same team as the API itself. A mobile app and a desktop dashboard pulling from the same backend can each request exactly the fields they need in a single call, instead of over-fetching a fixed REST response or making several round trips to assemble the same view.

That flexibility has a cost. A GraphQL server has to guard against expensive, deeply nested queries that a careless or malicious client could use to overload the backend. A REST endpoint does not face that problem. Its response shape is fixed from the start. Caching also takes more deliberate design, since a generic HTTP cache cannot key on the contents of an arbitrary query the way it can on a stable REST URL.

Versioning behaves differently between the two as well. A REST API commonly moves forward through a new version number when a breaking change is needed, giving existing clients time to migrate at their own pace. GraphQL is usually designed to evolve a single schema in place, adding fields rather than replacing endpoints. This avoids version sprawl but asks for more discipline about what gets marked as deprecated, and when it can actually be removed.

For most integrations, the honest answer is that REST covers the majority of cases well. Reaching for GraphQL without a genuine multi-client, multi-shape data problem adds operational weight for no real benefit. Simple usually wins. The decision is worth making deliberately, in a short design conversation before the first endpoint is built, rather than by default or by whichever technology a new team member happens to know best.