General API Guidance
General API guidance
Purpose
This site is intended for use by software developers looking to build a conformant GP Connect API interface with a focus on general API implementation guidance.
Notational conventions
The keywords ‘MUST’, ‘MUST NOT’, ‘REQUIRED’, ‘SHALL’, ‘SHALL NOT’, ‘SHOULD’, ‘SHOULD NOT’, ‘RECOMMENDED’, ‘MAY’, and ‘OPTIONAL’ on this site are to be interpreted as described in RFC 2119.
General standards
Information on the technical standards that SHALL be conformed to can be found in the sections below and throughout the GP Connect specification.
Internet standards
Clients and servers SHALL be conformant to the following Internet Engineering Task Force (IETF) request for comments (RFCs), which are the principal technical standards that underpin the design and development of the internet and thus FHIR's APIs.
- transport level integration SHALL be via HTTP as defined in the following RFCs: RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234 and RFC 7235
- transport level security SHALL be via TLS/HTTPS as defined in RFC 5246 and RFC 6176
- HTTP Strict Transport Security (HSTS) as defined in RFC 6797 SHALL be employed to protect against protocol downgrade attacks and cookie hijacking
RESTful API
The RESTful API described in the FHIR® standard is built on top of the Hypertext Transfer Protocol (HTTP) with the same HTTP verbs (GET, POST, PUT, DELETE, etc.) commonly used by web browsers. Furthermore, FHIR exposes resources (and operations) as Uniform Resource Identifiers (URIs). For example, a Patient resource /fhir/Patient/1, can be operated upon using standard HTTP verbs such as DELETE /fhir/Patient/1 to remove the patient record.
The FHIR RESTful API style guide defines the following URL conventions which are used throughout the remainder of this document:
- URL pattern content surrounded by [ ] are mandatory.
- URL pattern content surrounded by { } are optional.