[3670] API Generation #285
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
ghost
changed the title
More api generation wip
Work in Progress, add mimeType/contentType processing.
Update RPC OpenAPI generation
The OpenAPIv3 requires the "info" with "title" and "version". This provides a temporary hardcoded values for these and I plan on having a discussion on what to do in this regard. Utilize the Mockito ArgumentMatcher API to write a custom test for ensuring that the generated JSON and YAML OpenAPI Specs match pre-defined expecations. The REST is stubbed out but not implemented within the scope of this commit.
It just occurred to me that this seems silly. We are testing against the OpenAPI class and so the source data to compare against only needs to be in a single type. I chose json over yaml. Change the behavior of the program to just use a single test file for each expected response.
This got lost somewhere along the way. Add it back.
There are some significant problems that are exposed and need to be investigated. These are causing different kinds of failures (test failures and non-test failures that result in bad API).
3670 rest docs wip
…ect/Vitro into 3670-rest-docs
ghost
marked this pull request as ready for review
Alternate variation on getting the version.
chenejac
approved these changes
Mar 11, 2022
api/src/main/java/edu/cornell/mannlib/vitro/webapp/dynapi/DynamicAPIDocumentation.java
Outdated
Show resolved
Hide resolved
| Operation operation = new Operation(); | ||
| operation.addTagsItem(tag.getName()); | ||
|
|
||
| // No description available per resource API rpc |
There was a problem hiding this comment.
Maybe it doesn't not exist in examples, but I believe it is allowed to be added in accordance with the ontology: https://github.com/vivo-project/Vitro/blob/sprint-dynapi-2022-feb-staging/home/src/main/resources/rdf/tbox/filegraph/vitro-dynamic-api.owl#L441
There was a problem hiding this comment.
No description referenced in Java class.
There was a problem hiding this comment.
Actually, it should be added to https://github.com/vivo-project/Vitro/blob/sprint-dynapi-2022-feb-staging/api/src/main/java/edu/cornell/mannlib/vitro/webapp/dynapi/components/RPC.java, right? We need separated description for PUT, POST, GET and DELETE methods? Anyway, it is not there, and I will add it in the separated PR.
api/src/main/java/edu/cornell/mannlib/vitro/webapp/dynapi/DynamicAPIDocumentation.java
Outdated
Show resolved
Hide resolved
api/src/main/java/edu/cornell/mannlib/vitro/webapp/dynapi/DynamicAPIDocumentation.java
Outdated
Show resolved
Hide resolved
api/src/main/java/edu/cornell/mannlib/vitro/webapp/dynapi/request/ApiRequestPath.java
Outdated
Show resolved
Hide resolved
api/src/main/java/edu/cornell/mannlib/vitro/webapp/dynapi/request/DocsRequestPath.java
Show resolved
Hide resolved
chenejac
approved these changes
Mar 12, 2022
chenejac
requested changes
Mar 21, 2022
api/src/main/java/edu/cornell/mannlib/vitro/webapp/dynapi/DynamicAPIDocumentation.java
Show resolved
Hide resolved
chenejac
approved these changes
Mar 25, 2022
litvinovg
added a commit
to litvinovg/Vitro
that referenced
this pull request
Jun 30, 2023
* api generation wip * More api generation wip * Work in Progress, add mimeType/contentType processing. * update rpc endpoint generation * Implement Argument Matcher and test the OpenAPI documentation for RPC. The OpenAPIv3 requires the "info" with "title" and "version". This provides a temporary hardcoded values for these and I plan on having a discussion on what to do in this regard. Utilize the Mockito ArgumentMatcher API to write a custom test for ensuring that the generated JSON and YAML OpenAPI Specs match pre-defined expecations. The REST is stubbed out but not implemented within the scope of this commit. * Only a single type of test data is needed. It just occurred to me that this seems silly. We are testing against the OpenAPI class and so the source data to compare against only needs to be in a single type. I chose json over yaml. Change the behavior of the program to just use a single test file for each expected response. * Add comments to the requests() function for generating parameters. This got lost somewhere along the way. Add it back. * Work In Progress. There are some significant problems that are exposed and need to be investigated. These are causing different kinds of failures (test failures and non-test failures that result in bad API). * revert change to versioned pool and correct expected data * update tag name with key and expected results * fix duplicate resource api * update operation date * cleanup testing n3 * update test expected results * assert version 4 test api * generate custom rest action api * refactor integration test classes * return first step required params * Alternate variation on getting the version. * align resource id constant * initialize dynamic api documentation * minor comment updates * downgrade swagger-core to attempt resolve jackson version conflicts * fix: use /api prefix for api documentation * fix: added onGetAll object property * fix: test n3 data Co-authored-by: Kevin Day <kday@library.tamu.edu> Co-authored-by: Kevin Day <35114839+kaladay@users.noreply.github.com> Co-authored-by: Georgy Litvinov <git@litvinovg.pro>
litvinovg
added a commit
to litvinovg/Vitro
that referenced
this pull request
Jul 6, 2023
* api generation wip * More api generation wip * Work in Progress, add mimeType/contentType processing. * update rpc endpoint generation * Implement Argument Matcher and test the OpenAPI documentation for RPC. The OpenAPIv3 requires the "info" with "title" and "version". This provides a temporary hardcoded values for these and I plan on having a discussion on what to do in this regard. Utilize the Mockito ArgumentMatcher API to write a custom test for ensuring that the generated JSON and YAML OpenAPI Specs match pre-defined expecations. The REST is stubbed out but not implemented within the scope of this commit. * Only a single type of test data is needed. It just occurred to me that this seems silly. We are testing against the OpenAPI class and so the source data to compare against only needs to be in a single type. I chose json over yaml. Change the behavior of the program to just use a single test file for each expected response. * Add comments to the requests() function for generating parameters. This got lost somewhere along the way. Add it back. * Work In Progress. There are some significant problems that are exposed and need to be investigated. These are causing different kinds of failures (test failures and non-test failures that result in bad API). * revert change to versioned pool and correct expected data * update tag name with key and expected results * fix duplicate resource api * update operation date * cleanup testing n3 * update test expected results * assert version 4 test api * generate custom rest action api * refactor integration test classes * return first step required params * Alternate variation on getting the version. * align resource id constant * initialize dynamic api documentation * minor comment updates * downgrade swagger-core to attempt resolve jackson version conflicts * fix: use /api prefix for api documentation * fix: added onGetAll object property * fix: test n3 data Co-authored-by: Kevin Day <kday@library.tamu.edu> Co-authored-by: Kevin Day <35114839+kaladay@users.noreply.github.com> Co-authored-by: Georgy Litvinov <git@litvinovg.pro>
litvinovg
added a commit
to litvinovg/Vitro
that referenced
this pull request
Mar 7, 2024
* api generation wip * More api generation wip * Work in Progress, add mimeType/contentType processing. * update rpc endpoint generation * Implement Argument Matcher and test the OpenAPI documentation for RPC. The OpenAPIv3 requires the "info" with "title" and "version". This provides a temporary hardcoded values for these and I plan on having a discussion on what to do in this regard. Utilize the Mockito ArgumentMatcher API to write a custom test for ensuring that the generated JSON and YAML OpenAPI Specs match pre-defined expecations. The REST is stubbed out but not implemented within the scope of this commit. * Only a single type of test data is needed. It just occurred to me that this seems silly. We are testing against the OpenAPI class and so the source data to compare against only needs to be in a single type. I chose json over yaml. Change the behavior of the program to just use a single test file for each expected response. * Add comments to the requests() function for generating parameters. This got lost somewhere along the way. Add it back. * Work In Progress. There are some significant problems that are exposed and need to be investigated. These are causing different kinds of failures (test failures and non-test failures that result in bad API). * revert change to versioned pool and correct expected data * update tag name with key and expected results * fix duplicate resource api * update operation date * cleanup testing n3 * update test expected results * assert version 4 test api * generate custom rest action api * refactor integration test classes * return first step required params * Alternate variation on getting the version. * align resource id constant * initialize dynamic api documentation * minor comment updates * downgrade swagger-core to attempt resolve jackson version conflicts * fix: use /api prefix for api documentation * fix: added onGetAll object property * fix: test n3 data Co-authored-by: Kevin Day <kday@library.tamu.edu> Co-authored-by: Kevin Day <35114839+kaladay@users.noreply.github.com> Co-authored-by: Georgy Litvinov <git@litvinovg.pro>
litvinovg
added a commit
to litvinovg/Vitro
that referenced
this pull request
Mar 8, 2024
* api generation wip * More api generation wip * Work in Progress, add mimeType/contentType processing. * update rpc endpoint generation * Implement Argument Matcher and test the OpenAPI documentation for RPC. The OpenAPIv3 requires the "info" with "title" and "version". This provides a temporary hardcoded values for these and I plan on having a discussion on what to do in this regard. Utilize the Mockito ArgumentMatcher API to write a custom test for ensuring that the generated JSON and YAML OpenAPI Specs match pre-defined expecations. The REST is stubbed out but not implemented within the scope of this commit. * Only a single type of test data is needed. It just occurred to me that this seems silly. We are testing against the OpenAPI class and so the source data to compare against only needs to be in a single type. I chose json over yaml. Change the behavior of the program to just use a single test file for each expected response. * Add comments to the requests() function for generating parameters. This got lost somewhere along the way. Add it back. * Work In Progress. There are some significant problems that are exposed and need to be investigated. These are causing different kinds of failures (test failures and non-test failures that result in bad API). * revert change to versioned pool and correct expected data * update tag name with key and expected results * fix duplicate resource api * update operation date * cleanup testing n3 * update test expected results * assert version 4 test api * generate custom rest action api * refactor integration test classes * return first step required params * Alternate variation on getting the version. * align resource id constant * initialize dynamic api documentation * minor comment updates * downgrade swagger-core to attempt resolve jackson version conflicts * fix: use /api prefix for api documentation * fix: added onGetAll object property * fix: test n3 data Co-authored-by: Kevin Day <kday@library.tamu.edu> Co-authored-by: Kevin Day <35114839+kaladay@users.noreply.github.com> Co-authored-by: Georgy Litvinov <git@litvinovg.pro>
litvinovg
added a commit
that referenced
this pull request
Apr 19, 2024
* api generation wip * More api generation wip * Work in Progress, add mimeType/contentType processing. * update rpc endpoint generation * Implement Argument Matcher and test the OpenAPI documentation for RPC. The OpenAPIv3 requires the "info" with "title" and "version". This provides a temporary hardcoded values for these and I plan on having a discussion on what to do in this regard. Utilize the Mockito ArgumentMatcher API to write a custom test for ensuring that the generated JSON and YAML OpenAPI Specs match pre-defined expecations. The REST is stubbed out but not implemented within the scope of this commit. * Only a single type of test data is needed. It just occurred to me that this seems silly. We are testing against the OpenAPI class and so the source data to compare against only needs to be in a single type. I chose json over yaml. Change the behavior of the program to just use a single test file for each expected response. * Add comments to the requests() function for generating parameters. This got lost somewhere along the way. Add it back. * Work In Progress. There are some significant problems that are exposed and need to be investigated. These are causing different kinds of failures (test failures and non-test failures that result in bad API). * revert change to versioned pool and correct expected data * update tag name with key and expected results * fix duplicate resource api * update operation date * cleanup testing n3 * update test expected results * assert version 4 test api * generate custom rest action api * refactor integration test classes * return first step required params * Alternate variation on getting the version. * align resource id constant * initialize dynamic api documentation * minor comment updates * downgrade swagger-core to attempt resolve jackson version conflicts * fix: use /api prefix for api documentation * fix: added onGetAll object property * fix: test n3 data Co-authored-by: Kevin Day <kday@library.tamu.edu> Co-authored-by: Kevin Day <35114839+kaladay@users.noreply.github.com> Co-authored-by: Georgy Litvinov <git@litvinovg.pro>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
VIVO GitHub issue:
vivo-project/VIVO#3670
vivo-project/VIVO#3677
What does this pull request do?
Create endpoints to generate OpenAPI specifications for an entire REST version, specific REST resource, all custom actions, or specific custom action as either application/yaml or application/json.
All REST yaml
https://editor.swagger.io/?url=https://gist.githubusercontent.com/wwelling/98775eeb6cac7c98fa90b24316d30711/raw/8a46f2e11d0f246957212f3b2e9cf079340ee1bb/vivo-generated-rest-api.yaml
All RPC yaml
https://editor.swagger.io/?url=https://gist.githubusercontent.com/wwelling/4109bfcc8d9cc6f10fcdcd983cc055d4/raw/509ea688227787e4513d36defc1b1e0db3a77ad9/vivo-generated-rpc-api.yaml
Single REST resource json
https://editor.swagger.io/?url=https://gist.githubusercontent.com/wwelling/76b5b2b7abb9d53137afbf684bcb803b/raw/997a393374f143f5711bdb62c131ce947d5cc830/test_person_resource.json
Single RPC action json
https://editor.swagger.io/?url=https://gist.githubusercontent.com/wwelling/b762b8ba097eb5fe96034c302a4e0c56/raw/39aad70e3353944e2e5d39e6f69c574dfd86d8f2/test_action.json
What it is not doing
Interested parties
Tag (@ mention) interested parties or, if unsure, @VIVO-project/vivo-committers