Refinitiv Data Library for Python
Refinitiv Data Libraries concepts and design
Targeting both financial coders and professional developers, these libraries provide capabilities that cover simple use cases as well as the most advanced ones.
They are designed with simple and consistent interfaces enabling your applications to connect to the Refinitiv Data through its different access points. Once connected, your applications can rely on ease-of-use objects and functions to access to the breadth and depth of data services available on the platform. For very specific needs they can also leverage the service agnostic lower layer that gives you access to fine grained details of each platform service.
As previously outlined, the developer has the choice to access the platform from specific access point ranging from the desktop (Eikon/Refinitiv Workspace), via high-performance on-premise deployments (Refinitiv Real-Time Distribution System) to cloud-based services (Refinitiv Data Platform).
Depending on the specific access point, developers should not have to learn and use different APIs. The same API and libraries should work seamlessly across the platform, using the same paradigms, experience the same functional behavior and receive the same data irregardless of how they choose to access content.
Depending on the application goals, what skill level and development experience is available, different types of developers will want to use this API with a large range of different use case scenarios.
These scenarios can be as basic as getting the current values of an instrument via a simple function call or can be as sophisticated as being alerted in real-time when values of an instrument change within the market.
Refinitiv Data Libraries will address these various needs by providing several abstraction layers and operation models as described below.
Platform Access Points
Depending on the access point it uses to connect to the Refinitiv Data Platform (either directly to the platform or via Eikon/Refinitiv Workspace or via a local Real-Time Distribution System), your application will create and use one of the different session types defined by the libraries. With the exception of this session creation phase, the design of the Refinitiv Data Libraries is normalized to provide consistent interfaces, irregardless how you access content. For example, applications built to access streaming content from the Refinitiv Workspace can seamlessly switch to another supporting access point (like direct access to the Refinitiv Data Platform) with minimal code changes. The goal is to provide the developer an intuitive interface that defines consistent APIs through multiple access points when accessing data services within the platform.
The following diagram presents the different platform access points available to the developer:
Refinitiv Data Libraries abstraction layers target different needs as well as different types of developers.
Depending on the skill and comfort level of the developer, the library offers general abstraction (Session & Delivery) layers specific to the delivery mode of the content to more business-specific (Content & Access) layers defining interfaces more suited to the nature of the data. But even the lower layers (Session & Delivery) provides intuitive and easy to use APIs.
All these layers can be used together in the same application.
Depending on the access point it uses to connect to the Refinitiv Data Plaform, access requires authentication and connection semantics in order to communicate and retrieve content. Refinitiv Data Libraries provide this managed access through an interface called a Session. Once the session has been established, it can be used with objects and functions of other layers to retrieve data from the platform.
The Delivery layer implements classes that can be used to interract with the different delivery modes provided by the Refinitiv Data to retrieve data:
- Request (HTTP Request/Response)
- Stream (WebSockets)
- Queue (Alerts)
- Files (bulk)
For each of these delivery modes, defined classes can be used to easily retrieve data from the platform in raw JSON format.
Classes defined in the Delivery layer are not dependent on any specific data service. They are service agnostic. Designed as a low abstraction layer of the library, the Delivery layer targets developers who need specific features that are not offered by other higher level abstraction layers (Content & Function). This layer targets the professional developer but can also be used by financial coders with good programming skills.
The Content layer refers to logical market data objects, largely representing financial items like level 1 market data prices and quotes, Order Books, News, Historical Pricing, Company Research data and so on. These objects are built on top of the Delivery abstraction layer and provide value-add capabilities to manage and access the content within the interface.
The Content layer can easily be used by both professional developers and financial coders. It provides great flexibility for familiar and commonly used financial data models.
The Access layer, that is the easiest way to access Refinitiv data, has been specifically designed for quick experimentation within interactive coding environments such as Jupyter Notebooks and Jupyter Lab.
The abstraction layers outlined above provide several operation models that meet the needs of a large range of use cases, from the simplest to the more advanced. These models are synchronous, asynchronous and event-driven.
Method/function calls are blocking. The result related to the call is available as soon as the method/function returns control to the calling thread. Synchronous calls are extremely useful when prototyping within scripting environments such as Jupyter Notebooks.
Method/function calls are non-blocking and return control to the calling thread almost immediately, before the result of the call is available. The Asynchronous model allows the calling thread to perform other operations in parallel to the task requested by the method/function call. When done with the other operations, the calling thread can wait for the requested result to be available (e.g. async/await paradigm). Applications that require more sophisticated interfaces, such as GUI-based applications, will greatly benefit from asynchronous calls.
With this model, the application registers callback methods or lambda expressions that are called when the requested results are available. Mostly applicable to streaming data, the Event driven model can be mixed with the Synchronous model and the Asynchronous model.
When mixed with the Synchronous model, some of the callback methods or lambda expressions are called before the method/function returns control to the calling thread. When mixed with the Asynchronous model, callback methods or lambda expressions are generally called after the method/function returns control to the calling thread. Event-driven applications are quite common when building applications that work with streaming data.