After reading this blog post on how to return HTML from Web API 2 using IHttpActionResult, I wanted to somehow "wire-up" this IHttpActionResult to my ApiController based on the Accept header that is sent with request.
Given controller actions that have signature similar to this:
public MyObject Get(int id)
{
return new MyObject();
}
If the request specifies the Accept: text/html, this IHttpActionResult should be used to return HTML. Is that possible? In addition, some insight on how this content negotiation pipeline works for json or xml (that have built-in support) would be greatly appreciated.
If we keep the discussion of IHttpActionResult aside for a momment, Content-negotiation process in Web API is driven through formatters. So you would need to create a new formatter for handling the media type text/html.
Web API exposes the default algorithm it uses for content-negotiation called DefaultContentNegotiator which is an implementation of the service IContentNegotiator.
Now this negotiation algorithm can be run either by Web API automatically for you like in the following cases:
Usage # 1:
public MyObject Get(int id)
{
return new MyObject();
}
OR
you can manually run the negotiation yourself like in the following:
Usage #2 :
public HttpResponseMessage Get()
{
HttpResponseMessage response = new HttpResponseMessage();
IContentNegotiator defaultNegotiator = this.Configuration.Services.GetContentNegotiator();
ContentNegotiationResult negotationResult = defaultNegotiator.Negotiate(typeof(string), this.Request, this.Configuration.Formatters);
response.Content = new ObjectContent<string>("Hello", negotationResult.Formatter, negotationResult.MediaType);
return response;
}
Regarding IHttpActionResults:
In the following scenario, Ok<> is a shortcut method for generating an instance of type
OkNegotiatedContentResult<>.
public IHttpActionResult Get()
{
return Ok<string>("Hello");
}
The thing is this OkNegotiatedContentResult<> type does similar thing as in Usage # 2 scenario above. i.e they run the negotiator internally.
So to conclude, if you plan to support text/html media type then you need to write a custom formatter and add it to Web API's formatter collection and then when you use Ok<string>("Hello") with an Accept header of text/html, you should see the response in text/html. Hope this helps.
Related
We have a .netcore 3.1 ApiController with an endpoint listening for PATCH requests, and defined a Test Server that we're using for the Integration/API tests.
PATCH request sent with Postman works just fine, but requests sent via HttpClient inside the XUnit tests are failing with 415 Unsupported media type.
Postman Patch request:
No specific headers other than Bearer token and Content-Type: "application/json"
In the tests, we use WebApplicationFactory and it's factory.CreateClient() for our HttpClient.
It shouldn't be an issue with Json Serialization since I looked into the content through debugger and it seems to be serialized just fine.
Also, our POST methods work completely out of the box with this exact same code (replacing "PATCH" with "POST" etc)
Looking forward to some advices. Also if you need any more info, please let me know. Thanks a lot.
Controller:
[HttpPatch("{id}")]
public async Task<ActionResult<Unit>> Edit(Edit.Command request)
{
return await Mediator.Send(request);
}
Command:
public class Command : IRequest
{
public string Id { get; set; }
public JsonPatchDocument<ObjectDTO> PatchDocument { get; set; }
}
Test:
[InlineData(/* inline data goes here */)]
public async void TestEdit_Ok(/* required parameters for the test */)
{
var request = new HttpRequestMessage(new HttpMethod("PATCH"), url));
request.Headers.Add("Authorization", "Bearer " + token);
/* create patch document logic goes here */
var command = new Command()
{
Id = target,
PatchDocument = patchDocument,
};
_testHelper.AddJsonContent(request, command);
// Act
var response = await _client.SendAsync(request);
// Assert
Assert.Equal(HttpStatusCode.OK, response.StatusCode);
}
Where helper method AddJsonContent is defined as:
public void AddJsonContent(HttpRequestMessage request, object content)
{
request.Headers.Accept.Add(new MediaTypeWithQualityHeaderValue("application/json"));
string serializedContent = JsonConvert.SerializeObject(content);
request.Content = new StringContent(serializedContent, Encoding.UTF8, "application/json");
}
just wanted to say that, while I see this is a confirmed bug, I think once we used full url http://localhost:PORT/endpoint in the client instead of just /endpoint, we didn't encounter this issue anymore. This is the same as one of the proposed workarounds on github issue.
I see the ticket Vadim linked is still open so this may fix the issue for some of you.
Thanks for the help.
The problem is confirmed in Asp.Net Core 5.0
(the problem confirmed by me — I have the same problem as the topic starter)
The PATCH method returns the "415 Unsupported Media Type" status, when using the xUnit with WebApplicationFactory and factory.CreateClient() for HttpClient.
All possible attempts in different combinations results the 415 status.
However, other means like Swagger and Postman work well with the PATCH methods.
Only the xUnit (or WebApplicationFactory) PATCH method fails.
Finally, to conduct the testing, we made a workaround with POST methods, which contain /with-partial-update as a route part.
This bug is reported to aspnetcore repository
When you return a response form an asp .net core controller you can return data in two ways (there may be more but I am just focusing on these two). My question is what is the difference between the two methods (if any); return a value vs writing directly to the body?
[HttpGet("Fetch_Write")]
public void Fetch_Write()
{
HttpContext.Response.ContentType = "application/json";
var s = Encoding.UTF8.GetBytes(JsonConvert.SerializeObject(new { data = "my_fetched_data" }));
HttpContext.Response.Body.Write(s, 0, s.Length);
}
In the method above the return type of the function is void and I am writing a content directly to the response body, but the version below my function returns a string. When using postman I get the same response from both api calls, is there a difference between the two? Should I use one over the other?
[HttpGet("Fetch_Return")]
public string Fetch_Return()
{
HttpContext.Response.ContentType = "application/json";
return JsonConvert.SerializeObject(new { data = "my_fetched_data" });
}
My guess is is that the function that returns a string does something similar later down the line where it writes the content to the body as I have done in the first code snippet function but I am not sure.
There isn't much difference. But in practice you should avoid both as it's boiler plate and doesn't fully utilize ASP.NET Core MVC tooling.
It's best to use IActionResult instead as return type and use either the helper methods (Ok, BadRequest, NotFound, File etc.) or directly create the OkObjectResult/OkResult classes and return them. This allows you to set status codes and let ASP.NET Core choose the correct formatter (XML or json, later on maybe even OData, protobuf or even custom formatters) which depend on accepted header of the caller.
For example:
[HttpGet("Fetch_Return")]
[Produces("application/json"),Produces("application/xml")]
public string Fetch_Return()
{
return Ok(new { data = "my_fetched_data" });
}
[Produces("application/json"),Produces("application/xml")] will only allow XML and json formatting. So if a user calls this action with Accept: application/xml he will receive an xml file and if he calls with Accept: application/json. If you request application/text, the browser will return Http Code 415 "Unsupported Media Type".
Is it possible to send [FromBody] POST data to a controller using client.GetAsync() (or PostAsync/SendAsync?
I had to set up a base controller that all api calls will go through.
My ajax calls all go to this SecureApi controller, and they send the original path as a parameter to that they can be re-routed to the correct controller. Something like:
$.ajax({
url: "./api/SecureApi/?path=/api/OtherApi/SomeRoute",
data: {
param1: 1,
param2: 2
}
});
So my base controller looks something like:
public class SecurityApiController : ApiController
{
[HttpPost]
public HttpResponseMessage SecureApi([FromBody]object data, string path)
{
// do some stuff
// get uri
var applicationPath = Request.RequestUri.Scheme + "://" + Request.GetRequestContext().VirtualPathRoot.Replace("/", String.Empty);
Uri routeUri = new Uri(applicationPath + path);
// then redirect to correct controller
var config = new HttpConfiguration();
var server = new HttpServer(config);
var client = new HttpClient(server);
// how can I send [FromBody]object data here?
var response = client.GetAsync(routeUri).Result; // or PostAsync/SendAsync?
return response;
}
}
The other controller looks like:
public class OtherApiController : ApiController
{
[HttpPost]
public HttpResponseMessage OtherApi([FromBody]OtherData data)
{
// do stuff
}
}
Unfortunately I can't change OtherApi, so I HAVE to send the [FromBody] POST data in the same way (in the POST body).
Is that possible?
EDIT:
Per #Philippe's response below, I'm using PostAsJsonAsync and it seems to want to work, but I'm getting a 401 Unauthorized result. More info:
I went with the correct(?) ASYNC/AWAIT route...
public async Task<HttpResponseMessage> SecureApi([FromBody]Dictionary<string, dynamic> data, string path)
{
...
var client = new HttpClient();
var response = await client.PostAsJsonAsync(routePath, data);
return response;
}
And the Other controller has:
[Authorize(Roles = "Admin")] // I do have the "Admin" role
[Route("Save")]
[HttpPost]
public SaveResultBase Save([FromBody]Dictionary<string, dynamic> data)
{
...
}
But this controller is never hit (no breakpoints are hit there) and it returns a 401 Unauthorized response.
I guess that I have to add my user credentials to the client headers before calling PostAsJsonAsync. Can't find any way to do that though.
The method GetAsync of HttpClient will send a HTTP GET request so it would only be possible to have [FromUri] arguments. Because [FromBody] argument are by definition POST data, you will want to use PostAsJsonAsync/ PostAsXmlAsync/PostAsync. The difference between all of them is how the data is serialized.
var response = client.PostAsJsonAsync(routeUri, data).Result;
That being said, if you have security in mind, it would be rather easy for anyone to call the "right api" directly. Moreover you will increase latency by generating two HTTP requests.
You should take a look at this guide on MSDN. I believe that an authentication filter is probably what you are looking for.
I would like to set ServiceStack's default format to JSON, as opposed to the HTML formatted response it normally returns when a service is accessed from a browser. I know this can be specified on each request by sending a ?format=json parameter or setting the Accept header to application/json. Is there a way to change this without having to rely on these hints from the request?
In addition to specifying it on the QueryString with ?format=json, by appending the format .ext to the end of the route, e.g: /rockstars.json, or by specifying the HTTP Header (in your HttpClient): Accept: application/json.
Otherwise if your HttpClient doesn't send an Accept header you can specify JSON as the default content type in your AppHost with:
SetConfig(new HostConfig {
DefaultContentType = MimeTypes.Json
});
All Configuration options in ServiceStack are set here.
The issue when calling web services from a web browser is that they typically ask for Accept: text/html and not JSON which by contract ServiceStack obliges by returning back HTML if it is enabled.
To ensure JSON is returned you may also want to disable the HTML feature with:
SetConfig(new HostConfig {
EnableFeatures = Feature.All.Remove(Feature.Html),
});
Different ways to specify the Response Content Type
Otherwise if you want to override the Accept header you can force your service to always return json with any of these ways to Customize the HTTP Response, e.g:
Using a filter (AddHeader is built-in):
[AddHeader(ContentType=MimeTypes.Json)]
public object Any(Request request) { ... }
Setting the Response in the service:
public object Any(Request request)
{
base.Response.ContentType = MimeTypes.Json;
return dto;
}
Returning a decorated response:
return new HttpResult(dto, MimeTypes.Json);
I use the PreRequestFilter to force JSON responses to a browser. You still see the ?format=json on the querystring, but it's useful if you've disabled html & xml.
this.PreRequestFilters.Add( (req, res) =>
{
const string queryString = "format=json";
var jsonAccepted = req.AcceptTypes.Any(t => t.Equals(ContentType.Json, StringComparison.InvariantCultureIgnoreCase));
var jsonSpecifiedOnQuerystring = !string.IsNullOrEmpty(req.QueryString["format"]) && req.QueryString["format"].Equals("json", StringComparison.InvariantCultureIgnoreCase);
if (!jsonAccepted && !jsonSpecifiedOnQuerystring)
{
var sb = new StringBuilder(req.AbsoluteUri);
sb.Append(req.AbsoluteUri.Contains("?") ? "&" : "?");
sb.Append(queryString);
res.RedirectToUrl(sb.ToString(), HttpStatusCode.SeeOther);
res.Close();
}
});
Late to the question, but since I couldn't find the answer anywhere, I finally figured it out from ServiceStack's source code :)
The simplest way I found to default to Json instead of Html from the browser was this:
HttpRequestExtensions.PreferredContentTypes = new[] { MimeTypes.Json, MimeTypes.Xml };
Call this at the startup of your app, and it will override default's ServiceStack mime types and start with json (which will work with your browser's requests since / will match it).
Note that you should still disable Html and make Json the default mime type:
SetConfig(new HostConfig {
DefaultContentType = MimeTypes.Json
EnableFeatures = Feature.All.Remove(Feature.Html),
});
For the curious: ServiceStack uses internally HttpRequestExtensions.GetResponseContentType (see HttpRequestExtensions.cs), which loops through preferred content types. Because it contains MimeTypes.Html, it will catch the first accept type from the browser (text/html) and ignore whatever is coming after. By overriding this, text/html is not seen as a preferred content type, and it then skips to */* which defaults to json as expected.
What is the better way to upload a file for a REST client?
From the WCF Web API Documentation
[WebInvoke(UriTemplate = "thumbnail", Method = "POST")]
public HttpResponseMessage UploadFile(HttpRequestMessage request)
{
From multiple forum posts:
WCF REST File upload with additional parameters
[WebGet(UriTemplate="", Method ="POST"]
public string UploadFile(Stream fileContents)
I understand, that the first method allows to directly post a file from a normal HTML form. The 2nd approach seems more common on all forum posts I find.
What would you recommend and why? The REST api should be accessible from all kind of languages and platforms.
For the HttpRequestMessage approach, how would I do an upload a file preferable with the WCF HttpClient? With the FormUrlEncodedMediaTypeFormatter)
In order to test the HttpRequestMessage approach I have done the following using MVC:
public class TestingController : Controller
{
public ActionResult Index()
{
return View();
}
public ActionResult Upload()
{
var file = Request.Files[0];
var filename = Request.Form["filename"];
var uri = string.Format("http://yoururl/serviceRoute/{0}", filename);
var client = new HttpClient();
client.DefaultRequestHeaders.Accept.Add(new System.Net.Http.Headers.MediaTypeWithQualityHeaderValue("image/pjpeg"));
var content = new StreamContent(file.InputStream);
var response = client.PostAsync(uri, content);
ViewBag.ServerUri = uri;
ViewBag.StatusCode = response.Result.StatusCode.ToString();
return View();
}
}
The Index view should have a form in it that posts back to the Upload method. Then you are able to use the HttpClient to make a connection to your REST service.
The first method is "closer to the metal" and would be more flexible since you would be processing the http requests and building the responses yourself. If all you need to do is accept a stream from a client, the second option is much simpler from the implementation standpoint (under the hood, it does the same work that the first method is doing)
I don't have an answer for your last question.