REST, GraphQL or an XML File? Choosing the Right Interface
File exchange, REST APIs, GraphQL or webhooks: strengths, limitations and use cases of the most important interface types compared.
When two systems need to exchange data, the question of technology comes up early: is a file enough, do you need a REST API, or is GraphQL the better choice? Each option has strengths – what matters is what the systems, partners and processes involved require.
File-based exchange: XML and CSV
In a file-based exchange, one system creates a file that another system imports. XML is well suited to structured, nested data and can be validated against a schema. CSV is simpler but quickly reaches its limits with nested structures and special characters.
- Strengths: easy to trace, easy to archive, independent of the recipient’s software and well suited to fixed exchange formats between companies.
- Limitations: not real-time, errors often only show up at the recipient’s end, and responses have to be organized separately.
REST APIs
A REST API exposes data as resources over HTTP – such as jobs, customers or documents. A client queries or changes data specifically, and the response usually comes in JSON format. HTTP status codes indicate whether a request was successful.
GET /api/jobs/A-1042 HTTP/1.1
Accept: application/json
HTTP/1.1 200 OK
Content-Type: application/json
{ "id": "A-1042", "status": "in_progress", "sections": 3 }- Strengths: a widely used standard supported by almost every programming language, good for real-time queries and changes, and easy to document, for example with OpenAPI.
- Limitations: complex views often require several requests, and clients sometimes receive more data than they need.
GraphQL
GraphQL offers a single endpoint to which the client sends a query that describes exactly which fields it needs. This is useful when different interfaces – such as a web app and a mobile app – need different slices of the same data.
query {
job(id: "A-1042") {
status
sections { id length }
}
}- Strengths: flexible queries, less unnecessary data and a strongly typed schema.
- Limitations: more effort on the server side; caching and permissions require care; often oversized for simple partner integrations.
Events and webhooks
Instead of regularly asking whether anything has changed, a system can actively notify others: a webhook calls an agreed address as soon as, for example, a job has been completed. This saves unnecessary requests and shortens response times – but requires the recipient to be reachable and missed messages to be delivered again.
Comparison at a glance
| Criterion | File (XML/CSV) | REST API | GraphQL |
|---|---|---|---|
| Timeliness | delayed | near real-time | near real-time |
| Effort for simple cases | low | low to medium | medium |
| Exchange with external partners | very good with fixed formats | good | less common |
| Flexible queries | no | limited | yes |
| Validation against a schema | yes, e.g. XSD | yes, e.g. OpenAPI | yes, GraphQL schema |
What matters regardless of technology
- Data validation: check required fields, formats and plausibility before processing.
- Versioning: introduce format changes so that existing partners can keep working.
- Authentication: secure access and grant only the permissions that are needed.
- Logging: keep track of what was transferred and when.
- Idempotency: a transfer must be safe to repeat without creating duplicate data.
- Documentation: describe fields, examples and error cases clearly.
Conclusion
For fixed exchange formats with partners, a validated XML file is often the most robust solution. For real-time integration of your own systems, REST APIs are the proven standard, and GraphQL pays off when many different interfaces are involved. Many solutions combine several options – what matters is data validation, documentation and clean error handling.