TickHistoryRawExtractionRequest REST API throws an error using Curl
Answers
-
To my best understanding, you can use the output from curl any way that you require, i.e. disregard any output that you do not require, selecting what you need.
Please note, we are not the owner/provider of curl, it is a licensed tool that the public has the option to use, free of charge, plus there are different versions of it available from different providers?
Hope this helps
0 -
@zoya faberov thanks very much ...we are here new to Python but definately if it makes the enviornment more stable without performance issue then we would definately like to try the example which you have provided and use Python for RTH REST ...i will let you know in case i face any issue while using this code for RTH Rest....0
-
@zoya faberov thanks the demo example is working in python environment...just few questions...
1) As we have 3000 Identifiers list what is the best practice in terms of performance, stability and without loss of data to send this Identifier request to the RTH REST ? Should we send the Identifier request one by one to the RTH REST or bulk Identifier request for example 500 Identifier request in one RTH REST request and then another 500 Identifier request and so on.. ?2) In demo example i see comments in some parts where it says the example is for demo purpose only and in production it will create problem...what does this actually mean and where do we need to update the code ?
3) As we are expecting huge volume of data from RTH REST from the 3000 Identifier list, we are thinking to send either one by one Identifier request or bulk Identifier(500 in one request) to the RTH REST and then get the data from this REST, store the data in the csv zip file like given in demo example and then load the data into database table....And then do another Identifier request to the REST, just delete the previous csv zip file, fetch the data from REST and load into database table and the process goes on until all the 3000 Identifier request has been sent to the REST...Is this good approach considering Volumne of data and performance ?
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
- 690 Datastream
- 1.4K DSS
- 629 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
- 25 Messenger Bot
- 3 Messenger Side by Side
- 9 ONESOURCE
- 7 Indirect Tax
- 60 Open Calais
- 280 Open PermID
- 45 Entity Search
- 2 Org ID
- 1 PAM
- PAM - Logging
- 6 Product Insight
- Project Tracking
- ProView
- ProView Internal
- 23 RDMS
- 2K Refinitiv Data Platform
- 716 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 中文论坛