For the APIs described by LIonWeb, which parts to we specify?
Assumption: We're talking about HTTP REST APIs.
Possible levels:
- Set of APIs
- Conceptual features of the API
- Partial data format on the wire
- Precise data format on the wire
- Minimal set of parameters
- Required and optional parameters
- Exact format of each parameter
- Endpoint address
"data format on the wire" means the precise serialization format of content/payload, i.e. nodes, as exchanged between LIonWeb components.
On 2023-07-07, we decided to describe conceptual features and precise serialization format, but not more. This corresponds to level 4.
Rationale: Every repository needs a different set of parameters (e.g. Modelix always needs a version tag, and the internal node id. MPS (as bulk server) needs a model id and some node ids). Similar for endpoint addresses.
The architectural solution would be another level of indirection. But then we essentially implement service discovery, which is definitely out of scope for LIonWeb.
Consequence: LIonWeb components cannot combine via plug&play -- each system needs to bind the components together in its own way. LIonWeb provides a common language to converse in once the participants found each other, and established their communication channels.
We might extend the level in the future, or in an additional spec.
For the APIs described by LIonWeb, which parts to we specify?
Assumption: We're talking about HTTP REST APIs.
Possible levels:
"data format on the wire" means the precise serialization format of content/payload, i.e. nodes, as exchanged between LIonWeb components.
On 2023-07-07, we decided to describe conceptual features and precise serialization format, but not more. This corresponds to level 4.
Rationale: Every repository needs a different set of parameters (e.g. Modelix always needs a version tag, and the internal node id. MPS (as bulk server) needs a model id and some node ids). Similar for endpoint addresses.
The architectural solution would be another level of indirection. But then we essentially implement service discovery, which is definitely out of scope for LIonWeb.
Consequence: LIonWeb components cannot combine via plug&play -- each system needs to bind the components together in its own way. LIonWeb provides a common language to converse in once the participants found each other, and established their communication channels.
We might extend the level in the future, or in an additional spec.