The new keys which now work with OData if you select that option in the APIkeys section.
And we can use those through the Otto proxy by just adding /otto into the path - and that works all beautifully, Thanks. Am interested in understanding the performance implications. My tests indicate about a 30ms penalty (a combination of 5-6ms for going through th proxy and the rest of using the Bearer rather than Basic method)
Just to confirm this key will ONLY work on the file that the key is for, so the higher level query to /$metadata can not be used to find out everything about the system but only the field names for that file??
Yes there will be a slight penalty going through the proxy. The bearer token looks up the creds from the db and the proxies the request, so that will take some time. But the DB is sqlite, which blazing fast and everything is on the same machine so there shouldn’t be much network impact.
The /$metadata endpoint is already file-specific, so I imagine that will work via the proxy, but I’m not sure if that endpoint provides information about schema from other files or not (i.e. external file references)
server/fmi/odata/v4/$metadata works with a Basic auth
server/otto/fmi/odata/v4/$metadata does not with this key (because the key is for A file)
The first gives you all the tables, all the fields, and some other interesting metadata (especially if you return it as XML)
Are you getting the “Api Key is not for the given database” error in the 401 that is returned when you try to use the API key with the metadata endpoint?
I think I can fix this in our next version, its due to how we’re parsing the database out of the url.