Develop Reference

WebAPI CORS Policy when Creating new record

I have a React frontend connecting to a .NET CORE WebAPI, I'm able to call, GET, Delete, and Create in one controller with no issues, however, on another controller, when I call the Create I get the CORS policy error message. What would cause the error in one controller and only the Create? I can call the Get and Delete with no issues, I can also call the Create from PostMan with no issues, just when I call it from my React App.
Create Code: (this works when I test it from Postman, I'm connecting to the API on my Local host for the time being, and only this one controller in the WebAPI is kicking me out the CORS policy error and only on the Create Call)
public IActionResult Create(CarDetails, details)
{
db.CarDetails.Add(details);
db.SaveChanges();
return Ok(details.DetailsId);
}

PostMan ignores CORS headers and will just not care about them. That is a reason for PostMan working while the browser does care.
With that said I do no really know why your API stops one request and not the other. Are there differences in the headers?
I think your problem would have a higher chance of getting solved when asked in a .NET forum. CORS errors are caused by settings for your backend/api host and not caused by React/JS/Client side code.
You might need to allow more headers, open up localhost:3000 or some other setting.

I got it working. once I added this to my API call file, it worked:
headers: {
"Content-type": "application/json"
}

OAuth 1.0 default request token URL in Postman, how to obtain?

Maybe title is not that clear but..
I have created a POST query that works in Postman using OAuth 1.0 authentication.
Mu calls are made to url:
https://lo.enghist.liveperson.net/abc/api/def/1234567/ghi/search
How does postman know all other urls - to request token url etc.
I’m trying to rewrite it in a custom C# app but have no idea how to track what happens when I click send - if I go to Developer Console I only see the final request with final params that were obtained somewhere?
Is it always sth default like:
https://lo.enghist.liveperson.net/oauth/request_token

Answering myself:
I didn't correctly understand OAuth 1.0. I first thought that there is a different URL that we make calls to receive the token which we then use to make the final call. This is not the case, we create our token using secrets, nonce (random string) and few other rules, then it's all hashed and sent to WebService which does the same and compares both values.
Postman now provides you with code - below the button "Send" there is a link "Code" which gives you so many languages and one of them is C# using RestSharp.
Regarding above, it sadly shows a semi working solution - quite a lot of logic is skipped and all the values are precalculated so I was thinking I need to calculate them myself even if RestSharp can do that for you, please check my final working code here:
https://stackoverflow.com/a/64819771/1619684

Web API GET vs POST

I initially setup a Web API (not any expert with web api) and followed someone's tutorial online for passing in parameters to a simple get API call.
I had originally created a GET with query strings but as the tutorial showed how using POST allows me to pass JSON to an class object in POST API parameter, it seemed a good idea.
Later on one developer said this was bad practice? Is it? Should I always use GET instead of POST which in essence is what it should be anyway... a GET call, but I like the idea of passing parameters via an object and avoiding a long API call with query strings.
So:
$.ajax({
url: '\api\getlist\1?param2=yyyy&param3=kikkkk&param4=88' etc
})
or
var params = ....
$.ajax({
url: '\api\getlist\',
data: params
})
What should I do, change the code back to using GET? What about caching?

You should take a look at the http documentation in w3c.
GET is recommended for reading data and POST is used to send information (write operations) into the server.
From client side perspective, you could set in jquery ajax setup, to do not use cache with the follow code:
$.ajaxSetup({
cache: false
});
It will generate a random argument on the async request to make a different request everytime, add a parameter like this: ?_=31312312312.

Restful PUT acting as GET when testing

So I've been working on an api that, using RESTful, allows the user to get data from a database. Pretty simple, URL is along the lines of local:port/projects/[id of project]. The api returns some xml with 4 or 5 results.
What I'm having trouble with is PUT. As far as I understand it, I should use the same url, but use the PUT request method, and include the data that I want sent in a parameter. The problem seems to be that when I run the PUT, it just returns the same data as a GET.
I'm using the following site to test this: wst dot mytechlabs dot com (won't let me post two links here;?)
The code for my controller is located here: http://pastebin.com/3HXXR4YY
Thanks in advance, I'll monitor this, so let me know if I forgot any info that would help.

How to check what URL a RedirectToRouteResult will make?

In my asp.net-mvc project I do a redirect from a post request to a get request.
In between my redirect and my arrival of the method I expect it to arrive, one of my parameters magically turns into null and I can't figure out why.
Probably it has something to do with my global.asax (route defenition).
The only way I can come up with to debug this is with the route debugger library. But I don't see how I can use it with a RedirectToRoute.
Any suggestions?

A little late to the party but this was the first hit on Google for an issue I was having so thought I'd share my experience.
I wanted to parse a RedirectToRouteResult to a URL so I can redirect to it at a later stage, but this class has no method to do this. You can, however, use UrlHelper.RouteUrl(), e.g:
Url.RouteUrl(redirectResult.RouteName, redirectResult.RouteValues);
where Url is property of Controller class.

A redirect is a result sent to the browser, and then the browser honors the redirect by doing a GET on the new URL. Therefore, look at the browser to see what the URL is. When the browser receives the redirect, it will do a GET on the new URL, which you can see with Firebug, Fiddler, or the tool of your choice.
Inside the new action, when it is called, you can also examine Request.Url.