CPS-322 - Getting issue details... STATUS
Currently there is no validation within CPS for names/ID's. Meaning that there is no restrictions to what the following can be named
- Dataspaces
- Schema-Sets
- Anchors
- CM-handles
- CM-Handle Properties.
Open Issues
- What kind of naming validation should be in place?
- According to this ONAP Documentation it should be alphanumeric with underscores(_) VNF and PNF Modeling Requirements - Resource IDs
- Should CM-Handle ID's be more strict, or carry the same amount of strictness as anchor names. Due to the fact that we create a corresponding anchor for every CM-Handle it cannot be less strict.
- Should validation also be applied to Get/Query API's as opposed to just creation of the functions above? (Not recommended as this will add little value, at a high cost)
- Should dashes be included? A lot of dummy data and tests within CPS use dashes as part of their Network Function ID's. If we decide to not use dashes, we should also change these.
Implementation Proposals
At CPS's service layer within the the Java API:
- Use general regex for String validation.
- Use Spring validator.
- Throw Data Validation Exception(BAD_REQUEST 400 Error Code) on invalid ID's.
- If same rules apply for anchor as CM-Handle ID, throw the exception when creating the anchor (Current code will have to be refactored to accomplish this, as CM-Handle is registered before Anchor is created).
- Or, CPS-Core will expose a new java interface to check if anchor name is valid when registering a CM-Handle.