A container for a collection of resources.

Indicates the purpose of this bundle- how it was intended to be used.

It's possible to use a bundle for other purposes (e.g. a document can be accepted as a transaction). This is primarily defined so that there can be specific rules for some of the bundle types.

The base URL for the service that provided these resources. All relative URLs are relative to this one (equivalent to xml:base).

If a set of search matches, this is the total number of matches for the search (as opposed to the number of results in this bundle).

Only used if the bundle is a search result set.

A series of links that provide context to this bundle.

A name which details the functional use for this link - see [[http://www.iana.org/assignments/link-relations/link-relations.xhtml]].

The reference details for the link.

An entry in a bundle resource - will either contain a resource, or information about a resource (transactions and history only).

The Base URL for the resource, if different to the base URL specified for the bundle as a whole.

This allows bundles to be composed of resources from multiple servers (collated search, documents etc).

A series of links that provide context to this entry.

The Resources for the entry.

Information about the search process that lead to the creation of this entry.

Why this entry is in the result set - whether it's included as a match or because of an _include requirement.

When searching, the server's search ranking score for the entry.

Servers are not required to return a ranking score. 1 is most relevant, and 0 is least relevant. Often, search results are sorted by score, but the client may specify a different sort order.

Additional information about how this entry should be processed as part of a transaction.

The HTTP verb for this entry in either a update history, or a transaction/ transaction response.

A search URL for this resource that specifies how the resource is matched to an existing resource when processing a transaction (see transaction documentation).

If the ETag values match, return a 304 Not modified status. See the read/vread interaction documentation.

Only perform the operation if the Etag value matches. For more information, see the API section "Managing Resource Contention".

Only perform the operation if the last updated date matches. For more information, see the API section "Managing Resource Contention".

Instruct the server not to perform the create if a specified resource already exists. For further information, see "Conditional Create".

Additional information about how this entry should be processed as part of a transaction.

The status code returned by processing this entry.

The location header created by processing this operation.

The etag for the resource, it the operation for the entry produced a versioned resource.

This has to match the version id in the header if a resource is included.

The date/time that the resource was modified on the server.

This has to match the same time in the meta header if a resource is included.

XML Digital Signature - base64 encoded.

This is base 64 encoded to address issues with json/xml.