I have an ODataController that is returning a PageResult.
Api Example:
public PageResult<Customer> Get(ODataQueryOptions options) {
// cut some stuff out...
PageResult<Customer> result = new PageResult<Customer>(
searchResults as IEnumerable<Customer>,
Request.GetNextPageLink(),
Request.GetInlineCount());
return result;
When I debug this, it seems to be fine and have a PageResult class built up correctly to return. On the Web side..
Web Example
using (var client = new HttpClient()) {
client.BaseAddress = new Uri(testURL);
string searchUrl = "api/customer?$top=1&$skip=0";
client.DefaultRequestHeaders.Accept.Add(MediaTypeWithQualityHeaderValue.Parse("application/json;odata=verbose"));
HttpResponseMessage response = client.GetAsync(searchUrl).Result;
The response is a StatusCode 406, with a reason phrase stating the content was not acceptable. It also does this if I define a new MediaTypeWithQualityHeaderValue("application/json").
What do I need to change so that I successfully consume this Api in the controller before passing it on to the view?
I think you are missing the first two steps of building an OData service. ODataController, as the name says, only works with OData routes. You need to build an EDM model representing your OData service, and, add an OData route exposing that EDM model. Refer to this official documentation and blog post for details on how to build OData services.
Related
I am asked to implement a REST Web API to a specific route, where either of two different Json Datatypes may be posted.
This results in the following exception being thrown:
Microsoft.AspNetCore.Routing.Matching.AmbiguousMatchException: The request matched multiple endpoints.
Is there an Attribute that can be placed on the Web Methods, referencing Properties of the Json payloads so as to disambiguate the two possible Datatypes?
This was covered here but I'll add a little bit.
It's not good API design to do that and goes against Swagger / OpenAPI specifications to do what you're asking.
The only way to do this with the same HTTP method (POST in your case) is to have one action that takes in both models. Check which one isn't null to then route to the correct method to handle that logic.
If you can get away with using a different HTTP verb you could technically do that and have two separate action methods (like POST and PUT), but you wouldn't be using them "correctly" and based on your question and need, I doubt you can do that anyway.
You can read the request body as a string and then try to decide which type to deserialize in:
[HttpPost]
[Route("api/mypath")]
public async Task<IActionResult> MyMethod()
{
request.Body.Position = 0;
var reader = new StreamReader(request.Body, Encoding.UTF8);
var body = await reader.ReadToEndAsync();
if(body.Contains("A))
{
var A = JsonConvert.DeserializeObject<A>(body);
}
else{
var B = JsonConvert.DeserializeObject<B>(body);
}
}
And add a middleware to enable request buffering:
app.Use(next => context => {
context.Request.EnableBuffering();
return next(context);
});
You can read more about it here
Configured the HttpClient in the startup.cs.
services.AddHttpClient("jsonPosts", client => {
client.BaseAddress = new Uri("https://jsonplaceholder.typicode.com/");
On the Controller calling API:
// Obtaining _clientFactory by DI on the Controller constructor
var client = _clientFactory.CreateClient("jsonPosts");
var myContent = JsonConvert.SerializeObject(myObjectToSerialize);
HttpContent stringContent = new StringContent(myContent, Encoding.UTF8, "application/json");
HttpResponseMessage result = await client
.PostAsync(client.BaseAddress + "posts/1", stringContent)
.ConfigureAwait(false);
You can can see on the PostAsync method the API endpoint is being appended to the base address of the HttpClient.
Is this the recommended approach of managing different endpoints across an application?
Well, that depends on your application.
If you only have to do few things like authenticate, post something, exit application then there´s no reason to do the work and create a structure thatfor.
If you do multiple calls and especially want to do the same call at different points in your code you should create an api wrapper.
A common way is to create one generic method that takes an Type as generic argument, also give it the url, HTTP method and other data you might need.
The method will do the call with the arguments given, automatically Deserialize the JSON to an Object of the generic type and return it to you.
This way you can do something like this with only having to write one method and define classes for the Results. You might even use dynamics without defining classes but I personally don´t like dynamics.
ApiClient api = new ApiClient(baseUrl);
User user = api.get<User>("/user", new Query().add("user", "admin"));
EmailList emails = api.get<EmailList>("/user/emails");
Then you could still populate it into multiple methods if you don´t want to mess with the endpoints like
public User getUser(String username){
User user = api.get<User>("/user", new Query().add("user", "admin"));
return user;
}
And use it like
MyApiWrapper.getUser("admin");
TL;DR;
"I like how my generated AutoRest client deserializes my main entities when dealing with the 200 scenarios.. but, MUST I manually parse the 400 scenarios?", said the lazy programmer
DETAILS:
So, I have an API, (Web API 2), and I do all the standard stuff.. using POCO's that implement IValidatable in addition to property-level validation using System.Data.DataAnnotations my Web API returns 400 errors like this (just an example):
if (!ModelState.IsValid)
{
return BadRequest(ModelState);
}
And, where appropriate I use SwaggerResponse attributes, and my swagger.json is documented thus so that my generated client knows that a 400 is a viable response.
Now, my unit tests which directly instantiate the api controllers, I purposely try to test for invalid model state.. I can take the IHttpActionResult response from the controller invocation, and cast it to InvalidModelStateResult and iterate over the ModelState dictionary.
But, I find writing something similar for my 'production HTTP calls' with an actual HTTP client -- not as straightforward.
So, getting closer to the heart of my question:
Is there a preferred method for deserializing the InvalidModelStateResult?
So, when interacting with my API with actual http calls.. via the Microsoft.Rest.ServiceClient the JSON that I get back is in a slightly different shape..
Example MVC controller code interacting with my API:
HttpOperationResponse resp = await client.SpecialLocations.PatchByIdWithHttpMessagesAsync(id, locationType, "return=representation");
if (!resp.Response.IsSuccessStatusCode)
{
//The JSON returned here is not really in the form of an InvalidModelStateResult
ViewBag.Error = await resp.Response.Content.ReadAsStringAsync();
return View(locationType);
}
So, for now, I'm using Newtonsoft's JObject to parse ModelState returned from my WebAPI (again - it's not really named as such once retrieved via http request) and now pushing it into my MVC controller's ModelState.
This is my answer for now. But will consider others that have any merit. It just seems like a weird thing to have to do.
HttpOperationResponse resp = await client.SpecialLocations.PatchByIdWithHttpMessagesAsync(id, locationType, "return=representation");
if (resp.Response.StatusCode == HttpStatusCode.BadRequest)
{
string jsonErrStr = await resp.Response.Content.ReadAsStringAsync();
JObject err = JObject.Parse(jsonErrStr);
string[] valPair = ((string)err["error"]["innererror"]["message"]).Split(":".ToCharArray());
//now push into MVC controller's modelstate, so jQuery validation can show it
this.ModelState.AddModelError(valPair[0].Trim(),valPair[1].Trim());
return View(locationType);
}
How do you properly create a Web API POST of complex object or multiple parameters using Angular2?
I have a service component in Angular2 as seen below:
public signin(inputEmail: string, inputPassword: string): Observable<Response> {
return this.http.post('/api/account/signin', JSON.stringify({ Email: inputEmail, Password: inputPassword}), this.options);
}
The targeted web api is seen below:
[HttpPost]
[Route("signin")]
public async Task<IActionResult> Signin(string email, string password)
{
....
}
This does not work because I need to convert the parameters of the web api into a single POCO class entity with Email and Password properties and put the [FromBody] attribute: Signin([FromBody] Credential credential)
Without using [FromURI] (POST requests with query strings?), how can I make POSTs of multiple parameters or complex objects without converting these parameters into a single POCO class?
Because what if I have numerous Web API POST actions with parameters like (string sensitiveInfo1, string name, int sensitiveInfo2) or (ClassifiedInfo info, string sensitiveInfo1, string sensitiveInfo2), do I need to convert them all to POCO classes and always use [FromBody]?
PS.
I was using RestangularJS before and it can posts anything (mulitple primitive objects and complex objects) without my Web API actions having [FromBody] attributes. Will about to investigate how RestangularJS do it.
Without using [FromURI] (POST requests with query strings?), how can I make POSTs of multiple parameters or complex objects without converting these parameters into a single POCO class?
I know its not what you want to hear but out of the box this is not possible. It is not a limitation of the browser code that is making the request. This means it does not matter if you are using Angular, JQuery, straight JavaScript, or even RestangularJS. This is a limitation (I use that word loosely as I am sure this is by design) of Web API (any version). Here is the documentation on this design: Parameter Binding in ASP.NET Web API by Mike Wasson.
At most one parameter is allowed to read from the message body. So this will not work:
// Caution: Will not work!
public HttpResponseMessage Post([FromBody] int id, [FromBody] string name) { ... }
So the question becomes, what are your options?
Create a model
This is the thing you were trying to avoid but I list it first because this is how Web API was intended to behave. I have not yet heard a compelling reason not to do this. This approach allows you to extend your model easily without having to change the method signature. It also allows for model validation on the model itself. Personally I really like this approach.
public class SignInModel{
public string Email {get;set;}
public string Password {get;set;}
}
[HttpPost]
[Route("signin")]
public async Task<IActionResult> Signin(SignInModel signInModel)
{
// ....
}
I did not repeat your existing JavaScript code because what you have works as is with the above web api code
URL
Again, what you were trying to avoid. This does make what you want possible with the limitation that you have to pass these parameters using the Query string on the URL. The JavaScript would change but the signature you had on the Web API method would not.
public signin(inputEmail: string, inputPassword: string): Observable<Response> {
return this.http.post('/api/account/signin/?email=inputEmail&password=inputPassword', null, this.options);
}
I did not repeat your existing Web API code because what you have works as is with the above web JavaScript code (by default FromUri is assumed I believe)
Custom Model Binder
See Passing multiple POST parameters to Web API Controller Methods by Rick Strahl. This option allows you to create a custom model binder that could do what you are asking. It is a whole bunch of extra code though for, IMHO, not much benefit. Maybe there are situations where it would be useful although I really cannot think of any off the top of my head.
Dynamic
Finally you could also pass in a dynamic object as the parameter of your Web API. This is essentially the same as receiving the JSON as a string and making your Controller code responsible for the deserialization of content. Again, I believe that this would make your code worse in most situations as you have to implement custom validation and type checks. This answer was proposed previously on SO by Bes Ley. Again, maybe there are situations where it would be useful although I really cannot think of any off the top of my head.
If you call Web API 2.2 post method from Angular 2 type script, dont forget to add following header content and parameter object.
let headers = new Headers({ 'Content-Type': 'application/x-www-form-urlencoded' });
var params = new URLSearchParams();
params.set('userid', '102');
params.set('username', 'foo');
return this._http.post('http://localhost:6579/api/PostUser', params.toString(), { headers: headers }).map(res => res.json());
Perhaps you should post with options:
{
headers: new Headers({
'Content-Type': 'application/x-www-form-urlencoded'
})
}
and encode data like
jQuery.param({user:'bla', password: 'bla'});
WebAPI does not provide this out of the box. If you try to get understanding of web API bindings, you might be able to figure out why.
I think this article might help.
The generic rules are:
– simple, string-convertible parameters (value types, strings, Guids, DateTimes and so on) are by default read from URI
– complex types are by default read from the body
– collections of simple parameters are by default read from the body too
– you cannot compose a single model based on input from both URI and request body, it has to be one or the other
I have fixed the issue of Angular2 HTTP Post ASP.NET MVC Web API
let headers = new Headers();
headers.append('Content-Type', 'application/x-www-form-urlencoded; charset=utf-8');
let params: URLSearchParams = new URLSearchParams();
params.set('value', '2');
let options = new RequestOptions({
headers: headers//,
//search: params
});
let content = new URLSearchParams();
content.set('StudentName', 'Inderjit Singh';
content.set('Mobile', '+919041165398');
content.set('Nationality', 'Indian');
content.set('AdmissionNo', '6');
content.set('SectionCode', '1');
content.set('Gender', 'Male');
content.set('RegNo', '18585');
content.set('ClassCode', '1');
this.http.post('YOUR_URL', content.toString(), { headers: headers }).map((res: Response) => { console.log("data is==>" + res.text()); }).subscribe();
WebApi will be able to deserialize your Credential object provided the JSON object has the same field names (I am not sure about case so you may be right here). You seem to be missing the headers from the post call in your Angular2 component.
Can you check the Content-Type using Chrome Debugger or Fiddler? It should be application/json.
Try this, passing a complex class object into a single data parameter.
var SearchQuery = function () {
this.Alphabet = null;
this.Search = false;
this.Keyword = null;
this.RegionList = null;
};
var para = new SearchQuery();
{ data: JSON.stringify(para) } - Post Data
you can receive it using a JObject in your API controller and deserialize it as according to your classes.
I am building an ASP.NET Web API application that returns an Atom or an RSS feed. To do this, it builds a System.ServiceModel.Syndication.SyndicationFeed and a custom MediaTypeFormatter is responsible for handling the HTTP Accept Header, converting the SyndicationFeed to either an Atom10FeedFormatter or an Rss20FeedFormatter, and streaming the result to the response stream. So far, so good.
My controller looks something like this:
public class FeedController : ApiController
{
public HttpResponseMessage Get()
{
FeedRepository feedRepository = new FeedRepository();
HttpResponseMessage<SyndicationFeed> successResponseMessage = new HttpResponseMessage<SyndicationFeed>(feedRepository.GetSyndicationFeed());
return successResponseMessage;
}
}
What I would like to do is make use of the built-in OData querying to filter my feed, but changing the return type of the Get() method to IQueryable<SyndicationFeed> obviously will not work since a SyndicationFeed does not implement IQueryable.
Is there a way to use the built in OData querying on the IEnumerable<SyndicationItem> property on the SyndicationFeed?
This question is no longer relevant, since Microsoft remove the rudimentary support for OData querying that was in the Beta build of Web API.
A future version will include more complete OData support. There is an early build of this available via CodePlex and NuGet and there are more details here: http://blogs.msdn.com/b/alexj/archive/2012/08/15/odata-support-in-asp-net-web-api.aspx
The System.Linq namespace provides an extension method named AsQueryable to the IEnumerable interface. Your code would look along the lines of this:
public class FeedController : ApiController
{
public IQueryable<SyndicationFeed> Get()
{
FeedRepository feedRepository = new FeedRepository();
//TODO: Make sure your property handles empty/null results:
return feedRepository.GetSyndicationFeed()
.YourEnumerableProperty.AsQueryable();
}
}
You don't have to return IQuerable from controller when working with OData.
Check "Invoking Query Options Directly" section at https://learn.microsoft.com/en-us/aspnet/web-api/overview/odata-support-in-aspnet-web-api/supporting-odata-query-options
For your case it will looks like:
public SyndicationFeed Get(ODataQueryOptions<SyndicationItem> opts)
{
var settings = new ODataValidationSettings();
opts.Validate(settings);
SyndicationFeed result = feedRepository.GetSyndicationFeed();
result.Items = opts.ApplyTo(result.Items.AsQuerable()).ToArray();
return result;
}