上記の例はどれも私の個人的なニーズには役立ちませんでした。以下は私がやったことです。
public class ContainsConstraint : IHttpRouteConstraint
{
public string[] array { get; set; }
public bool match { get; set; }
/// <summary>
/// Check if param contains any of values listed in array.
/// </summary>
/// <param name="param">The param to test.</param>
/// <param name="array">The items to compare against.</param>
/// <param name="match">Whether we are matching or NOT matching.</param>
public ContainsConstraint(string[] array, bool match)
{
this.array = array;
this.match = match;
}
public bool Match(System.Net.Http.HttpRequestMessage request, IHttpRoute route, string parameterName, IDictionary<string, object> values, HttpRouteDirection routeDirection)
{
if (values == null) // shouldn't ever hit this.
return true;
if (!values.ContainsKey(parameterName)) // make sure the parameter is there.
return true;
if (string.IsNullOrEmpty(values[parameterName].ToString())) // if the param key is empty in this case "action" add the method so it doesn't hit other methods like "GetStatus"
values[parameterName] = request.Method.ToString();
bool contains = array.Contains(values[parameterName]); // this is an extension but all we are doing here is check if string array contains value you can create exten like this or use LINQ or whatever u like.
if (contains == match) // checking if we want it to match or we don't want it to match
return true;
return false;
}
上記をルートで使用するには、次を使用します。
config.Routes.MapHttpRoute("Default", "{controller}/{action}/{id}", new { action = RouteParameter.Optional, id = RouteParameter.Optional}, new { action = new ContainsConstraint( new string[] { "GET", "PUT", "DELETE", "POST" }, true) });
何が起こるかというと、このルートがデフォルトのGET、POST、PUT、およびDELETEメソッドにのみ一致するように、メソッドの偽物の種類が制約されます。そこでの「真」は、配列内の項目の一致をチェックしたいことを示しています。falseの場合は、strYouでそれらを除外すると言うことになります。次に、次のようなこのデフォルトの方法より上のルートを使用できます。
config.Routes.MapHttpRoute("GetStatus", "{controller}/status/{status}", new { action = "GetStatus" });
http://www.domain.com/Account/Status/Active
上記では、基本的に次のURL=>などを探しています。
上記を超えて、私はあまりにも夢中になるかどうかはわかりません。結局のところ、それはリソースごとである必要があります。しかし、さまざまな理由から、わかりやすいURLをマップする必要があると思います。Web Apiが進化するにつれて、ある種のプロビジョニングがあると私はかなり確信しています。時間があれば、より永続的なソリューションを構築して投稿します。