1

Sitecore ルートで REST サービスを構築しようとしています。私のアプリケーションの開始は次のようになります。

void Application_Start(object sender, EventArgs e) 
{
    RouteTable.Routes.MapHttpRoute(
        name: "DefaultApi", routeTemplate: "api/{controller}/{id}", defaults: new { id = System.Web.Http.RouteParameter.Optional });
}

私のURLは次のようになります。

http://{mydomain}/api/books

私は正しいコントローラーとそのすべてを持っています。

しかし、Sitecore は私を 404 ページにリダイレクトし続けます。web.config に IgnoreUrlPrefixes ノードへのパスを追加しましたが、役に立ちませんでした。推測する必要があるとすれば、Sitecore のハンドラーはコードが実行される前にリダイレクトしていると思いますが、実際にはわかりません。

誰が何が間違っているのか考えていますか?

4

4 に答える 4

1

あなたの評価は正しいです。httpRequestBeginSitecoreの処理を中止するには、パイプラインにプロセッサが必要です。SystemWebRoutingResolverこの回答 のを参照してください： SitecoreおよびASP.net MVC

この記事でも説明されています： http ：//www.sitecore.net/Community/Technical-Blogs/John-West-Sitecore-Blog/Posts/2010/10/Sitecore-MVC-Crash-Course.aspx

ただし、ここにもコードを含めます。:)

public class SystemWebRoutingResolver : Sitecore.Pipelines.HttpRequest.HttpRequestProcessor
{
    public override void Process(Sitecore.Pipelines.HttpRequest.HttpRequestArgs args)
    {
        RouteData routeData = RouteTable.Routes.GetRouteData(new HttpContextWrapper(args.Context));
        if (routeData != null)
        {
            args.AbortPipeline();
        }
    }
}

次に、httpRequestBegin構成で：

<processor type="My.SystemWebRoutingResolver, My.Classes" />
于 2012-05-25T01:57:57.423 に答える
0

ルーティング用のパイプライン初期化子が必要です: 次のようになります:

パブリック クラス イニシャライザ

{
        public void Process(PipelineArgs args)
        {
        RouteCollection route = RouteTable.Routes;
        route.MapHttpRoute("DefaultApi", "api/{controller}/{action}/{id}",
        new { id = RouteParameter.Optional });
        }
}

構成ファイルには次のものがあります。

<configuration xmlns:patch="http://www.sitecore.net/xmlconfig/">
  <sitecore>
    <pipelines>
      <initialize>
    <processor type="_YourNameSpace.Initializer,_YourAssembly" />
      </initialize>
     </pipelines>
  </sitecore>       
</configuration>

ハッピーコーディング

于 2013-06-29T08:35:04.113 に答える
0

私が効果的に使用した別のオプションは、コンテンツ ツリー、「スター」アイテム、およびこの目的専用のサブレイアウト/レイアウトの組み合わせを使用することです。

[siteroot]/API/*/*/*/*/*/*/*/*/*

上記のパスでは、1 ～ 9 個のセグメントを使用できます。それ以上のセグメントが必要な場合は、おそらくプロセスを再考する必要があります (IMO)。これにより、すべての Sitecore コンテキストも保持されます。フォルダー内にアイテムが見つからない場合、Sitecore はキャッチオール スター アイテムを探し、存在する場合は 404 を返す代わりにそのアイテムをレンダリングします。

安らかなメソッドとサブレイアウト (または、解析を簡素化するために深さで分離したい場合はサブレイアウト) を実行するには、いくつかの方法があります。

一般的な「標準」に従い、GET、PUT、および POST 呼び出しを使用してこれらのアイテムと対話することを選択できますが、カスタム バックエンド キャッシュ コードなしでは Sitecore キャッシュを使用できません)。または、API を 3 つの異なるツリーに分割できます。

[siteroot]/API/GET/*/*/*/*/*/*/*/*/*
[siteroot]/API/PUT/*/*/*/*/*/*/*/*/*
[siteroot]/API/POST/*/*/*/*/*/*/*/*/*

これにより、GET リクエストをキャッシュできます (GET リクエストはデータを取得するだけで、更新する必要はないため)。これらのコンテキストのいずれかでこれを使用する場合は、基本的に、データ、ユーザーなどのすべての順列に基づいてキャッシュする必要があります。

複数のサブレイアウトを作成する場合は、GET、PUT、および POST の一般的なメソッドを処理する基本クラスを作成し、それらのクラスをサブレイアウトの基本として使用することをお勧めします。

サブレイアウトでは、Request オブジェクトを取得し、パス (およびクエリを使用している場合はクエリ) を取得し、それを分割して、標準ルーティングの場合と同様に大文字と小文字の切り替えロジックを実行するだけです。PUT の場合は、Response.ReadBinary() を使用します。POST の場合、Request.Form オブジェクトを使用してすべてのフォーム要素を取得し、それらを繰り返し処理して提供された情報を処理します (すべてのフォーム データを、文字列としてカプセル化された単一の JSON オブジェクトに入れるのが最も簡単な場合があります (したがって、.NET文字列と見なされるため、1 つのプロパティと見なされます)、ユーザーが指定した POST パスに応じて、ポストに 1 つの要素のみを逆シリアル化する必要があります。

複雑？はい。動作しますか？はい。おすすめされた？まあ...共有環境（複数のサイト）にいて、パイプラインプロセッサのすべてのサイトでこの処理を実行したくない場合は、このソリューションが機能します。Sitecore で MVC を使用できる場合、またはパイプライン プロセッサの変更に問題がない場合は、おそらくより効率的です。

コンテンツ ベースの方法の利点の 1 つは、コンテキスト ライフサイクルが標準の Sitecore ページ (ログインなど) とまったく同じであるため、ライフサイクルのその時点で他のアイテムが提供するのと同じコントロールをすべて利用できることです。これのマイナス点は、コードに到達する前にページ ライフサイクル全体の負荷に対処しなければならないことです...パイプライン プロセッサは多くの Sitecore のプロセスをスキップし、必要なデータのみを直接取得することができるため、高速化されます。

于 2013-06-28T13:52:07.757 に答える