We're updating the issue view to help you get more done. 

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

Change Description

None

Impact Analysis

None

Status

Assignee

Unassigned

Reporter

Pablo Pazos

Labels

Components

Priority

Major