@@ -21,3 +21,26 @@ When starting a [Light host component](/implementation/Light-host-walkthrough) i
Even without the prefix, the path is different.
In conclusion, this registry probably could work as a substitute for the BaSyx registry but not without changing basically every route in the REST API.
TODO: Test if the HTTP PUT body is even usable by taking and pushing it manually.
## [SAP/i40-aas](https://github.com/SAP/i40-aas)
SAP also has a framework which also is already talked about in the [initial considerations](/initial-considerations/Deciding-on-a-framework#deciding-with-which-frameworks-to-continue).
As one of the key points, SAP states the framework "Provide[s] registry and discovery services".
The documentation is pretty good in technical terms but hard to navigate.
After "installing" it (which just runs a `docker-compose` stack) everything seems to be up and running.
There are logs in the console and running `sudo lsof -i -P -n | grep LISTEN` shows that docker is listening on all the ports that are configured in the `.env` file in the repository.
But for some reason, every connection to any service returned an empty response.
Turns out, the browsers' default is to not use HTTPS on local connection, which normally is fine, but the `i40-aas` service only serves on HTTPS using a self-signed certificate, you have to explicitly trust in the browser.
[`https://localhost:4401/index.html`](https://localhost:4401/index.html) is the "endpoint-registry-ui" which is where you can see the registered endpoints - so it's a UI for the registry.
You can even add new descriptors by hand.
How we can use the registry endpoints programmatically is described in the [endpoint-registry documentation](https://github.com/SAP/i40-aas/blob/master/docs/markdown/endpoint-registry.md).
And here we see: The routes are very different again.
They neither match the BaSyx registry nor the python-aas-registry.
