The HDSI, AMI and BIS all support a variety of response formats which are controlled by the Accept header. Valid accept headers are:
XML format optimized for synchronization interfaces
JSON format optimized for synchronization interfaces
JSON format optimized for HTML rendering
XML is the preferred method of transport for the HDSI, AMI and BIS. XML has several advantages over the JSON format messages, especially when running SanteDB in a full .NET Framework Environment. These benefits include:
Pre-Compiled Serialization - The .NET framework pre-compiles serialization and parsing libraries which make the reading and writing of XML much faster.
Use of Streams - When using XML serialization the parser and serializer classes use .NET memory streams and stream readers. This is much faster and less memory intensive than the string based processing that the JSON formats use.
Easy Validation / Translation - When using XML you can leverage the XSD and XSLT functions of XML to easily validate and transform messages. SanteDB provides schemas for all payload classes in XSD.
Additionally, SanteDB offers content compression on response and request payloads. When compressed the size of the payloads over the wire are negligible when compared to compressed JSON formats.
JSON format payloads which are a 1:1 map of the XML payloads can be obtained using the synchronization JSON format. These payloads are small since they make the assumption that the caller already has prior knowledge of referenced data.
When using this format, the response objects are serialized (using JSON.NET) directly to the wire. There is a performance penalty however, since JSON.NET uses string manipulation to achieve parsing and serialization.
ViewModel JSON is a convenience method of serialization, and is intended for use when the client may not have the ability (or desire) to synchronize data with the entire server. ViewModel JSON works by expanding (lazy loading) properties and including them as nested objects in the response payload.
This is extremely helpful when rendering data, consider, for example, the following patient result:
While this consumes more bandwidth, it does save roundtrips to the server.
Request / Response Compression
SanteDB is designed to work in low-resource environments with high latency narrowband networks. This means that SanteDB provides a variety of data compression algorithms which can be specified when interacting with the server.
Request payloads which are compressed are indicated using the Content-Encoding HTTP header and the Accept-Encoding HTTP header to control the compression of the response.