Interoperability rules for an European API ecosystem: do we still need SOAP?
How Italy is introducing REST API and a more reliable IT architecture in the Public Administration.
Keynote by Roberto Polli, Full Stack Developer at Digital Transformation Team
of new services: - Very expensive (both for setup and maintenance/operation) - Complicates communication with non-governmental agencies - The IT world was moving beyond SOAP
protocol (HTTP, SMTP, ..) • adds one layer, with computational and architectural costs • virtually asynchronous exchanges (soap messages) Today: • new HTTP Semantics RFC 7230-7238 released in 2014 • services are inherently based on HTTP • synchronous exchanges (eg. mail vs chat)
using Path and Method (Eg. idempotent vs non-idempotent) • use Status and Headers for service management, don't have to process the body • Caching, Conditional and Range Requests, ...
API-first approach to REST APIs based on OpenAPI v3 • Scheme standardization based on national, European and industry standards • Availability strategy based on a distributed circuit-breaker and throttling patterns
ago 08:45:37 CEST 2018 Fri May 05 08:45:37 IST 2018-May-08 10:06:25 AM 05/12/2018 2018/12/05 12-05-2018 05/12/2018 2018-12-05 12-05-2018 Logs, dates: RFC5424 / 3339 2018-05-08T10:06:25Z 2018-05-08T10:06:25.000Z
basic units (eg. Bytes, seconds, …) - use increasing Service Level Indicators, the higher the better Example: - availability is 0-100% - expose success rates, not error rates Standardized metrics
was up for 95% of the time - success_rate: % of successful requests - target_response_time: expected latency at 95p Evaluating: - or responsiveness: the service meet the target_response_time for 90% of the time - or APDEX index: Standardizes metrics
for a non-repudiation framework. SOAP has a well-established (and criticized) standard for Signing and Encryption REST standards are Json Web Signatures|Encryption RFC7515 used by OpenID Connect (still criticized) Signatures and Encryption
(eg. json) - sign just the body (a sort of ws-security built with JWS) extending the objects with claims or adding an Headers - sign a fingerprint(request,header,body) via Headers Current request/response fingerprint functions and Signature headers proposals (eg. amz, draft-cavage, signed-exchanges) Signatures and Encryption
- EC keys are easily embedded in claims and headers On Headers - evaluate Structured Headers Example-DictHeader: en="Applepie", da=*w4ZibGV0w6ZydGUK=* - deprecate or adopt Digest Further discussions