CODEWITHSUNDEEP
javascriptreactjspostmanodata
OhLongJohnson
OhLongJohnson

Reputation: 33

Postman and Chrome different API responses

I have been making the exact same API request one from postman and one from a react app which is located in localhost so on my machine but when I evaluate the response I get different results between the two.

The request contains odata commands and looks like this:

Articles?$expand=Category&$select=Category

The authorization is over a bearer token which I already checked and is correct in both request and the headers and URL are the exact same too.

The only thing different is the response where chrome is missing a few entries inside an array which is supposed to contain these Category fields which are JavaScript objects.

The response body looks like this:

{
    "@odata.context": ... , value: [
        {
            Category: ...
        }
    ]
}

What is missing is some of the category objects that are there in postman so basically postman is working as intended.

Also for some reason the request appears two times in the network tab one time as OPTIONS and one time as GET which I don't know why either. Somebody good a clue what the culprit could be in this situation?

Upvotes: 1

Views: 7323

Answers (2)

One with the Internet
One with the Internet

Reputation: 1

For me the issue was a difference between the request.body sent to the API from Postman and the request.body sent from my frontend app. The one sent from my app had a missing field.

Hope this helps.

Upvotes: 0

T.J. Crowder
T.J. Crowder

Reputation: 1074168

Postman and a browser are different things. Clearly, the service you're querying is differentiating the requests and returning slightly different results based on the source of the request. The details of the requests (headers, etc.) are probably slightly different.

Also for some reason the request appears two times in the network tab one time as OPTIONS and one time as GET which i dont know why either. Somebody good a clue what the culprit could be in this situation?

That's because you're making the request from a web browser, and so the Same Origin Policy comes into effect. The browser sends a "preflight" request via OPTIONS to the server, which apparently returns appropriate CORS headers to allow the main request, and so then sends the main GET request. See:

Upvotes: 2

Related Questions