📖 HTTP, REST and SOAP
The client-server model explains who asks and who responds. The systems also need shared rules for how to send a request and a response.
HTTP: the web protocol
HTTP is the protocol commonly used for communication on the web. It defines request methods such as GET and POST and describes how a server returns a response and status code.
In a FHIR RESTful API, a client might send an HTTP GET request for
Patient/123. The server can respond with the Patient resource in JSON
or XML, or with an error response when the request cannot be completed.
REST: an architectural style
REST (Representational State Transfer) is an architectural style, not a protocol. A RESTful API applies REST principles while commonly using HTTP as its protocol.
FHIR defines a RESTful API with standard interactions for its resource model, including create, read, update, delete, and search. This is a widely used way to exchange FHIR resources, but it is not the only one. FHIR also supports documents, messaging, subscriptions, operations, and other exchange patterns.
SOAP: optional historical context
SOAP is an XML-based messaging protocol used by many web services, especially in enterprise systems. It did not create or formalize all client-server communication on the web. SOAP can be combined with separate WS-* specifications for features such as message-level security and reliable messaging.
For this beginner course, the main point is simply that SOAP and REST are different approaches. FHIR can be used in service-oriented architectures, while its RESTful API is the most familiar starting point for many implementations.
Security comes from the complete implementation
Neither REST nor SOAP makes a system secure automatically. A production FHIR service normally needs several layers of protection, including:
- HTTPS to encrypt data in transit;
- authentication to establish who or what is connecting;
- authorization to decide what that identity may do;
- input validation, logging, monitoring, and auditing; and
- organizational controls that meet the applicable privacy and security requirements.
OAuth 2.0 is commonly used as part of an authorization solution, but it does not replace the other controls.