[MGNLREST-152] Configure multiple delivery endpoints in separate modules Created: 20/Nov/17 Updated: 09/Apr/18 Resolved: 30/Jan/18 |
|
| Status: | Closed |
| Project: | Magnolia REST Framework |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | 2.1 |
| Type: | Story | Priority: | Major |
| Reporter: | Christopher Zimmermann | Assignee: | Dai Ha |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | 0d | ||
| Time Spent: | 11d 4.5h | ||
| Original Estimate: | 7d 3h | ||
| Issue Links: |
|
||||||||
| Template: |
|
||||||||
| Acceptance criteria: |
Empty
|
||||||||
| Task DoD: |
[ ]*
Doc/release notes changes? Comment present?
[ ]*
Downstream builds green?
[ ]*
Solution information and context easily available?
[ ]*
Tests
[ ]*
FixVersion filled and not yet released
[ ] 
Architecture Decision Record (ADR)
|
||||||||
| Release notes required: |
Yes
|
||||||||
| Documentation update required: |
Yes
|
||||||||
| Date of First Response: | |||||||||
| Epic Link: | REST Phase2 | ||||||||
| Sprint: | Saigon 129, Saigon 130, Saigon 131, Saigon 132 | ||||||||
| Story Points: | 13 | ||||||||
| Description |
|
It should be possible to configure endpoint definitions separtately (for example with separate YAML files) which can be in separate modules. - It should be possible to work with them in the same way as defintitions for apps or virtualURI's. Currently one can only define one delivery endpoint, which can be decorated. If more than one definition is supplied, then only one of them is used. Some open questions:
|
| Comments |
| Comment by Mikaël Geljić [ 10/Jan/18 ] | |||||||||||||||||||||
| |||||||||||||||||||||
| Comment by Christopher Zimmermann [ 17/Jan/18 ] | |||||||||||||||||||||
|
So the endpoint url would then always be the path to the endpoint file, instead of /.rest/delivery/? File path delivery.yaml File path sooper.yaml File path /delivery/imfree.yaml | |||||||||||||||||||||
| Comment by Dai Ha [ 17/Jan/18 ] | |||||||||||||||||||||
|
I had a PR which implements below behaviors: /module_name/restEndpoints/delivery/def_v2.yaml -> {context}/.rest/delivery/def/v2 --> no need to re-configure web access/module_name/restEndpoints/p1/p2/p3/def_v1.yaml -> {context} /.rest/p1/p2/p3/def/v1 /module_name/restEndpoints/def_v1.yaml -> {context} /.rest/def/v1 Team had decided to support multiple endpoints for a new endpoint class "info.magnolia.rest.delivery.jcr.v2.JcrDeliveryEndpoint", each endpoint definition will bind to one workspace. This helps the old ones work as is. In additional, new attribute "endpointPath" was introduced in definition for flexibility to by-pass above convention. It mean if endpoint is defined with "endpointPath", then the endpoint url will be value of "endpointPath". For example: /module_name/restEndpoints/p1/p2/p3/def_v1.yaml {endpointPath: a/b/c/v1} -> {context} /.rest/a/b/c/v1 | |||||||||||||||||||||
| Comment by Mikaël Geljić [ 17/Jan/18 ] | |||||||||||||||||||||
|
Where does tours/v1 come from in your examples? There's no "endpoint-prefix" anymore, as the workspace-parameters get flattened into the v2 JcrDeliveryEndpointDefinition.
(1) changes of config change the behavior, so the version in the file name becomes a mere recommendation | |||||||||||||||||||||
| Comment by Christopher Zimmermann [ 17/Jan/18 ] | |||||||||||||||||||||
|
Looks good on first impression! So the version path segment is actually completely optional and does nothing special except route to a specific endpoint config? | |||||||||||||||||||||
| Comment by Mikaël Geljić [ 18/Jan/18 ] | |||||||||||||||||||||
|
I just mentioned conflict on the first example, as it would pbly be a bad idea to name the new endpoint just delivery; or more generally to have overlap between endpoint paths on different depth (e.g. /foo and /foo/bar). Re: A/B cases, you mean if you had a v1 previously configured? There's no prefix in v2; but if you mean v1 these might be good cases to check during QA.
Exactly. | |||||||||||||||||||||
| Comment by Dai Ha [ 18/Jan/18 ] | |||||||||||||||||||||
|
Just try out the ambiguous case: Verified both endpoints work. I am thinking about a mechanism to prevent conflict on paths in case a new endpoint registering. |