joData does not support query urls that have parameters

[asmarkis]

I did a lot of research on what developers prefer and are saying about the oData standard. It seems like some feel that oData encourages leaky abstraction, which is not the best design principle.

I was looking through joData to see if there was any functionality that could add parameters to the query outside of oData. Either I couldn't find a proper way to do this, or it seems like it is unsupported.

For example, if I want to filter a query on: /odata/EntityTables

Like so: /odata/EntityTables?$filter=id eq 10

But have a parameter: /odata/EntityTables?type=1&$filter=id eq 10

With joData, it will result in the incorrect uri: /odata/EntityTables?type=1?$filter=id eq 10

So, the current workaround that I am using for this problem is adding the normal parameters on after the jodata filtering, which works, but is not ideal: jodatauri = /odata/EntityTables?$filterTables?$filter=id eq 10 get(jodatauri.toString() + "&type=1");

Am I missing something, or is there missing functionality?

[druttka]

It's been a long time since I looked at this project, and it looks like it has even evolved since the last time I did. The readme seems to indicate that custom query options are not currently supported.

I could imagine something like joData.raw('type=1') might be an interesting enhancement to support a scenario of adding any additional parameters to the generated query.

[druttka]

As I thought about it more, what is this type parameter? Is it not something that could be part of a filter expression?

[druttka]

One final thought. joData could look at the base to see if it already contains a ?, in which case it could use a leading & instead. Note that these comments were quite off-the-cuff and, again, based on a fairly outdated memory of what joData is doing =)

[asmarkis]

My "type" was an example parameter. So, "?exampleparameter=9000" would be part of the query but not part of the OData query parameters, for example.

Why I brought up "Leaky Abstraction" is because of the concern for the OData standard and its support in the long term. If you were to migrate the API to a different platform, these 'custom' parameters would still work, but 'OData' ones may not. You also don't want the applications to do their own query logic, the API should handle that, and the client should simply request the different commands the API is meant to support ;) So, yes, "?$filter=type eq 1 " would work as well, but maybe it is a parameter I want the API to require.

joData.raw('type=1') sounds like a good feature, but I think checking for an existing '?' after the final slash might also be good in the compatibility sense.

Thanks for the quick replies and insight on this issue!