It should be possible to create two APIs with same urls_namespace

[anentropic]

Django url namespaces are hierarchical rather than a flat global namespace.

Currently there is some validation to prevent creating two Ninja APIs with the same urls_namespace:

  File "/home/circleci/project/.venv/lib/python3.11/site-packages/ninja/main.py", line 436, in urls
    self._validate()
  File "/home/circleci/project/.venv/lib/python3.11/site-packages/ninja/main.py", line 577, in _validate
    raise ConfigError(msg.strip())
ninja.errors.ConfigError: Looks like you created multiple NinjaAPIs or TestClients
To let ninja distinguish them you need to set either unique version or urls_namespace
 - NinjaAPI(..., version='2.0.0')
 - NinjaAPI(..., urls_namespace='otherapi')
Already registered: ['reports']

But this seems like a mis-feature, because these APIs may be loaded into Django urlconf under different parent namespaces.

Relates to #1593

django-ninja/ninja/main.py

Lines 562 to 578 in e5806ca

	def _validate(self) -> None:
	# urls namespacing validation
	skip_registry = os.environ.get("NINJA_SKIP_REGISTRY", False)
	if (
	not skip_registry
	and self.urls_namespace in NinjaAPI._registry
	and not debug_server_url_reimport()
	):
	msg = f"""
	Looks like you created multiple NinjaAPIs or TestClients
	To let ninja distinguish them you need to set either unique version or urls_namespace
	- NinjaAPI(..., version='2.0.0')
	- NinjaAPI(..., urls_namespace='otherapi')
	Already registered: {NinjaAPI._registry}
	"""
	raise ConfigError(msg.strip())
	NinjaAPI._registry.append(self.urls_namespace)

django-ninja/ninja/main.py

Lines 428 to 442 in e5806ca

	def urls(self) -> Tuple[List[Union[URLResolver, URLPattern]], str, str]:
	"""
	str: URL configuration
	Returns:
	Django URL configuration
	"""
	self._validate()
	return (
	self._get_urls(),
	"ninja",
	self.urls_namespace.split(":")[-1],
	# ^ if api included into nested urls, we only care about last bit here
	)

The registry itself doesn't seem to serve any other purpose except prevent people from creating APIs with same namespace (?) ... but I don't think this should be disallowed in the first place?

[anentropic]

For example, this makes it awkward to use same/similar API defs under different app names

(In my case I am also using django-ninja-extra class-based API Controller to have code reuse between similar views in different apps)

[anentropic]

as a compromise it could be nice if NINJA_SKIP_REGISTRY flag was read from Django settings instead of raw env var

[vitalik]

@anentropic you can just use Router instead of NinjaAPI ?

api1 = Router()
...

api2 = Router()


api_root = NinjaAPI()
api_root.add_router(api1)
api_root.add_router(api2)

or am my missing something ?

[anentropic]

I see

I'm not sure that is possible with django-ninja-extra

They have:

from ninja_extra import NinjaExtraAPI

api = NinjaExtraAPI()

api.register_controllers(MyAPIController, MyAPIController2, ...)

where the APIController is the class-based view abstraction that sort of behaves as a router to NinjaAPI, but it lacks the ability to have nested controllers (routers)

But also I don't want to have a single root API that owns a whole path hierarchy, I want to be able to attach APIs into an existing path hierarchy alongside other Django views

Even if it's a bit niche, I feel like this should be possible? The restriction seems unnecessary

[vitalik]

Well there is a planned rework on routers are planned which should allow same urls merging - but not sure yet about timing

as of now looks like the only option is give these API different url namespaces

maybe you can also play a bit with this method to give some different names or something:

django-ninja/ninja/main.py

Line 502 in 9b7c4f1

def get_operation_url_name(self, operation: "Operation", router: Router) -> str:

[anentropic]

To let ninja distinguish them you need to set either unique version or urls_namespace

Is there actually any place where Ninja needs to distinguish them?

[vitalik]

Is there actually any place where Ninja needs to distinguish them?

/docs view - it's a named <namespace>:docs-root

and as well openapi.json view

[anentropic]

ah I see, they don't currently handle mounting the API at a non-root url namespace

so a full solution would allow for them to be relative to the API wherever it was mounted