Skip to main content
Commonmark migration
Source Link

Update your Api methods to add an [HttpGet] attribute or change the method name to Get() (and update your route initialization accordingly):

public class TestApiController : ApiController
{
    [HttpGet]
    public string Test()
    {
        return "Success from Test()";
    }

    public string Get()
    {
        return "Success from Get()";
    }
}

The current placement of the initialization pipeline processor is fine, just be aware that patching before/after the InitializeRoutes processors makes more sense depending on whether the calls should be tracked:

The Sitecore.Mvc.Pipelines.Loader.InitializeRoutes processor of the Initialize pipeline requires a session to be present for all routes. Therefore, if you add the custom route registration processor before the Sitecore.Mvc.Pipelines.Loader.InitializeRoutes processors, the session is available in the controllers.

 

If you register the routes in the processor that is initialized after the Sitecore.Mvc.Pipelines.Loader.InitializeRoutesprocessor, the session is not available and the controller requests are not tracked. This is useful for custom routes that you do not need to track, for example Web API routes.

Update your Api methods to add an [HttpGet] attribute or change the method name to Get() (and update your route initialization accordingly):

public class TestApiController : ApiController
{
    [HttpGet]
    public string Test()
    {
        return "Success from Test()";
    }

    public string Get()
    {
        return "Success from Get()";
    }
}

The current placement of the initialization pipeline processor is fine, just be aware that patching before/after the InitializeRoutes processors makes more sense depending on whether the calls should be tracked:

The Sitecore.Mvc.Pipelines.Loader.InitializeRoutes processor of the Initialize pipeline requires a session to be present for all routes. Therefore, if you add the custom route registration processor before the Sitecore.Mvc.Pipelines.Loader.InitializeRoutes processors, the session is available in the controllers.

 

If you register the routes in the processor that is initialized after the Sitecore.Mvc.Pipelines.Loader.InitializeRoutesprocessor, the session is not available and the controller requests are not tracked. This is useful for custom routes that you do not need to track, for example Web API routes.

Update your Api methods to add an [HttpGet] attribute or change the method name to Get() (and update your route initialization accordingly):

public class TestApiController : ApiController
{
    [HttpGet]
    public string Test()
    {
        return "Success from Test()";
    }

    public string Get()
    {
        return "Success from Get()";
    }
}

The current placement of the initialization pipeline processor is fine, just be aware that patching before/after the InitializeRoutes processors makes more sense depending on whether the calls should be tracked:

The Sitecore.Mvc.Pipelines.Loader.InitializeRoutes processor of the Initialize pipeline requires a session to be present for all routes. Therefore, if you add the custom route registration processor before the Sitecore.Mvc.Pipelines.Loader.InitializeRoutes processors, the session is available in the controllers.

If you register the routes in the processor that is initialized after the Sitecore.Mvc.Pipelines.Loader.InitializeRoutesprocessor, the session is not available and the controller requests are not tracked. This is useful for custom routes that you do not need to track, for example Web API routes.

Source Link
jammykam
  • 13.9k
  • 2
  • 29
  • 74

Update your Api methods to add an [HttpGet] attribute or change the method name to Get() (and update your route initialization accordingly):

public class TestApiController : ApiController
{
    [HttpGet]
    public string Test()
    {
        return "Success from Test()";
    }

    public string Get()
    {
        return "Success from Get()";
    }
}

The current placement of the initialization pipeline processor is fine, just be aware that patching before/after the InitializeRoutes processors makes more sense depending on whether the calls should be tracked:

The Sitecore.Mvc.Pipelines.Loader.InitializeRoutes processor of the Initialize pipeline requires a session to be present for all routes. Therefore, if you add the custom route registration processor before the Sitecore.Mvc.Pipelines.Loader.InitializeRoutes processors, the session is available in the controllers.

If you register the routes in the processor that is initialized after the Sitecore.Mvc.Pipelines.Loader.InitializeRoutesprocessor, the session is not available and the controller requests are not tracked. This is useful for custom routes that you do not need to track, for example Web API routes.