I have created an OData Web API but I am having problems looking up data where the primary key contains a forward slash.
This url returns data as expected:
/api/SalesOrders('12345')
But this one with the forward slash in the key fails:
/api/SalesOrders('12345/1')
Even when encoded:
/api/SalesOrders('12345%2F1')
In the error presented (see below), it looks like the final forward slash is being converted to a backslash as you would expect because it is part of the url and not in the query string:
If I use the following url instead, where the forward slash is in the querystring, then the data is returned correctly:
/api/SalesOrders?$filter=SalesOrderNumber eq 12345/1
If I were generating the urls myself, this wouldn't be much of an issue.
However, I am using the OData v4 Client Code Generator
So the call in code actually looks like this:
var salesOrder = erpClient.SalesOrders.ByKey(worksOrder.SalesOrderNumber).GetValue();
This generates the url which contains the forward slash before the query string and thus fails.
I can work around this by forcing the forward slash into the querystring as follows:
var salesOrder = erpClient.SalesOrders.Where(so => so.SalesOrderNumber == "12345/1" && so.SalesOrderNumber == so.SalesOrderNumber).FirstOrDefault();
This forces the forward slash into the querystring:
/api/SalesOrders?$filter=SalesOrderNumber eq '450993/1' and SalesOrderNumber eq SalesOrderNumber
This feels messy and I would like to avoid moving away from the OData v4 Client as we have several apps that already use it.
Is there anything else I can do to make this work a little neater?
Footnote:
I followed the process on this blog to handle special characters, but this does not include advice on how to handle the forward slash:
Take a look at the ODataPathAndSlashEscapeSample on Github. The basic idea is to subclass DefaultODataPathHandler and override the Parse
method. Then provide an instance of your custom path handler to the MapODataServiceRoute method in your Web API configuration code.