What does the client need?
Identify resources, protocol and required journey; choose by needs rather than a standards label.
MOBILE-ID · TRUSTED LTANS
REST API vs LTAP Adapter
Choose REST or an LTAP adapter by client needs, protocol, functional scope and acceptance readiness.
Choose an interface for the source system
| Criterion | REST Mobile-ID | LTAP adapter |
|---|---|---|
| Scope | 26 operations under OpenAPI 3.0.0-draft; explicit resources/jobs. | Six draft-08 operations mapped to canonical commands/queries. |
| Suitable client | Web apps, DMS/ECM and software integrating the JSON contract. | Clients requiring LTAP with an agreed interoperability profile. |
Renewal | POST /v1/renewals and explicit renewal modes. | Do not invent a seventh renewal operation in the draft. |
| Authentication | Provisioned OAuth 2.0/mTLS plus object authorization. | Agree client/adapter security and identity mapping; do not assume REST equivalence. |
| Acceptance | Schemas/examples validated in-package; backend needs a provisioned environment. | Target design; no adapter interoperability acceptance supplied. |
Three questions before selection
Is a profile agreed?
Agree version, custody, security, errors and asynchronous behavior before a PoC.
Can it be accepted?
Execute interoperability cases for the selected interface; a mapping is not a test result.