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:
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.
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.