I am developing a add-on to provide some WebApi services to fetch data from EPiServer. I use 2 third-party components such as HtmlAgilityPack and Microsoft.AspNet.WebApi. So should I use them as implicit dependencies? Does anyone have good idea for me? Thanks a lot.
I would suggest that you use the NuGet-support to install and manage add-ons that was introduced a few months ago. Then you can use regular NuGet dependencies for WebAPI and HTML agility pack. For WebAPI, and any OWIN dependencies, it's important that you don't set up WebAPI yourself but rather have this as part of a step that the developer has to do. The reason for this is that several different components/add-ons could otherwise try to set up the same functionality, for instance web API. You can read more here:
Thank for your suggest! It is great for my job.
Linus, by "requiring developer to setup AddOn" you mean that developer is responsible for setting up routing to webapi in this case as well?
Good question! I had to do some research on the current status. It seems that for the EPiServer Service API (which is the only component/add-on that is currently using service API), we are using attribute routing. Unfortunately, set up of attribute routing is automatically done in a initialization module (we call config.MapHttpAttributeRoutes();). The reason I say "unfortunately", is that this may collide with other code doing this, for instance code in the partners solution. We have reported a bug to remove this for the automatic initialization and to add this to the list of things to do for initialization when setting up the Service API.
I think that attribute routing is the way to go in an environment where you might have several components, potentially from several sources, using Web API. This way, each component can define their routing within each component and just require that the attribute routing is initialized.
Yes, that sounds like more preferred way. "Components" provide sort of metadata for routing, and there is a "component system composer" that takes care of initializing and registering discovered routes across all known components. But currently, if we call MapHttpAttributeRoutes twice - I guess it should fail with "already in dicttionary" exception or similar..?!
Yes, it's good point. Now, I am registering my routing by calling config.MapHttpAttributeRoutes() too. Maybe it will be duplicated with other components or system. So I think that the developer can add routing information into web.config or module.config as EPiServer have done and read config info to register routing in initialization module .
When I call MapHttpAttributeRoutes() a second time I get the following exception:
A route named 'MS_attributerouteWebApi' is already in the route collection. Route names must be unique.
Therefore, it should be up the the partner implementing the web site to call the attribute route initialization since there is no check that it cannot be called twice. As mentioned before, the EPiServer service API does not currently follow this pattern but we will make sure it does so in the future.
Binh: If you use attribute route-declarations there is no need for set up for your routes, just as long as the attribute routing is set up at inititialization.