[FOLIO-3105] SPIKE: Investigate OKAPI extensions to accommodate things like distributed configuration Created: 07/Apr/21 Updated: 21/Jul/21 Resolved: 19/Apr/21 |
|
| Status: | Closed |
| Project: | FOLIO |
| Components: | None |
| Affects versions: | None |
| Fix versions: | None |
| Type: | Task | Priority: | P2 |
| Reporter: | Craig McNally | Assignee: | Craig McNally |
| Resolution: | Done | Votes: | 0 |
| Labels: | R2, platform-core | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original estimate: | Not Specified | ||
| Issue links: |
|
||||||||||||||||||||||||||||||||
| Sprint: | CP: sprint 112, CP: sprint 111 | ||||||||||||||||||||||||||||||||
| Story Points: | 2 | ||||||||||||||||||||||||||||||||
| Development Team: | Core: Platform | ||||||||||||||||||||||||||||||||
| Release: | R2 2021 | ||||||||||||||||||||||||||||||||
| Description |
OverviewFollowing
Provide a way for modules to implement a common interface, with some easy way to tell OKAPI which one we want to call. Requirements
|
| Comments |
| Comment by Jakub Skoczen [ 07/Apr/21 ] |
|
Craig McNally Adam Dickmeiss I was thinking about something like a new parameter called "namespace" that would allow is to implement a regular interface by more than one module. Example: {
"id": "mod-hello-foo-1.0.0",
"name": "Hello foo module",
"provides": [{
"id": "configuration",
"version": "1.0",
"namespace": "foo"
"handlers": [{
"methods": [
"GET"
],
"pathPattern": "/config",
"permissionsRequired": ["foo.config"]
}]
}
}
and {
"id": "mod-hello-bar-1.0.0",
"name": "Hello bar module",
"provides": [{
"id": "config",
"namespace": "bar"
"version": "1.0",
"handlers": [{
"methods": [
"GET"
],
"pathPattern": "/config",
"permissionsRequired": ["bar.config"]
}]
}
}
Okapi then would mount the endpoint with an additional path prefix that takes the value of "namespace": /foo/config/ Additionally on the "requires" end Okapi would allow to depend on an interface in a specific namespace, like so: "requires": [
{
"id": "config",
"version": "1.0"
"namespace": "foo"
}
All (exiting) implementations that don't specify an explicit namespace would be considered in a ":default" namespace. |
| Comment by Adam Dickmeiss [ 07/Apr/21 ] |
|
Looks good to me.. I would have suggested to reuse the scope for this.. But perhaps it's just better to add a new property (the scope was an array as well !). We could be more explicit with the path patterns.. eg
{
"id": "mod-hello-foo-1.0.0",
"name": "Hello foo module",
"provides": [{
"id": "configuration",
"version": "1.0",
"namespace": "foo"
"handlers": [{
"methods": [
"GET"
],
"pathPattern": "/{namespace}/config",
"permissionsRequired": ["foo.config"]
}]
}
}
or even even: "pathPattern": "/{namespace}/{version}/config", if you want the interface version to be part of it too .. or "pathPattern": "/{namespace}/{version}/{id}", |
| Comment by Adam Dickmeiss [ 07/Apr/21 ] |
|
Jakub's suggestion would be a P3 in effort, I reckon. So this could be delivered for at least one module to use for P2 (like a PoC). |
| Comment by Jakub Skoczen [ 08/Apr/21 ] |
|
Adam Dickmeiss if we re-use 'scope' for this are we going to have a problem ensuring that only one implementation of a given interface can exist per scope? If not, then I don't see a problem. Though I don't see much value in being able to specify multiple 'scope' values. Regarding making the path more 'explicit' – I am not sure it's a good idea. I am concerned that it would make it harder for the client/UI code to call the ednpoints. How would they know how to supply the 'scope' in the request? I think we should have a "fixed" calling convention for this that is not configurable. We could make the path component a bit more special (similar to the /_/invoke mechanism) e.g /_/scope/bar/.... |
| Comment by Craig McNally [ 12/Apr/21 ] |
Adam Dickmeiss can you please clarify what you mean by a P3 in effort? |
| Comment by Craig McNally [ 12/Apr/21 ] |
|
See https://folio-org.atlassian.net/wiki/display/DD/Distributed+Configuration+via+Namespace |