Force CamelCase on ASP.NET WebAPI Per Controller - asp.net

In ASP.NET WebAPI, I know you can set the default json formatter to use camel case using CamelCasePropertyNamesContractResolver() in the global.aspx which will force ALL json serialization to camel case.
However, I need to be able to set it on a "Per Controller" instance, instead of a Global solution.
Is this possible?

Thanks to #KiranChalla I was able to achieve this easier than I thought.
Here is the pretty simple class I created:
using System;
using System.Linq;
using System.Web.Http.Controllers;
using System.Net.Http.Formatting;
using Newtonsoft.Json.Serialization;
public class CamelCaseControllerConfigAttribute : Attribute, IControllerConfiguration
{
public void Initialize(HttpControllerSettings controllerSettings, HttpControllerDescriptor controllerDescriptor)
{
var formatter = controllerSettings.Formatters.OfType<JsonMediaTypeFormatter>().Single();
controllerSettings.Formatters.Remove(formatter);
formatter = new JsonMediaTypeFormatter
{
SerializerSettings = {ContractResolver = new CamelCasePropertyNamesContractResolver()}
};
controllerSettings.Formatters.Add(formatter);
}
}
Then just add the attribute to any Controller class you want CamelCase.
[CamelCaseControllerConfig]

Yes, it's possible...you can use IControllerConfiguration to define per-controller specific configuration..
This is a sample which describes this scenario. You can quickly take a look at how this interface should be used over here(from the sample).

This Stack Overflow answer should be helpful. It shows you how to create an ActionFilter which can be applied to any action where you wish to use CamelCasing.

I know this is pretty old, but I had a problem with the accepted answer because there were other necessary changes to the formatter that were no longer present after removing and re-adding. I did this by just modifying the existing formatter as shown in this Gist: https://gist.github.com/mauricedb/5356933.

Related

CamelCase property names with NJsonSchema C# CodeGeneration

does anybody know a way to configure NJsonSchema to use CamelCase property naming durching code generation? I've a JSON schema with property names like message_id which lead to C# property name 'Message_id' where i.e. 'MessageId' whould be a more C#-like way.
With an attribute like '[JsonProperty("message_id"]' it would be no problem to specified the connection between the different names.
So, you asked about code generation. I was having trouble with the schema it generated not matching what was getting sent to my Angular app. So, while this isn't exactly what you were looking for, perhaps it helps you find an answer (maybe?).
To generate the schema with the camel case property names, I'm setting the Default Property Name Handling to CamelCase, but this is using the deprecated call to set these settings directly. There should be some way to use the SerializerSettings directly, but I wasn't quite able to make that work. This isn't production code for me, so it will do.
internal class SchemaFileBuilder<T>
{
public static void CreateSchemaFile()
{
CreateSchemaFile(typeof(T).Name);
}
public static void CreateSchemaFile(string fileName)
{
JsonSchemaGeneratorSettings settings = new JsonSchemaGeneratorSettings();
settings.DefaultPropertyNameHandling = PropertyNameHandling.CamelCase;
var schema = NJsonSchema.JsonSchema.FromType<T>(settings);
var json = schema.ToJson();
Directory.CreateDirectory("Schemas");
File.WriteAllText($"Schemas\\{fileName}.schema.json", json);
}
}
I set this up as a generic function so I could pass multiple schemas in to either createSchemaFile functions. Here's are some example calls which would generate a Person.schema.json file and a Persons.schema.json file:
SchemaFileBuilder<Person>.CreateSchemaFile();
SchemaFileBuilder<Dictionary<string, Person>>.CreateSchemaFile("Persons");

Azure functions HttpTrigger, not using HttpMethods class in attribute

Why do functions in AzureFunctions requires to use
[HttpTrigger(AuthorizationLeve.Anonymous, "get")]
Instead of
[HttpTrigger(AuthorizationLeve.Anonymous, HttpMethods.Get)]
Of course I cannot use
HttpMethods.Get.ToString()
becase language does not allow to call functions in Attributes
and creating my own
public static class HttpMethodsStrings
{
public const string Get = "get";
}
seems redundant since .NET already provides HttpMethods.
You can use System.Net.WebRequestMethods.Http.X constants instead of hard coded strings ("get", "post"). I have put together the piece of code and debugged it and it works fine.
The snippet of the same is shown below -
You can modify your second example to use the nameof operator
eg
[HttpTrigger(AuthorizationLeve.Anonymous, HttpMethods.Get)]
becomes
[HttpTrigger(AuthorizationLeve.Anonymous, nameof(HttpMethods.Get))]

Upgrading Unity container breaks interception mechanism

We recently upgraded Microsoft's Unity in our project from version 3.5.1404 to 5.8.6. With only a few minor adjustments in our code this upgrade seemed to go pretty easy. It resolves all our registered instances without a problem. However, we also use Unity's Interception-mechanism to cache some results that a method returns in AOP-style. This cache mechanism is broken since the upgrade and we can't figure out why. Apparently, our attributes are no longer called when a decorated method is called.
It currently works as follows. We register the interception like this:
var container = new UnityContainer();
container.RegisterType<IService, Service>(some_lifetime);
container.AddNewExtension<Interception>();
container.Configure<Interception>()
.SetInterceptorFor(typeof(IService), new InterfaceInterceptor());
In the Service class, which implements IService we have a method that is decorated with a custom Cache attribute, like this:
public class Service : IService {
[Cache(..)]
public Result SomeMethod() {
// Some code
}
}
And lastly, our custom Cache attribute which inherits from Unity's HandlerAttribute:
public class CacheAttribute : HandlerAttribute
{
// ctor
public override ICallHandler CreateHandler(IUnityContainer container)
{
return new CacheCallHandler(container, and, some, more);
}
}
When method SomeMethod used to be called with version 3.5.1404 the attribute was called first, but since 5.8.6 it no longer calls this attribute. The code however, does compile. The changes we had to make to make it compile are mostly changes in usings. Like Microsoft.Practices.Unity.InterceptionExtension which changed to Unity.Interception.PolicyInjection.Policies.
We can't figure out why this mechanism is no longer working. And even after extensive research on the internet, we can't find a way to get this to work. Any suggesties would therefore be greatly appreciated!
I got in your exact same situation while trying to refresh some legacy code. I got it working with:
Changing:
config.SetInterceptorFor(myType, new InterfaceInterceptor()); for
config.SetInterceptorFor(myType, new TransparentProxyInterceptor());
Registering the class that inherits from HandlerAttribute
Container.RegisterType<MyHandlerAttribute>(new PerRequestLifeTimeManager());
Register each type to intercept with special InjectionMembers:
Container.RegisterType<MyClassToBeIntercepted>(
new Interceptor<TransparentProxyInterceptor>(),
new InterceptionBehavior<PolicyInjectionBehavior>()
);

Is is possible to use a custom resolver instead of the hubname attribute to resolve signalr hubs?

All of my SignalRHubs have their own service interface, this is used on the client side for type safe calling; ie no more referring to methods by string.
Anyways with this setup I have had to add a HubName attribute to all my hubs with the Interface name. Is it even possible to have the hubs resolved by these interfaces.
I did try replacing the resolver both in GlobalHost and in the HubConfiguration object with a Ninject resolver but it didn't seem to ever call the resolved for the hubs themselves.
Here is an example of a hub:
[HubName("IFoobarService")]
public class FoobarHub : Hub, IFoobarService
{
public void Baz(BazDto dto)
{
Clients.Others.Baz(dto);
}
}
}
Here is the code I used to try to bind my hubs with Ninject
kernel.Bind(x => x.FromThisAssembly()
.SelectAllClasses()
.InheritedFrom()
.BindAllInterfaces());
I think that using the HubName attribute is your best bet.
You could provide your own IHubDescriptorProvider and register it with SignalR's DependencyResolver, but I wouldn't recommend it.
You can take a look at the default IHubDescriptorProvider implemenation here: https://github.com/SignalR/SignalR/blob/2.0.2/src/Microsoft.AspNet.SignalR.Core/Hubs/Lookup/ReflectedHubDescriptorProvider.cs#L56
Notice the following line of code:
var hubDescriptors = types
.Select(type => new HubDescriptor
{
NameSpecified = (type.GetHubAttributeName() != null),
Name = type.GetHubName(),
HubType = type
});
Type.GetHubName() is implemented as an extension method here:
https://github.com/SignalR/SignalR/blob/2.0.2/src/Microsoft.AspNet.SignalR.Core/Hubs/Extensions/HubTypeExtensions.cs#L9
You could replace the ReflectedHubDescriptorProvider with your own IHubDescriptorProvider implementation that calls into your own GetHubName method, but I think that would be overkill.
Once again, I think using the HubName attribute is your best bet.

Versioning of REST API Built With ASP.NET MVC 3 - Best Practices

I am wondering if there is a best practice for creating a REST API with ASP.NET MVC 3? At the moment I am thinking of creating a controller for each version of the REST API. For example, so far I have:
public class V1Controller : Controller
{
public V1Controller()
{
}
public ActionResult GetUser(string userId, IUserRepository userRepostory)
{
//code to pull data and convert to JSON string
return View("Results");
}
public ActionResult GetUsersByGroup(string groupId, IUserRepository userRepostory)
{
//code to pull data and convert to JSON string
return View("Results");
}
}
Then for the views I overwrite the _ViewStart.cshtml to remove the layout and then I have Results.cshtml that just outputs the data that is formatted in the controller action, right now JSON. Having every single REST call in one controller seems like a bit too much but it is the best way I can think of so that I can keep clean separate versions of the API so that when it comes to creating version 2 of the API, I can create a V2Controller and not break the existing API to give people time to switch over to the new API.
Is there a better way to create a REST API with ASP.NET MVC 3?
I was able to find a decent solution using MVC's use of Areas.
First, I wanted to have my API follow this URL Definition:
http://[website]/[major_version]_[minor_version]/{controller}/{action}/...
I also wanted to break up the different versions in separate Project files and use the same Controller names in each version:
"../v1_0/Orders/ViewOrders/.." => "../v2_3/Orders/ViewOrders/.."
I searched around and found a workable solution with the use of MVC Areas.
I created a new project in my solution called "Api.Controllers.v1_0" and, as a test, put a SystemController.cs file in there:
using System.Web.Mvc;
namespace Api.Controllers.v1_0
{
public class SystemController : Controller
{
public ActionResult Index()
{
return new ContentResult() {Content = "VERSION 1.0"};
}
}
}
I then added a v1_0AreaRegistration.cs file:
using System.Web.Mvc;
namespace Api.Controllers.v1_0
{
public class v1_0AreaRegistration : AreaRegistration
{
public override string AreaName
{
get{ return "v1_0";}
}
public override void RegisterArea(AreaRegistrationContext context)
{
context.MapRoute(
"v1_0",
"v1_0/{controller}/{action}/{id}",
new { controller = "System", action = "Index", id = UrlParameter.Optional }
);
}
}
}
I walked through the same steps above for a "..v1_1" project with the corresponding files in there, added the projects as references into my "Api.Web" MVC project and was off and running.
If all you are returning is JSON, you do not need a view. Jusr return
new JsonResult(){Data = Data};
Look in here.
Also in terms of versioning, versions can be implemented as different controllers or as extra methods in the same controller. But without knowing why you would need versions and why your clients (which I assume are browsers) would need to know about versioning is not clear from your question.
A controller such as the one you posted in your example code should always keep that methods that you have now for instance GetUsersByGroup() with the same signature. I don't see how there could be a different version of that method.
The inputs are group and repository (which I believe comes from DI). The output is a list of users in JSON format. That's all that matters to the users of the API. What you do inside this method is no one's business.
You should think more of inputs and outputs. You shouldn't be changing the signatures of existing actions unless it is really neccessary to do so.
Think of the controller class in terms of implementing the interface. You have an interface and controller class is it's implementation (I mean you don't need to have it but just think of it in that way). You will rarely change the interface once one or several classes implement it. But you might add the methods to it. And that requires only changes in implementing classes - it does not break the functionality of the API and everyone who's using it will be able to continue using it.

Resources