Different behaviour: Postman / Java Http call
?Hi, i have a strage behaviour with /Search/HistoricalCriteriaSearch
In Java and in Postman I make the following request, this is the body (header is also the same):
{"Request":{"RicPattern":"FGBLH6","CurrencyCodes":["978"],"ExpiryDate":{"Start":"2016-03-01T00:00:00.000Z","End":"2016-03-31T00:00:00.000Z"},"Range":{"Start":"2017-02-03T09:06:12.113Z","End":"2017-02-03T09:06:12.115Z"}}}
In Postman I get an http 200 and an empty result. In the Java call I get:
Response Code : 502 / {"error":{"message":"Gateway ETH returned error status code: BadRequest from (http://rp.cp.hdc.reuint.com/TickHistoryWS/search) Error ID: [ca49310a-fdcd-49fc-93f5-3a232e031aba]"}}
Maybe there is something wrong in the request, I'm currently investigating that, but that is not my current questions. My question is: how is it possible to get different behavior between Postman and Java Http calls?
Best Answer
-
I have advanced this case against an open REST API bug. I believe the reason you got the 502 failure was because Currency Code "978" is not a valid code from the Historical Currency list. Note: In the future when the bug is fixed, you will received a 400 reply with a error message saying something about the value provided was invalid.
I am not sure why you would not have received a 502 to all requests that specified that same code. Each response will have an X-Request-Execution-Correlation-Id HTTP header. If you can provide that information per troubled call then I can investigate the specific operations that lead to the undesirable outcome.
0
Answers
-
Other previously working tests are now also failing, i therefore investigated a bit deeper. Looks like this type of request is not working if authentication request and search request are performed very close after each other. In debug mode (where there is more time in between) it is working fine.
Can you please confirm if that is the correct reason for this situation and please advice how to handle it on customer/client side?
0 -
Just FYI, returned HTTP Status codes are documented here.
502 is a BadGatewayException, meaning that the server, while acting as a gateway or proxy, received an invalid response from the upstream server it accessed in attempting to fulfill the request.
I do not know if your hypothesis is correct or not, I hope the dev team can clarify this.
0 -
My hypothesis is of course just a hypothesis. I was just able to reproduce the behavior in normal (full speed) JUnit test run and not in debug where i was steeping manually. Also i was not able to reproduce this behavior using postman, where the authentication was done early in the morning. That's why I guess there must be some relation between authentication and request. That is the only difference between the JUnit run and the Postman request.
0 -
You say "Currency Code "978" is not a valid code" but why is this request then working fine in Postman? I really think the issue it the time between authentication and request. That is the only difference between running my test case in normal and in debug mode.
0 -
I agree your observation requires some additional thought - I already pondered it a bit the first time, but meant to come back to it to figure out why that might be true. I hope to get to that tomorrow. Are correct values working for you now, or even with correct values do you see trouble?
0 -
Thanks for your help. This behavior was always occurring with correct values. That's why I'm so worried about it. I tested always with the same (generally working) request.
If it helps I can try to reproduce the situation today again, just let me know.
0 -
I cannot explain it - when I issue that identical request via Fiddler, I always get back an empty result here too:
{"Request":{"RicPattern":"FGBLH6","CurrencyCodes":["978"],"ExpiryDate":{"Start":"2016-03-01T00:00:00.000Z","End":"2016-03-31T00:00:00.000Z"},"Range":{"Start":"2017-02-03T09:23:40.154Z","End":"2017-02-03T09:23:40.156Z"}}}
@{"@odata.context":"https://hosted.datascopeapi.reuters.com/RestApi/v1/$metadata#Collection(ThomsonReuters.Dss.Api.Search.HistoricalSearchResult)","value":[]}<br>0 -
That is the same here. By working request i meant i did not get an HTTP 502 reply.
I just re-tested the request and I don't get the HTTP 502 response any more now. If it happens again I will let you know.
0
Categories
- All Categories
- 3 Polls
- 6 AHS
- 36 Alpha
- 166 App Studio
- 6 Block Chain
- 4 Bot Platform
- 18 Connected Risk APIs
- 47 Data Fusion
- 34 Data Model Discovery
- 689 Datastream
- 1.4K DSS
- 627 Eikon COM
- 5.2K Eikon Data APIs
- 11 Electronic Trading
- 1 Generic FIX
- 7 Local Bank Node API
- 3 Trading API
- 2.9K Elektron
- 1.4K EMA
- 255 ETA
- 559 WebSocket API
- 39 FX Venues
- 15 FX Market Data
- 1 FX Post Trade
- 1 FX Trading - Matching
- 12 FX Trading – RFQ Maker
- 5 Intelligent Tagging
- 2 Legal One
- 24 Messenger Bot
- 3 Messenger Side by Side
- 9 ONESOURCE
- 7 Indirect Tax
- 60 Open Calais
- 278 Open PermID
- 44 Entity Search
- 2 Org ID
- 1 PAM
- PAM - Logging
- 6 Product Insight
- Project Tracking
- ProView
- ProView Internal
- 23 RDMS
- 2K Refinitiv Data Platform
- 708 Refinitiv Data Platform Libraries
- 4 LSEG Due Diligence
- LSEG Due Diligence Portal API
- 4 Refinitiv Due Dilligence Centre
- Rose's Space
- 1.2K Screening
- 18 Qual-ID API
- 13 Screening Deployed
- 23 Screening Online
- 12 World-Check Customer Risk Screener
- 1K World-Check One
- 46 World-Check One Zero Footprint
- 45 Side by Side Integration API
- 2 Test Space
- 3 Thomson One Smart
- 10 TR Knowledge Graph
- 151 Transactions
- 143 REDI API
- 1.8K TREP APIs
- 4 CAT
- 27 DACS Station
- 121 Open DACS
- 1.1K RFA
- 106 UPA
- 194 TREP Infrastructure
- 229 TRKD
- 918 TRTH
- 5 Velocity Analytics
- 9 Wealth Management Web Services
- 95 Workspace SDK
- 11 Element Framework
- 5 Grid
- 19 World-Check Data File
- 1 Yield Book Analytics
- 48 中文论坛