Passing a dynamic where clause through Web API - .net-core

I am currently in the process of creating a.NET Core Web API that is going to interact with an Angular front end. There is a requirement for the web API to be able to return data based on a dynamically built where statement. For example, I have an object with the following model
{
"accountCode": "ABC123",
"addressLine1": "AddressLine1",
"addressLine2": "AddressLine2",
"addressLine3": "AddressLine3",
"addressLine4": null,
"addressLine5": null,
"businessUnitName": "",
"companyRegistrationNumber": null,
"name": "My supplier",
"postcode": "BA112RP",
"supplierId": 3,
"vatRegistrationNumber": null
}
Now rather than having my controller method setup with 12 different parameters and needing to add an extra parameter whenever I add a new property is there a way I can have a dynamic parameter (KeyValuePair type arrangement)?

Your asp.net-core web api is able to implicitly convert input into any given Object, for example:
[Route("api/[controller]")]
[ApiController]
public class HomeController : ControllerBase
{
public IActionResult PostObject([FromBody] MyObject obj)
{
// Your Code goes here
}
}
By default this expects a JSON format but you can use others like FormData as well.
Also it mustn't be an object with the defined properties. You can use a simple KeyValuePair as well. Have a look at Parameter Binding in ASP.NET Web API where you can find additional advice on how to best solve your Problem.

Related

Delete WebApi FromURI binding

I am trying to create a .NET5 WebApi delete method in a controller class where this method receives several "ids" that will be used for deleting some entities.
I realized when building the delete request on the client side that specifying a content does not make sense. So I was guided to pass ids on the Uri, hence the use of the "FromUri" attribute:
// DELETE: api/ProductionOrders/5
[HttpDelete("ProductionOrders")]
public IActionResult DeleteProductionOrder([System.Web.Http.FromUri]int[] ids)
{
//code
}
If this is a reasonable approach, is there a better way to build this Uri from the client-side? Imagine instead of an array of ints I had a complex type. How can I serialized this and put into the Uri?
For this example I end up building up a URI like this:
http://localhost:51081/api/ProductionOrders?ids=25563&ids=25533
Personally, if I have to pass a List or a complex type I would map values from the Body via JSON. The DELETE allow using body. And then just decorate your param with [FromBody] attribute.
Despite some recommendations not to use the message body for DELETE requests, this approach may be appropriate in certain use cases.
This allows better extensibility in case you need to change how the data is coming.
In your case with ids I’d create new class like this:
public class RequestEntity {
[JsonPropertyName("Ids")]
public List<int> Ids { get; set; }
}
And then when calling this method, send the Body along with the request.
{
"Ids": [25392, 254839, 25563]
}
In a future you can pass complex objects just by changing what is send to server and implement complex logic.

Filtering Out Properties in an ASP.NET Core API

I want to serve up the following JSON in my API:
{
"id": 1
"name": "Muhammad Rehan Saeed",
"phone": "123456789",
"address": {
"address": "Main Street",
"postCode": "AB1 2CD"
}
}
I want to give the client the ability to filter out properties they are not interested in. So that the following URL returns a subset of the JSON:
`/api/contact/1?include=name,address.postcode
{
"name": "Muhammad Rehan Saeed",
"address": {
"postCode": "AB1 2CD"
}
}
What is the best way to implement this feature in ASP.NET Core so that:
The solution could be applied globally or on a single controller or action like a filter.
If the solution uses reflection, then there must also be a way to optimize a particular controller action by giving it some code to manually filter out properties for performance reasons.
It should support JSON but would be nice to support other serialization formats like XML.
I found this solution which uses a custom JSON.Net ContractResolver. A contract resolver could be applied globally by adding it to the default contract resolver used by ASP.Net Core or manually to a single action like this code sample but not to a controller. Also, this is a JSON specific implementation.
You can use dynamic with ExpandoObject to create a dynamic object containing the properties you need. ExpandoObject is what a dynamic keyword uses under the hood, which allows adding and removing properties/methods dynamically at runtime.
[HttpGet("test")]
public IActionResult Test()
{
dynamic person = new System.Dynamic.ExpandoObject();
var personDictionary = (IDictionary<string, object>)person;
personDictionary.Add("Name", "Muhammad Rehan Saeed");
dynamic address = new System.Dynamic.ExpandoObject();
var addressDictionary = (IDictionary<string, object>)address;
addressDictionary.Add("PostCode", "AB1 2CD");
personDictionary.Add("Address", address);
return Json(person);
}
This results in
{"Name":"Muhammad Rehan Saeed","Address":{"PostCode":"AB1 2CD"}}
You'd just need to create a service/converter or something similar that will use reflection to loop through your input type and only carry over the properties you specify.

How to send templated emails?

How does one send a templated Postmark message on ASP.NET? I'd imagine it would be done in this way:
TemplatedPostmarkMessage message = new TemplatedPostmarkMessage
{
From = "demo#demo.com",
To = "someone#else.com",
TemplateId = 1738,
TemplateModel = some_passed_in_model
};
The question now arises, what exactly is TemplateModel? From the API on Postmark's site, it seems like a JSON object, but in the definition from the DLL, it's as follows:
public object TemplateModel { get; set; }
I tried creating my own object with variable names that correspond to those on the Postmark template, however that does not work (it just sends a blank template). Postmark also does not have any documentation on how to use TemplatedPostmarkMessage in ASP.NET yet.
We send a dictionary of <string, object>, I believe you can use more complex models but a dictionary will get the job done.

How do QueryString parameters get bound to Action method parameters?

I have a webforms project, and am attempting to run some code that allows me to make a call to an MVC route and then render the result within the body of the web forms page.
There are a couple of HttpResponse/Request/Context wrappers which I use to execute a call to an MVC route, e.g.:
private static string RenderInternal(string path)
{
var responseWriter = new StringWriter();
var mvcResponse = new MvcPlayerHttpResponseWrapper(responseWriter, PageRenderer.CurrentPageId);
var mvcRequest = new MvcPlayerHttpRequestWrapper(Request, path);
var mvcContext = new MvcPlayerHttpContextWrapper(Context, mvcResponse, mvcRequest);
lock (HttpContext.Current)
{
new MvcHttpHandlerWrapper().PublicProcessRequest(mvcContext);
}
...
The code works fine for executing simple MVC routes, for e.g. "/Home/Index". But I can't specify any query string parameters (e.g. "/Home/Index?foo=bar") as they simply get ignored. I have tried to set the QueryString directly within the RequestWrapper instance, like so:
public class MvcPlayerHttpRequestWrapper : HttpRequestWrapper
{
private readonly string _path;
private readonly NameValueCollection query = new NameValueCollection();
public MvcPlayerHttpRequestWrapper(HttpRequest httpRequest, string path)
: base(httpRequest)
{
var parts = path.Split('?');
if (parts.Length > 1)
{
query = ExtractQueryString(parts[1]);
}
_path = parts[0];
}
public override string Path
{
get
{
return _path;
}
}
public override NameValueCollection QueryString
{
get
{
return query;
}
}
...
When debugging I can see the correct values are in the "request.QueryString", but the values never get bound to the method parameter.
Does anyone know how QueryString values are used and bound from an http request to an MVC controller action?
It seems like the handling of the QueryString value is more complex than I anticipated. I have a limited knowledge of the internals of the MVC Request pipeline.
I have been trying to research the internals myself and will continue to do so. If I find anything I will update this post appropriately.
I have also created a very simple web forms project containing only the code needed to produce this problem and have shared it via dropbox: https://www.dropbox.com/s/vi6erzw24813zq1/StackMvcGetQuestion.zip
The project simply contains one Default.aspx page, a Controller, and the MvcWrapper class used to render out the result of an MVC path. If you look at the Default.aspx.cs you will see a route path containing a querystring parameter is passed in, but it never binds against the parameter on the action.
As a quick reference, here are some extracts from that web project.
The controller:
public class HomeController : Controller
{
public ActionResult Index(string foo)
{
return Content(string.Format("<p>foo = {0}</p>", foo));
}
}
The Default.aspx page:
protected void Page_Load(object sender, EventArgs e)
{
string path = "/Home/Index?foo=baz";
divMvcOutput.InnerHtml = MvcWrapper.MvcPlayerFunctions.Render(path);
}
I have been struggling with this for quite a while now, so would appreciate any advice in any form. :)
MVC framework will try to fill the values of the parameters of the action method from the query string (and other available data such as posted form fields, etc.), that part you got right. The part you missed is that it does so by matching the name of the parameter with the value names passed in. So if you have a method MyMethod in Controller MyController with the signature:
public ActionResult MyMethod(string Path)
{
//Some code goes here
}
The query string (or one of the other sources of variables) must contain a variable named "Path" for the framework to be able to detect it. The query string should be /MyController/MyMethod?Path=Baz
Ok. This was a long debugging session :) and this will be a long response, so bear with me :)
First how MVC works. When you call an action method with input parameters, the framework will call a class called "DefaultModelBinder" that will try and provide a value for each basic type (int, long, etc.) and instance of complex types (objects). This model binder will depend on something called the ValueProvider collection to look for variable names in query string, submitted forms, etc. One of the ValueProviders that interests us the most is the QueryStringValueProvider. As you can guess, it gets the variables defined in the query string. Deep inside the framework, this class calls HttpContext.Current to retrieve the values of the query string instead of relying on the ones being passed to it. In your setup this is causing it to see the original request with localhost:xxxx/Default.aspx as the underlying request causing it to see an empty query string. In fact inside the Action method (Bar in your case) you can get the value this.QueryString["variable"] and it will have the right value.
I modified the Player.cs file to use a web client to make a call to an MVC application running in a separate copy of VS and it worked perfectly. So I suggest you run your mvc application separately and call into it and it should work fine.

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