I have the following JSON
{"name":"tester1","type":"frontend"}
{"name":"tester2","type":"midlleware"}
{"name":"tester3","type":"backend"}
When I paste the above into Postman with an application/JSON, only the 1st row/JSON will be passed to the function because of the lack of commas between each row. Note, I cannot change the incoming JSON format nor the Content-Type (application/JSON). Also note this is a valid multipart JSON
See here
My API method is as follows:
public async Task<HttpResponseMessage> ProcessJson([FromBody] string _incomingJSON)
Note: I can change my signature ([FromBody] string _incomingJSON)
_incomingJSON is null if I use application/JSON but populated if I use text/plain (which I can't use)
Is there any way I can handle this format with application/JSON and not get _incomingJSON as null?
Thanks in advance
You should send with Postman in 3 rows like this:
Related
I have a Controller that can receive Post requests.
public IHttpActionResult PostCreaAlimento([FromBody] Alimento alimento)
{
if (!ModelState.IsValid)
return BadRequest("Invalid data.");
return _repositorio.CreaAlimento(alimento) ? Ok(alimento) : (IHttpActionResult)NotFound();
}
The request is correctly done on swagger, and I receive a response code 200.
But, if I try to do the same on POSTMAN, I receive an Unsupported Media File.
Request on POSTMAN
Why is this not working :/
Since you are using [FromBody] in the action it means that you need to send application/json contentType
so select Body=> raw => json and put this in the body of Postman
{
"AlimentoId":4,
"Description":"testing",
"Calorias" :400
}
Please try raw, not form-data. Ensure that you choose JSON. Next prepare your data as a json object.
You pass json data as form data but your controller accepts request body data as raw data. You should change body type as raw data.
I am using postman to test my .net core API, when i am trying to post data via postman form-data this returns a 415 even if i set the Content-Type header to application/json as the common solution for this issue appears to be online.
If i fire the request without any files via the raw postman option and set the content type as JSON(application/json) this request reaches the API successfully.
Here is how my API looks:
[HttpPost("{organization}")]
public IActionResult Post([FromBody] Asset asset, string organization)
{
//Api body
//Get files from request
Task uploadBlob = BlobFunctions.UploadBlobAsync(_blobContainer,Request.Form.Files[0]);
}
And here is how the failed postman request looks like
and the header for that request
What else am i missing for this to work?
Small update
This works fine if i remove [FromBody]Asset asset and just pass the file
Try using the [FromForm] attribute instead of the [FromBody] attribute:
[HttpPost("{organization}")]
public IActionResult Post([FromForm] string asset, string organization, IFormFile fileToPost)
{
//Api body
Asset asset = JsonConvert.DeserializeObject<Asset>(asset);
//Get files from request
Task uploadBlob = BlobFunctions.UploadBlobAsync(_blobContainer, fileToPost);
}
I can't say for sure, but my guess is that in postman, since you're making a form-data request, your content-type would end up being "multipart/form-data" (if you debug the request when it is being processed, you can see that the content type changes to multipart even though you set it to application/json).
But in your Controller's POST action you specify that you expect an Asset object from the body (which expects a JSON object by default). So you get a 415 since your request's content type is multipart while your API expects application/json because you used the [FromBody] attribute.
Turns out that for some weird reason I was not allowed to pass any of them as a variable of my controller but it works if I retrieve both from the Request.
if (!Request.Form.ContainsKey("asset"))
{
return BadRequest("Asset cannot be empty");
}
Asset asset = JsonConvert.DeserializeObject<Asset>(Request.Form.First(a => a.Key == "asset").Value);
and for the file
var file = equest.Form.Files[0]
Not sure why this is the case and would appreciate if someone could explain this to me but this seems to solve my issue.
I'm using RestSharp to make a call to REST service. My call looks something like this:
var request = new RestRequest("/foo", Method.POST);
request.JsonSerializer.ContentType = "application/json; charset=utf-8";
request.AddJsonBody(new string[] { "param1", "param2" });
var response = this._client.Execute<Foo>(request);
For most other calls this works fine. I'm running into issues when the response is compressed. The headers in the response look (mostly) like this:
HTTP/1.1 200 OK
Uncompressed-Size: 35000
Content-Length: 3019
Content-Encoding: deflate
Content-Type: application/json
The issue is when I call this method with RestSharp I keep getting the error:
Error: Block length does not match with its complement.
I've tried setting the Accept-Encoding header in the request but it still produces the error. I also tried using a custom deserializer but the error is occurring before deserialization. From what I can tell, RestSharp should automatically handle deflation if the Content-Encoding header says deflate (which it does).
How can I get RestSharp to handle the deflation properly?
UPDATE
In the end I was able to have the service changed to look for an Accept-Encoding header in the request with a value of identity. If found, the service was changed to return the data uncompressed.
This is unfortunately not really a solution to the original issue but it does resolve the problem for me. If a better solution is posted I will try it.
According to this post, you should be able to handle it if you won't pass charset=utf-8 in content type.
Please refer to this:
RestSharp compress request while making rest call to server
I have an ashx processing POST of a form on my website.
Most of the time, I am sent data with content-type x-www-form-urlencoded.
If my user is under IE8/9, I have to use XDomainRequest object instead of the usual XmlHttpRequest.
In the first case, I use context.Request.Form["..."] to read the datas, but HttpRequest.Form is only populated if content-type is x-www-form-urlencoded.
In the IE8/9, XDomainRequest only support plain/text content-type, hence I'd have to use HttpRequest.Querystring to get the datas.
My question is : Is Querystring populated when the content type is x-www-form-urlencoded ?
Really struggling with something I hope people here can help with. I'm writing a RESTful API in Web API 2. Whenever I send a request to this service, the response is consistently being sent with a Content-Type of text/plain. Obviously this is no good, my response needs to be Content-Type of application/json. I've tried a few suggestions that I found from Google but I don't think I'm understanding the whole picture.
Is there something special I need to do in order to have my web service respond with application/json content? Note that I want this to work globally across the whole app, so I'm not after a way to modify a given response and set its content type - I want this to be a default behaviour for the whole web service: If a request contains an Accept header for application/json I want my web service to return that Content-Type instead of text/plain.
Edit to clarify:
My response contains an object called "responseData" that should be serialized into JSON and included in the body. I'm currently putting together my response like this:
HttpResponseMessage response = Request.CreateResponse(HttpStatusCode.OK, responseData);
return response;
responseData is a POCO. This get's correctly serialized as JSON and returned in the response - the only missing part is the Content-Type which is incorrectly set to "text/plain". I could manually change this on every single response I compose, but I'm wanting to configure this on a global level.
OK, assuming that your responseData is a string, the Content-type header will be text/plain when you create the HttpResponseMessage. Doesn't matter what the contents of the string are, since no attempt is made to determine this.
The solution is to create the appropriate Content object for your message, initialized with the media type you're returning:
HttpResponseMessage response = new HttpResponseMessage()
{
Content = new StringContent(
responseData,
Encoding.UTF8,
"application/json"
)
};
There are other methods that amount to returning a particular object type and letting the API libraries serialize to JSON or XML for you as required. I prefer to let the framework do the work for me where possible, but this is how you'd achieve it with a string you've created yourself.
For a strict JSON-only result, remove the XML formatter from the WebAPI configuration and return your POCO.
In App_Start\WebApiConfig.cs, add the following to the WebApiConfig.Register method:
config.Formatters.Remove(config.Formatters.XmlFormatter);
And for your API:
public class MyObject
{
public bool result;
public string reason;
}
public class TestController : ApiController
{
public MyObject GetData()
{
MyObject result = new MyObject { result = "true", reason = "Testing POCO return" };
return result;
}
}
I ran this up and requested /api/Test from Chrome, which doesn't even mention application/json in the Accept header. Here are the response headers up until it hits Content-Type:
HTTP/1.1 200 OK
Cache-Control: no-cache
Pragma: no-cache
Content-Type: application/json; charset=utf-8
And the body:
{"result":true,"reason":"Testing POCO return"}
Since I disabled XML it defaulted to JSON.
Add the following to Global.asax file.
protected void Application_Start()
{
JsonSerializerSettings serializerSettings = new JsonSerializerSettings();
serializerSettings.Converters.Add(new IsoDateTimeConverter());
var jsonFormatter = new JsonNetFormatter(serializerSettings);
jsonFormatter.SupportedMediaTypes.Add(new MediaTypeHeaderValue("text/html"));
GlobalConfiguration.Configuration.Formatters.Insert(0, jsonFormatter);
}
Another possible source of the issue described is that there may be an authorization redirect in play as was the case for us when one of the engineers thought to re-use user authentication for an api.
This means incoming requests were being redirected to a login page which was the text/html response that couldn't be parsed by ReadAsync<>. A silly mistake to be sure, but not an easy one to spot.
The solution in that case was to remove the user authentication and implement HMAC based authentication for the api.