...
- Doesn't require use of additional X-Okapi-* headers
- Allows modules to depend on the interface
- It's use is completely optional
- Clients are not required to know/determine the module Id in order to call a specific implementation of the interface.
Cons
- More complex OKAPI logic?logic that Okapi, front-end and back-end need to support
- Using namespace
"id":"distributed_configuration","namespace":"foo","pathPattern":"/configurations/entries"
doesn't have advantages over the existing path solution"id":"foo_configuration","pathPattern":"/foo/configurations/entries"
Other Considerations
- Do we want/need to incorporate version into the discriminator too? This is something that came up in the JIRA comments here.
- Do we even want to support RAML? If OpenAPI is the way forward, maybe we skip defining it in RAML...
- Has a way of sharing common API definitions/traits been sorted out yet on the OpenAPI side of things?
- Is the expectation that all modules will eventually move towards OpenAPI? Even those which currently use RAML?
...