REST vs SOAP: choosing without arguing

COVERAGE DIFFERS BY MODULE, NOT BY PREFERENCE. That sentence settles most of the argument before it starts. The question is which one supports the operation you need — and for a given object in a given release, frequently only one does. Only after that is it a question of which you would rather write, and by then the choice has usually been made for you. Where both are available, the honest comparison is short. REST is easier to read, easier to debug, and easier to hand to somebody else: a URL, a JSON body, an HTTP status. SOAP is more verbose, strongly described by its WSDL, and in some modules simply broader — particularly for older operations and for things that were never re-exposed. Do not choose on aesthetics and do not choose on what you used last time. Check the reference for the specific object and the specific operation,…

In this module: Module 10 · REST and SOAP: calling Fusion, and being called

1. 1What Fusion exposes, and what it does not
2. 2REST vs SOAP: choosing without arguingFree preview
3. 3Authentication and the service account
4. 4Reading the REST API catalogue
5. 5Your first call, and its error
6. 6Payloads, child resources and partial updates
7. 7Bulk operations and rate limits
8. 8Fusion calling out: business events
9. 9Idempotency and retries
10. 10Versioning and surviving a quarterly update
11. 11What breaks: five integration failures
12. 12Lab briefing · Read, write and break an integration