We have a number of paths in our API which we dont want included in the OpenAPI, because they are not used at the moment, and also because they are causing drf-spectacular to get confused about serializers.
The primary example is /oscarapi/admin which has a different set of objects with similar names as those under /oscarapi, because they are the 'admin' views of those objects with more details and write support. We anticipate having a different frontend app for the admins, and expose that as a separate OpenAPI. Not looking for any support wrt the second OpenAPI - it is moderately easy to do a second view with a fake filtered URLConf. I can (and am) also creating a specialised URLConf for the main API, but this is a bit more annoying because it is "almost everything except a few things" which IMO should be easy, and I suspect others would benefit from it, and not need to resort to my tom-foolery-approach.
We have a number of paths in our API which we dont want included in the OpenAPI, because they are not used at the moment, and also because they are causing drf-spectacular to get confused about serializers.
The primary example is
/oscarapi/adminwhich has a different set of objects with similar names as those under/oscarapi, because they are the 'admin' views of those objects with more details and write support. We anticipate having a different frontend app for the admins, and expose that as a separate OpenAPI. Not looking for any support wrt the second OpenAPI - it is moderately easy to do a second view with a fake filtered URLConf. I can (and am) also creating a specialised URLConf for the main API, but this is a bit more annoying because it is "almost everything except a few things" which IMO should be easy, and I suspect others would benefit from it, and not need to resort to my tom-foolery-approach.