refactor: reimplement rpcapi in DRF #9073
Open
Conversation
This file contains hidden or 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
Changes th 10000 e interface to return a list of Persons instead of a map from ID to name.
Gets turned into a literal nul somewhere in the process of generating a schema and building a Python client for purple. This has the same effect but avoids the nul.
Side effect is that the purple API client is named PurpleApi instead of RpcApi.
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.
This reimplements the API in
api/views_rpc.pyusing django-rest-framework instead of custom views. Removes therpcapi.yamlfile.The API spec is now generated by running
ietf/manage.py spectacular --file rpcapi.yaml. This generates the complete DRF schema, which includes both the red and purple APIs. These include tags in the schema that separate the PurpleApi from the RedApi.A few changes were made to the API to make serialization easier. Notably
/api/purple/...instead of/api/rpc/...{"something": [<array of things]}now just return the bare array without the wrappingThere will be a corresponding PR on ietf-tools/purple that makes the necessary adjustments to work with this. Local testing shows it at least mostly works. I have not test with the rfced-xfer process, but checked fairly carefully that the APIs created for that process return the same results as before.
Several bits of CI / dev gearing expect to fetch the
rpcapi.yamlfile from git - we'll need to refactor those to create or find another way to manage that spec. We've already worked around this for the RedApi.Important note: this makes a slight change to the validation on
DocumentInfo.title, which is way out of scope. The reason for this is that the oldvalidate_no_control_charsvalidator includes a regex with\x00in it. This escaped NUL char is turned into a literal NUL char somewhere on the way into purple's API client, resulting in python source with an invalid character in it. The change here replaces that\x00with a\0x1and adds aProhibitNullCharactersValidatorto thetitlefield which is the only place this validator is used. This adds a book-keeping migration.