GH-6 Mapping the Registration Adobe I/O Events API #8
Conversation
| Assert.assertEquals(TEST_VALUE, workspace.getConsumerOrgId()); | ||
| Assert.assertEquals(TEST_VALUE, workspace.getImsOrgId()); | ||
| Assert.assertEquals(TEST_VALUE, workspace.getTechnicalAccountId()); | ||
| Assert.assertEquals(TEST_VALUE, workspace.getMetascopes().iterator().next()); |
There was a problem hiding this comment.
nit: It will be better to use a different value for each field. This will make sure that the workspace POJO is managing/returning the correct value for each field.
| # api_key = your credential API Key (Client ID) as shown in in your Adobe Developer Console workspace | ||
| api_key=changeMe | ||
| # credential_id = your credential id as shown in your Adobe Developer Console workspace | ||
| credential_id=changeMe |
There was a problem hiding this comment.
Since Console uses "client_id", we should also use that only.
There was a problem hiding this comment.
unfortunately, it's not the clientId, it is yet another id, the (jwt) credential.id associated with your workspace (formerly known as the integrationId)
| } | ||
| if (StringUtils.isEmpty(workspace.getApiKey())) { | ||
| throw new IllegalArgumentException("Workspace is missing an apiKey context"); | ||
| } |
There was a problem hiding this comment.
- This validation code is common and can be moved to the Workspace constructor for re-use. wdyt?
- Are we following some paradigm on where to place the validation code? Is it inside the Builder class or the constructor of the corresponding model class? Currently, I see validation-related code at both places. We can consider moving all validations inside constructors of model classes only.
There was a problem hiding this comment.
- No it's not common. Elsewhere the api-key is only needed and set by the IMS auth interceptor. The Registration API is special, it expects it in the header of the registration input model
- The expected
workspaceentries vary from one service to the next, but to follow your advise, for one common validation paradigm, I moved the validation at the service constructor level, wdyt ?
| * | ||
| * @param imsOrgId your Ims Org Id | ||
| * @param consumerOrgId Your consumer organization Id | ||
| * @param credentialId The integration Id associated with your project/workspace |
There was a problem hiding this comment.
Is this clientId only, right? Lets use the same terminology everywhere.
There was a problem hiding this comment.
no unfortunately, it's not the clientId, it is yet another id, the (jwt) credential.id associated with your workspace (formerly known as the integrationId)
| "eventCode='" + eventCode + '\'' + | ||
| ", label='" + label + '\'' + | ||
| ", description='" + description + '\'' + | ||
| '}'; |
There was a problem hiding this comment.
Lets add sampleEventTemplate also in this method.
There was a problem hiding this comment.
well it's base64 encoded, so it won't help much in a toString() method
The expected `workspace` entries vary from one service to the next, but to follow your advise, for one common validation paradigm, I moved the validation at the service constructor level, wdyt ?
…void any conflicts with other system variables
Issues :
events_mgmt: addAdobe I/O EventsRegistration API wrappers #6coreuse a common prefix for the expected env. vars #9Description :
coreevents_mgmtPOST,GET,DELETERegistration API endpoints)