Oracle Fusion Technical: Reports, Data, Integrations and Extensions · Module 10 · REST and SOAP: calling Fusion, and being called
Versioning and surviving a quarterly update
Lesson 107 of 177 · 2 min
Which parts of an API Oracle commits to, and which it does not. The versioned resource contract is the strong part. A resource at a version keeps its shape: attributes are added, not removed or retyped, and an operation that worked continues to work. That is what makes an integration a safer thing to build than a report, and it is why Module 1's release lesson says reports are the exposed artefacts rather than integrations. What is NOT committed to: the behaviour of an attribute whose meaning depends on configuration; anything you reached that is not in the published catalogue; the exact wording of error messages, which people parse and should not; and the ORDER of results where you did not ask for one. Pin the version in the URL where the API offers one, and know that pinning is a decision with an expiry: an old version is eventually…
The full lesson is part of the course
The video, the complete written lesson and the module quiz are included in Oracle Fusion Technical: Reports, Data, Integrations and Extensions, with a certificate on completion and a fourteen-day refund window.
In this module: Module 10 · REST and SOAP: calling Fusion, and being called
- 1What Fusion exposes, and what it does not
- 2REST vs SOAP: choosing without arguingFree preview
- 3Authentication and the service account
- 4Reading the REST API catalogue
- 5Your first call, and its error
- 6Payloads, child resources and partial updates
- 7Bulk operations and rate limits
- 8Fusion calling out: business events
- 9Idempotency and retries
- 10Versioning and surviving a quarterly update
- 11What breaks: five integration failures
- 12Lab briefing · Read, write and break an integration