Update API spec to OpenAPI version 3.0.2

[carueda]

The one currently used is old.

Related: #24

@lewismc fyi a we just talked about as part of the corpy wrapper and your pyldn work.

[lewismc]

yes @carueda I think this may even be the source of some of our issues with corpy. I'll see if I get some time to dig into this.

[carueda]

@lewismc Lewis, as you may have already noted from #24, the spec is currently manually edited. So, assuming a similar "approach", the idea would be to load http://cor.esipfed.org/ontapi/swagger_cor.yaml into http://editor.swagger.io/ and start by changing the first line from swagger: '2.0' to openapi: '3.0.0', and dealing with the reported errors. Not sure how effective this strategy would be. Thanks for trying!

[lewismc]

OK @carueda I'm going to work on it right now.

[lewismc]

Hi @carueda I have an openapi 3.0.2-compliant yaml version of the ORR API available. I am not sure where to send the pull request though. The swagger.yaml in this repository is out of date (should we delete it?) The MMI version is specific of course to MMI.
Then of course we have the COR version. Where is this served from and where is it in source code management? Where should we keep the COR version?
My feeling is that the core openapi document should be maintained within a repository under the MMI Org. We can then pull from it and edit it as necessary for other deployments of ORR. Does this make sense?

[carueda]

@lewismc good point ... Although this of course should at some point be re-integrated here in the backend service repo, what about committing your updated spec to https://github.com/mmisw/mmiorr-docs/ (where the currently "manually" edited spec is located: https://github.com/mmisw/mmiorr-docs/blob/master/docs/swagger.yaml) ?

(then we can work together to copy it to the right location under the COR instance.)