I have ASP.NET WebApi configured with Swashbuckle to show swagger ui. I run it from within VS in IIS Express.
The solution was in VS 2013 and it worked fine. After migration to VS 2015 the swagger shows no methods. There's no error, just empty list. The response returned is:
{"swagger":"2.0","info":{"version":"v4","title":"Swashbuckle Dummy API V4"},"host":"localhost:35622","schemes":["http"],"paths":{},"definitions":{}}
I checked the troubleshooting chapter in documentation but based on it the configuration is ok.
What can I try next?
I have found the problem. I briefly describe the situation:
We have versioned API and use custom ControllerSelector (derived from DefaultHttpControllerSelector) to select the right version of the controller. (The API version is taken from Http header.) There are subfolders in Controllers folder (like V1, V2, ..) and the controller classes are placed in those subfolders.
Generally, for documentation generation it is used ApiExplorer class fed by DefaultHttpControllerSelector, which internally manages list of HttpControllerDescriptors keyed by controller name (the short name without 'Controller' suffix). When it builds this list it checks if the controller name has already been added to the list and if yes, it not only does not add the other one but also removes the one already added.
In our case it means there are no descriptors for controllers that have multiple versions.
I was able to fix it by overriding IHttpControllerSelector.GetControllerMapping() in our custom controller selector and passing in the controller name prefixed with version, which is also a valid route. Our custom ControllerSelector accepts also version passed in URL.
Related
I am working on APIs in dotnet core 2.2 and I'd like to version my API.
I'm looking for some solutions except:
Routing method (api/v1/controller, api/v2/contoller)
Routing method using APIVersioning package, (api/v{version: apiVersion}/contoller})
I want to know if there is any other solutions in which I don't have to change the route attribute? I might be completely wrong but can I use middleware? Like, map delegate to map the the incoming requests (based on v1, v2 it carries) to its right controller?
I'll highly appreciate any feedback and suggestions.
You can use the APIVersioning package and configure it so it selects the version based on the HTTP Header.
services.AddApiVersioning(c =>
{
c.ApiVersionReader = new HeaderApiVersionReader("api-version");
}
And then you can use the [ApiVersion] attribute on your controllers.
Can you use custom middleware - yes; however, be advised that endpoint selection is typically much more involved. The routing system provides extension and customization points, which is exactly what API Versioning does for you. Creating your own versioning solution will be a lot more involved than having to add a route template parameter.
If you're going to version by URL segment, then API Versioning requires that you use the ApiVersionRouteConstraint. The default name is registered as apiVersion, but you can change it via ApiVersioningOptions.RouteConstraintName. The route parameter name itself is user-defined. You can use whatever name you want, but version is common and clear in meaning.
Why is a route constraint required at all? API Versioning needs to resolve an API version from the request, but it has no knowledge or understanding of your route templates. For example, how would ASP.NET know that the route parameter id in values/{id:int} has be an integer without the int constraint? Short answer - it doesn't. The API version works the same way. You can compose the route template however you want and API versioning knows how and where to extract the value using the route constraint. What API versioning absolutely does not do is magic string parsing. This is a very intentional design decision. There is no attempt made by API Versioning to try and auto-magically extract or parse the API version value from the request URL. It's also important to note that the v prefix is very common for URL segment versioning, but it's not part of the API version. The approach of using a route constraint negates the need for API Versioning to worry about a v prefix. You can include it in your route template as a literal, if you want to.
If the issue or concern is having to repeatedly include the API version constraint in your route templates, it really isn't any different than including the api/ prefix in every template (which I presume you are doing). It is fairly easy to remain DRY by using one of the following, which could include the prefix api/v{version:apiVersion} for all API routes:
Extend the RouteAttribute and prepend all templates with the prefix; this is the simplest
Roll your own attribute and implement IRouteTemplateProvider
Ultimately, this requirement is yet another consequence of versioning by URL segment, which is why I don't recommend it. URL segment versioning is the least RESTful of all versioning methods (if you care about that) because it violates the Uniform Interface constraint. All other out-of-the-box supported versioning methods do not have this issue.
For clarity, the out-of-the-box supported methods are:
By query string (default)
By header
By media type (most RESTful)
By URL segment
Composition of n methods (ex: query string + header)
You can also create your own method by implementing the IApiVersionReader.
Attributes are just one way that API versions can be applied. In other words, you don't have to use the [ApiVersion] attribute if you don't want to. You can also use the conventions fluent API or create your own IControllerConvention. The VersionByNamespaceConvention is an example of such a convention that derives the API version from the containing .NET namespace. The methods by which you can create and map your own conventions are nearly limitless.
Here is the problem:
I need to get a list of dependencies and its version if available. I'm using .net core 3.1.
First of all, I thought that I need two things:
1.- a list of assemblies that are referenced in the current assembly at runtime. In order to do that I can use Assembly.GetReferencedAssemblies in Reflection. I am guessing that this will include a list of nuget packages, and the version is easy to get, and of course the .net core package and version.
2.- a list of rest api calls, in this case I don't need the version number as it is not available. In this case I don't have a clue. Is there any way that I can get a dynamic list of rest api calls at runtime? So far, I haven't found anything
Apparently, there is not a class that gets this information. In most of the cases, the api call details are stored somewhere, usually appsettings.json, so retrieve them from here.
I don't know the underlying principle of the AbpUserConfigurationController? How does it inject into the aspnet core DI container? Why can't it be seen on the Swagger page? I'm using the aspnetboilerplate Premium Startup Templates.
To override AbpUserConfigurationController
you can use the approach mentioned in aspnetboilerplate/#3296(comment)
To understand how Abp inject controller into AspNetCore project
It is explained by #tseng , controller can be added via AddApplicationPart of ApplicationPartManager.
There are a few places that Abp uses ApplicationPartManager to include additional controllers.
In Abp.AspNetCore, as pointed out by #tseng, at AbpAspNetCoreModule#L47-78, the implementation here is to include Controller created in the Abp.AspNetCore assembly.
In the downloaded template, you can look for *WebCoreModule.cs under *.*.Web.Core project. The following code snippet is another place that Abp converts all the application services in the MyProjectApplicationModule assembly into controllers.
Configuration.Modules.AbpAspNetCore()
.CreateControllersForAppServices(
typeof(MyProjectApplicationModule).GetAssembly()
);
Also you take a look at AbpAspNetCoreConfiguration.cs#L47-L55 where the ControllerAssemblySettings is being updated.
Take note that CreateControllersForAppServices is called in PreInitialize() of AbpModule and AddApplicationParts is called in PostInitialize() of AbpAspNetCoreModule.
Therefore, the ControllerAssemblySettings used in the method AddApplicationParts of AbpAspNetCoreModule has already contains all the controllers to be added via ApplicationPartManager
To understand why AbpUserConfigurationController not showing up in swagger-ui
In short, conventional routing is not supported by Swagger, see swashbuckle-apiexplorer-and-routing.
TokenAuthController showed up in the swagger-ui because it is decorated with [Route("api/[controller]/[action]")] (attribute routing)
I am trying to learn, how to create a custom NiFi controller service. To start off, I thought of mimicking the DBCPConnectionPool controller service by simply copying the original source code of DBCPConnectionPool service. To implement the same, I generated a maven archetype from "nifi-service-bundle-archetype" and got the following project structure
However, when i generated the archetype from 'nifi-processor-bundle-archetype , I got the following structure: -
I understand that in case of processor I simply need to write my code in MyProceesor.java present under nifi-ListDbTableDemo-processors folder and then create a nar file out of it. But in case of controller service, I have 4 folders generated. I can see two java files i.e.
StandardMyService.java present under nifi-DbcpServiceDemo folder
MyService.java present under nifi-DbcpServiceDemo-apifolder
Now, why is there two java files generated in case of custom controller service, while there was only one java file generated in case of custom processor. Also, Since I am trying to mimick the DBCPConnectionPool service, in which java file out of two should I copy the original source code of DBCPConnectionPool service.
Please guide me from scratch, the steps that I need to follow to create a custom service equivalent to that of DBCPConnectionPool service.
MyService.java under nifi-DbcpServiceDemo-api is an interface which be implemented by the StandardMyService.java under nifi-DbcpServiceDemo. Once the implementation is done, you have to use nifi-DbcpServiceDemo-api as dependency in the processor bundle which needs to work with this custom controller Service.
The reason why controller services are implemented this way is:
We will be hiding the actual implementation from the processor bundle because it need not depend on the implementation.
Tomorrow you write a new controller service implementation, say StandardMyServiceTwo which again implements MyService because only the implementation varies from StandardMyService and other members remains the same and can be shared. This new controller service can be introduced transparently without making any changes on the processor bundle.
Example:
The best example is the record reader/writer controller services. If you look at the nifi-record-serialization-services-bundle in nifi, they have different implementation for serializing records of JSON, Grok, avro, CSV data formats but they all are actually implementing one API - nifi-record-serialization-service-api And hence for the processors which want to use the Record Reader or Record Writer, instead of having the actual implementations as its dependency, they rather can have the api as its dependency.
So tomorrow you can add add a new implementation in the record-serialization-services-bundle for a new data format without touching anything on the processors bundle.
For you references, please take a look at the following links which would help you in writing the custom controller service from scratch
http://www.nifi.rocks/developing-a-custom-apache-nifi-controller-service/
https://github.com/bbende/nifi-dependency-example
I have a custom authorization attribute, required only for some actions, which checks the request headers for a custom token. The token is checked in a database. Checking the database requires access to a service which I would like to have injected through the constructor.
The way I have read this can be done (here, here, and here) is by having a constructor-less filter and injecting the dependent one like this:
kernel.BindFilter<MyAuthorizeFilter>(FilterScope.Controller, 0).WhenControllerHas<MyAuthorizeAttribute>();
However the BindFilter method is not available to me as I have setup Ninject as described here. This is using Ninject.Web.Common instead of Ninject MVC3 as I read that Ninject MVC3 would not work with MVC4 RC. How else can I go about accomplishing this?
I have read also that I could add to GlobalFilters.Filters - however I don't want it to be present on every action.
Thanks in advance for any answers.
I'm not completely sure I see how you have set up your application, but my experience has been that if you want a filter for a WebApi controller you need to add it to the HttpFilterCollection that is available from the GlobalConfiguration.Filters. This is a Different set of filters than what MVC uses (through the GlobalFilterCollection).