Once upon a time in Web Api 2 I could write such an action:

public class INP { public string value { get; set; } } public string Post(INP con) { return con.value; }

and everything worked fine with both ContentType: application/x-www-form-urlencoded sent from the client and ContentType: application/json .

However, in asp.net core everything is not so simple: with the above code ContentType: application/x-www-form-urlencoded works, but ContentType: application/json leaves me just null in the code. If you frame the parameter with the [FromBody] attribute, then the situation changes: everything is fine with ContentType: application/json , but with ContentType: application/x-www-form-urlencoded I get an answer like 415 Unsupported Media Type .

So, the question itself: how to write an action in asp.net core, which would take me to the parameter of different ContentType , as it was in Web Api 2? And why has the behavior changed?

    1 answer 1

    This question can be solved in this way: you need to create two different Action methods that can specifically bind the data necessary for sending, and then delegate the processing of calls to a common method.

    For example:

     public class MyController : Controller { //для ContentType: application/x-www-form-urlencoded [HttpPost] public IActionResult Index(MyClass myclass){ return DoSomething(myclass); } //и для ContentType: application/json [HttpPost] public IActionResult IndexFromBody([FromBody] MyClass myclass){ return DoSomething(myclass); } private IActionResult DoSomething(MyClass myclass){ // сделай тут что нибудь с myclass // ... // ... return Json(myclass); } }

    Why Change?

    Wasn't it easier before? Maybe, but according to Damian Edwards in the Standup community, the main reason is security, in particular, the prevention of Cross-Site Request Forgery (CSRF) .

    UPDATE

    You have to solve this problem by routing, but if you try to display the above two actions along the same route, this will result in an error. The solution to this is to create a custom route and call the appropriate method on the header. I understand that this requires more effort than it is worth, but they say that these changes are for security reasons, I did not study in depth exactly how this prevents CSRF. You can google or look here .

    • this is not exactly the solution, since when calling such a rest api, the routing system cannot choose one of the two Post-methods. How does this help prevent CSRF? - Qutrix
    • I updated the answer. - SᴇM
    • "The solution to this is to create a custom route and call the appropriate method for the title" - from this sentence, I did not understand much, can I elaborate? - Qutrix
    • one
      1. What does the CSRF, the same post-request. 2. x-www-form-urlencoded after all in the body, and not in the address. 3. How is json safer? - Qwertiy ♦
    • From the curves of hands and misunderstanding of the topic of development will not save anything, but more often such alleged security fixes are seen everywhere - in all frameworks of all languages. Maestro programming, establishing the rules, thereby trying to improve the quality of the code, increasing its complexity? What is the reason for this trend? - Goncharov Alexander