おそらく、多くの人が生活の中でRESTful APIを設計および開発する必要がありました。 Web APIテクノロジーのリリースにより、操作がはるかに簡単になりました。また、Web API 2のリリースにより、さらに快適になりました。 ASP.NET MVCから移行されたルーティングシステムは、そのタスクに対応し、パスを自由に設計できるだけでなく、さまざまなパラメーターでパスを調整し、中括弧で示します。 「api / {controller} / {id}」という形式のテンプレートが、今ではsomeone敬の念を起こさせることはほとんどありません。 しかし、この{id}としてのAPIのメソッドのいくつかが、Guidではなく、たとえば電子メールアドレスの文字列表現の数値を受け入れない場合はどうなりますか？ たとえば、データベース内のこのアドレスの可用性を確認するには。 それでは何も機能しませんが、すべてのせいは小さな一見完全に無害な点です。 これでさらに生き、カットの下で説明する方法。
問題の存在そのものがそれほど大げさなものではないことをすぐに言及する価値がありますが、2つの非常に標準的な方法で簡単に回避できます。
-解決する必要はありません。モデルでメールを送信できます。
-排泄する必要はありません。メールをクエリ文字列パラメータとして渡すことができます。
一方、電子メールがまさにその識別子である場合、モデルまたは属性ではなくパスに入れる方が論理的およびイデオロギー的に正確であると思われます。 ただし、このトピックについて長い間議論して議論できると確信していますが、非常に具体的な問題に直面しています。電子メールにドットが存在すると、404番目のエラーが発生します。 根本的な原因は完全に透過的だと思います：Webサーバーはファイル（ドット）を検索しようとしていますが、もちろんそのようなファイルはありません。
これにどのように対処できますか？ 多くの方法がありますが、それらはすべて異なっており、おそらくすべての可能性でさえ以下に表示されません（コメントが役立つことを願っています）。
方法1
スラッシュ。 {id}パラメーターの後にパスの最後に追加すると、すべてが突然機能します。 これは、このセグメントがファイル名としてではなく、フォルダー名として理解されるためです。 解決策は非常に簡単ですが、それほど美しくはありません。この方法の最後にスラッシュを付ける必要があることをサービスの消費者に知らせる必要があるためです。 ここでは、フォルダとポイントに関連する別の興味深い点に言及する価値があります。 スラッシュの直前のセグメントの最後にドットを入れると、404も得られます。MSDOS後のシステム（およびそこから脚が伸びる）のフォルダー名はドットで終わることはできません。 同じ理由で、次のリテラルはパスで使用できません：COM1-9、LPT1-9、AUX、PRT、NUL、CON。 もちろん、これを回避する方法があります。特に、属性を使用します
<httpRuntime relaxedUrlToFileSystemMapping="true" />
方法2
構成ファイルのsystem.webServerセクションで、指定します
<modules runAllManagedModulesForAllRequests="true" />
そして出来上がり、すべてが動作します。 悪い方法ですが、多くの人がすぐにアドバイスしますが、非常に悪いです。 むかしむかし、このオプションは本当に省くことができませんでしたが、概して、画像、CSS、スクリプトなどの静的コンテンツを受信するためのネイティブモジュールの代わりに、各要求がマネージモジュールのセット全体を通過することを意味します少なくとも大幅なパフォーマンスの低下を伴うアプリケーション。 それが、そのような決定が一種の「総当たり」である理由です。
方法3
すべて同じ構成ファイルで、次の設定で目的の効果を実現できます。
<modules> <remove name="UrlRoutingModule-4.0" /> <add name="UrlRoutingModule-4.0" type="System.Web.Routing.UrlRoutingModule" preCondition="" /> </modules>
ここで一番下の行は、UrlRoutingModuleのpreCondition属性をクリアして、このマネージモジュールがすべての着信要求を処理できるようにすることです。 この方法は、以前の方法と非常に似ていますが、唯一の違いは、 すべてのマネージモジュールがそこで各リクエストを処理したことです。 西洋ワサビは、一般的に、大根は甘くない。
方法4
2010年に、MicrosoftはIIS 7.0および7.5用のパッチをリリースしました。これにより、属性path = "*"のハンドラーが許可されました。 ポイントで終わるパスだけでなく、ポイントのないパスも理解します。 いわゆるの時代 拡張なしのURL、およびメソッド番号2の関連性が失われました。 ところで、パッチの説明はこちらにあります 。 今日、web.configのハンドラーセクションで同様のエントリを簡単に見つけることができます。
<remove name="ExtensionlessUrlHandler-Integrated-4.0" /> <add name="ExtensionlessUrlHandler-Integrated-4.0" path="*." verb="*" type="System.Web.Handlers.TransferRequestHandler" preCondition="integratedMode,runtimeVersionv4.0" />
これはどのように問題を解決しますか？ はい、一般的には何もありません。 パス属性の値を孤独なアスタリスクに変更しない限り。 また、一種の方法であり、電子メールも機能しますが、拡張子の付いた単一のファイルは取得できなくなります。 同じハンドラーから500番目のエラーが発生します。
質問が発生します：それで何をすべきか？ おそらく、それに対する答えは単一の値ではありません。 ここでの私の個人的な意見では、後者の方法を使用するのが最善の解決策ですが、部分的にしか使用できません。 メソッドへのすべてのパス（静的リソースではなくメソッドのみ）がわかっている場合、APIの対応するプレフィックス（「api / {controller} / {id}」）で始まる場合、同じハンドラを追加できます。 「api / *」形式のアドレスのタイプ：
<remove name="ExtensionlessUrlHandler-Integrated-4.0" /> <add name="API-ExtensionlessUrlHandler-Integrated-4.0" path="api/*" verb="*" type="System.Web.Handlers.TransferRequestHandler" preCondition="integratedMode,runtimeVersionv4.0" /> <add name="ExtensionlessUrlHandler-Integrated-4.0" path="*." verb="*" type="System.Web.Handlers.TransferRequestHandler" preCondition="integratedMode,runtimeVersionv4.0" />
したがって、彼らが言うように、API設計レベルでハエをカツレツから分離します。
PS誰かがそのような問題を解決する他の方法、および追加情報と説明を持っているなら、コメントで、彼の賢い考えだけでなく彼の表現が強く歓迎されます。 ご清聴ありがとうございました。