1. Is there another authentication way than Basic Auth.? If so, which one and how can I apply this?
2. Why is it possible to filter by $select, $filter and $orderby separate but not with a combination of these?
3. Why is the $top=10 parameter allowed on a table but not on a view?
4. How can I track down the cause of a problem when the system returns a particular HTTP error code (like the 500 internal server error)? I’m aware of the subfolder Logs from Indicium on the (web)server. Are there any other methods to tackle this problem?
5. Is it possible to request both master and detail records (like organisation and contact) in one response?
6. A few parties where we’d make a connection with would desire a result that is an API call “plain” JSON. The result of Indicum contains some kind of header (doubtless OData standard):
Is it possible to convert this result into “plain” JSON?
7. Currently, I’m testing this with the Postman tool. Are there any better alternatives, or is this one fine?
Best answer by Vincent DoppenbergView original
Here are the answers to your questions;
1. Currently, HTTP Basic Authentication is the only supported way of authentication. But this must be seen as a way to provide login data to Indicium. Indicium already supports Windows, RDBMS and IAM authentication after all. These all run by the HTTP Basic Authentication standard. The common disadvantage for HTTP Basic Authentication is that this is unencrypted. However, it’s fully possible to flare this disadvantage by using HTTPS, which we recommend our customers. We are currently working on an authentication in Indicium; so if you have a specific user case where Indicium is failing short at the moment, I’d like to here that. Maybe I can come up with an alternative or take this into account when developing.
2. The $select, $filter, $orderby parameters are only allowed to occur once. It’s possible to do OR-Conditions, which would be difficult with two $filter parameters.
3. Indicium doesn’t distinguish between tables and views. The $top=10 parameters should work on both, so I don’t think that’s causing the problem. The most obvious reason for the ‘500 internal server error’ would be that the view itself is causing an SQL error. Check out point 4 to find out whether this is true.
4. Most of the ‘500 internal server errors’ are caused by the database. Mostly because of a lack of rights or because of an SQL code that’s generating an error. Indicium only sends errors (and info messages) that have to do with the database and returns them using a TSFMessage header in the response. This header can contain several messages that are base64 encoded .
For security reasons, Indicium will only show errors in the development environment and not in the production environment. In the production environment, they will be replaced by ‘unknown error’. Indicium can be configured to run in a development environment by replacing the following line:
I will be expanding the documentation soon to cover this point.
5. No, you will need a second request for that.
6. Yes, upward of release 2018.1.4 of Indicium, this will be possible by adding the following request header:
7. Postman is a fine tool to test Indicium. I commonly use Insomnia myself. Both tools have comparable sets of features, but I prefer the interface of Insomnia.
Does this answer all your questions?
Thank you for your clear explanation!
I’m especially glad with your answer to question 6 and that this will be implemented in version 2018.1.4. Could you tell me when this version of Indicium will be released?
About the first question; I don’t have a very specific user case or wishes. I asked you because Basic Authentication is very basic. One of the external parties once asked be if OAuth 2.0 is supported but to be honest, I’m not sure what that specifically means.
I’m very happy with Indicium. I’ve been testing it for all while and I think it is really promising. This will give us a lot of new possibilities in our application.
Thanks again for the explanation,
Johan van Eijsden
In the meantime, version Indicium 2018.1.5 is released. For your info; two small issues are solved that were in the previous version. You’ll probably won’t encounter these, since they are both rare.
One last question about Indicium.
By adding the request header key:
I’ve managed to get back “plain” JSON:
but the API that we are communicating with expects the following:
How is this done?
The wrapper object with the "value" property is part of the OData standard and we cannot return a data set without it.
What the API expects is the value of the "value" property from the response given by Indicium. What you could do is extract this value from the response and send it to the API, instead of the entire response.