2017-12-20 13 views
0

Web-Apiがルートを解決する方法を理解しようとしています。私はWeb-Apiルート解決アレイモデルバインド

[WriteRoute(DivisionAPIRoutes.PAYROLL_IMPORT_PTO)] 
[HttpPost] 
public void ImportPTOByIds(GlobalEntityKey<IDivision> parentId, GlobalEntityKey<IDivisionPayCalendar> id, 
    ImportPTORequestDTO importPTORequest, [FromUri] GlobalEntityKey<IPTORequest>[] ptoRequestIds) 
{ 
    GlobalFactory<IEmployeePTOListService>.Instance.ImportPTOByIds(parentId, id, ptoRequestIds, importPTORequest); 
} 

[WriteRoute(DivisionAPIRoutes.PAYROLL_IMPORT_PTO)] 
[HttpPost] 
public void ImportPTOByFilter(GlobalEntityKey<IDivision> parentId, GlobalEntityKey<IDivisionPayCalendar> id, ImportPTORequestDTO importPTORequest, string filterOptions, 
    [FromUri] GlobalEntityKey<IPTORequest>[] excludedPTORequestIds) 
{ 
    var filterOptionsDTO = JsonConvert.DeserializeObject<FilterOptionsDTO>(filterOptions); 
    GlobalFactory<IEmployeePTOListService>.Instance.ImportPTOByFilter(parentId, id, filterOptionsDTO, excludedPTORequestIds, importPTORequest); 
} 

NOTE同じベースパスを使用する2つのルートがあります。CLR型の文字列をbuilting、デフォルトでは、int型は、私が正常に動作POSTリクエストを作ってるんだけど、私は」URI

から取得されます

(便宜上デコード)

https://localhost/api/paystream/v1/divisions/1af4edea-d442-4fda-b29d-02c42951c0d0/payrolls/cd2ed43d-0f3d-48fb-8d00-15294a8fa06e/_actions/import-pto?filterOptions= { "クエリ": ""、 "filterParameters":[{ "フィールド名" ルート方法に解決方法の基礎となるロジックを理解しようとM: "R "filterType": "GreaterThanOrEqual"}、{"fieldName": "RequestStartDate"、 "parsebleValue": "2017-12-31"、 "filterType": "parsebleValue" LessThanOrEqual "}]}

PostBody:{ AlwaysCreateNewCheck:偽、 PayBatchType: 'チェック' PayBatchId '1903771' }

IリクエストからexcludedPTORequestIdsを省略します。これはまだImportPTOByFilterに解決されますが、excludedPTORequestIdsを含めるとfilterOptionsを省略するとImportPTOByIdsが選択されています。

モデルバインダーによって処理されるリストと配列は、bind(string、int、Guidなど)をモデル化する他のデフォルトCLRタイプとは異なる動作をすると思う傾向があります。

文字列が必要であり、404を投げたり他のルートに解決したりするとき、配列の中に明示的に定義する必要はありません。

WebApiからのルート解決のための他のルールは何ですか?

答えて

1

他のルートにフィルタオプションパラメータがないため、filterOptionsを含めると、ImportPTOByFilterが解決されます。

フィルタオプションを削除すると、パラメータがメソッドのシグネチャと一致するため、ImportPTOByIdsに解決されます。ルートの解決はルート名とパラメータによって行われます。あなたは

RouteA(string myString, int myInt) {...} 

RouteA(string myString) {...} 

RouteA(int myInt) {...} 

を持っている場合あなたが、文字列、int型、またはその両方に合格した場合に基づいてルートを解決するために起こっています。

その他もっと知りたい人がいるかもしれませんが、実際のモデルではリクエスト全体をカプセル化したいと思いますが、その方法ではモデルを調べてフィルタリングする必要があるかどうかを判断しますか否か。

+0

パラメータは、1つの配列が 'excludedPTORequestIds'と一致せず、もう1つは' ptoRequestIds'と呼ばれ、両方のルートに1つのパラメータがありません。どちらのセナリオでも、1つのパラメータが欠落しています。しかし、欠落しているパラメータによっては、経路がどのように解決されるかが異なります。 –

+0

データ型も同じです。これは、ほとんどのベストプラクティスが同じ名前の2つのルートを持たないと言っている理由です。 EDIT:フィルタ文字列パラメータを削除すると、署名が最初のルートに一致します。 –

+0

私は同意します、名前は重複してはいけません、私はモデルバインダーの実装を理解しようとしています、このコードは、クライアントがget URLをシリアル化する方法に基づいてバグを引き起こしていた。私は起動時に標準のwebapiconfigクラスを使用している場合は、modelbinderが最初にコントローラとアクションを確認してから数量を調べると思います。 –

関連する問題