Add has_xxx operations to the REST API spec

Description

I'm reviewing the SM spec, and need to define how the has_xxx operations will work in the REST API implementation.
The openEHR SM spec has some operations to check if resources exist:

+ has_ehr https://specifications.openehr.org/releases/SM/latest/openehr_platform.html#_i_ehr_service_interface+ has_directory https://specifications.openehr.org/releases/SM/latest/openehr_platform.html#_i_ehr_directory_interface+ has_composition https://specifications.openehr.org/releases/SM/latest/openehr_platform.html#_i_ehr_composition_interface+ has_contribution https://specifications.openehr.org/releases/SM/latest/openehr_platform.html#_i_ehr_contribution_interface+ has_opt https://specifications.openehr.org/releases/SM/latest/openehr_platform.html#_i_definition_adl14_interface+ has_archetype https://specifications.openehr.org/releases/SM/latest/openehr_platform.html#_i_definition_adl14_interface

Note: those are abstract service definitions that could be implemented on many ways. Since we are dealing with a REST API, we need to define how those conceptual operations should be implemented, we have two options:

1. Using GET /xxx/{id}

The positive 200 could be interpreted as (has=true)

The negative 404 could be interpreted as (has=false)

For the positive case, a resource will be returned, which is not a problem, but requires extra resources.

2. Using HEAD /xxx/{id}

The positive 200 could be interpreted as (has=true)The negative 404 could be interpreted as (has=false)

But HEAD never retrieves a payload, which is semantically equivalent to the has_xxx operation, since that returns true or false, not any other content.

For this reason, I believe adding support for HEAD would be useful for testing conformance. But would like to hear opinions.

Environment

None

Status

Reporter

Pablo Pazos

Labels

Components

Priority

Major