v1 (RC Core) <> v2 API Mapping (OpenAPI)

[techsavvyash]

POA

1. Map v1 to v2 Mapping Doc
2. Setup Sunbird RC locally
3. Write modules to internally call v1 APIs for v2 APIs (Dev)
4. Make the system generic to use: i. Existing RC is deployed. and we need to add v2 APIs on top of it: Then we seed the existing data, i.e. generate DIDs for the existing entities in v1 (RC Core)
5. Migration Strategy (if required)' i. Script to migrate credentials from postgres to registry when moving to registry from postgres ii. Script to convert credential schemas to registry entity JSON
6. Unit testing the modules

Usage Scenarios

Fresh Setup

1. Setup a fresh instance of v1 (refer sunbird docs)
2. Setup a fresh instance of v2 (refer ULP/RCW docs )
3. Setup a fresh instance of v1 + v2
   1. use registry
   2. use registry + postgres

Migration

1. Integrate v2 in existing v1
2. Integrate v1 in existing v2

Open Questions

1. Are we supporting migration from v2 to v1, i.e. v2 is deployed using postgres as database and someone wants to add RC on top of it, are we supporting that, if yes then what is the migration step? Think Yes, that is why we are mapping this. What will be the migration strategy then?

   • Suggest users on how can they do this?

2. How to deal with schemas for entities? i. Do we have to create a script to generate entity schema () based on credential schema?

3. How to map DIDs with Entity type?

4. Who is going to create the Schemas for entities? Will the user will write does jsons? will we do it? Can we do something like create an NPM package of basic schemas and anything on top of that needs to be handled by the user manually as a config param?

5. What of the already existing credentials that are present in the registry for someone using v1 APIs and migrating to v2, do we resign the credentials present in the registry using v2 APIs?

6. Give an idea on the overall migration strategy.