You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Dec 11, 2021. It is now read-only.
To allow for a clean move, look for a way to forward requests that do not match any defined endpoint to another API.
In our case, this will be used to forward requests that do not have an implementation on the new API to the old Django-based API, and incrementally port features over.
The text was updated successfully, but these errors were encountered:
This adds a new endpoint handler using the `path` converter in order to match
requests directed to any subtree. As long as this endpoint is the last to be
included in the router, all requests not matching defined routes under the
`/api` endpoint will be forwarded to the old API.
Two new settings are added for this. One is the endpoint of the old API to
forward to, which may change in the future due to the pending subdomain removal
pull request. The other is the API token to use for the new API authenticating
with the old API: Whilst everything else sent by the client is forwarded to the
old API, the authorization schemes between the new and old API differ.
The entire point behind this functionality is to allow us to incrementally port
over endpoints to the new API, whilst reconfiguring clients to use the new API
completely.
Closes#8.
To allow for a clean move, look for a way to forward requests that do not match any defined endpoint to another API.
In our case, this will be used to forward requests that do not have an implementation on the new API to the old Django-based API, and incrementally port features over.
The text was updated successfully, but these errors were encountered: