1

OData Web API を作成しましたが、主キーにスラッシュが含まれているデータの検索に問題があります。

この URL は期待どおりにデータを返します:
/api/SalesOrders('12345')

ただし、キーにスラッシュが含まれているものは失敗します:
/api/SalesOrders('12345/1')
エンコードされている場合でも:
/api/SalesOrders('12345%2F1')

表示されたエラー (以下を参照) では、最後のスラッシュがクエリ文字列ではなく URL の一部であるため、予想どおりバックスラッシュに変換されているように見えます。

ここに画像の説明を入力

代わりに、スラッシュがクエリ文字列にある次の URL を使用すると、データが正しく返されます:
/api/SalesOrders?$filter=SalesOrderNumber eq 12345/1

自分で URL を生成していた場合、これは大きな問題にはなりません。
ただし、OData v4 Client Code Generatorを使用しています

したがって、コード内の呼び出しは実際には次のようになります。

var salesOrder = erpClient.SalesOrders.ByKey(worksOrder.SalesOrderNumber).GetValue();

これにより、クエリ文字列の前にスラッシュを含む URL が生成されるため、失敗します。

  1. これは OData v4 クライアントの既知の問題ですか?
  2. 主キー タイプの呼び出しでクエリ文字列の使用を強制する設定はありますか?

次のようにスラッシュをクエリ文字列に強制することで、これを回避できます。

var salesOrder = erpClient.SalesOrders.Where(so => so.SalesOrderNumber == "12345/1" && so.SalesOrderNumber == so.SalesOrderNumber).FirstOrDefault();

これにより、スラッシュがクエリ文字列に強制的に挿入されます:
/api/SalesOrders?$filter=SalesOrderNumber eq '450993/1' and SalesOrderNumber eq SalesOrderNumber

これは面倒です。OData v4 クライアントを使用しているアプリがいくつかあるため、OData v4 クライアントから離れることは避けたいと思います。

この作業をもう少しきれいにするために他にできることはありますか?

脚注：

このブログのプロセスに従って特殊文字を処理しましたが、スラッシュの処理方法に関するアドバイスは含まれていません。

using-wcf-data-service-with-restricted-characters-as-keys

4

3 に答える 3

2

GithubのODataPathAndSlashEscapeSampleを見てください。基本的な考え方は、DefaultODataPathHandlerをサブクラス化し、メソッドをオーバーライドするParseことです。次に、カスタム パス ハンドラーのインスタンスをWeb API 構成コードのMapODataServiceRouteメソッドに提供します。

于 2016-02-16T05:43:43.200 に答える
2

これは、「ODataルーティング」セクションのすぐ下にある同様のソリューションを探している人に役立つかもしれません...

...このエラーを回避するには、クライアントでスラッシュ (%252F) とバックスラッシュ (%255C) に二重のエスケープ シーケンスを使用する必要があります。

于 2016-11-03T04:09:14.920 に答える
0

おそらく odata は、エンコードされていても文字通り読み取ることができるため、台無しになっている可能性があります。私の意見では、リクエストコンテンツでパラメーターをオブジェクトとして送信する必要があります。より良いhttp://blogs.msdn.com/b/odatateam/archive/2014/12/08/function-amp-action-in-web-api-v2-2-for-odata-v4-0-を見ることができますtype-scenario.aspx#gist16957953

この助けを願っています

于 2016-02-04T11:08:53.177 に答える