RDK Resources
[*RDK Preferred*]
Code Management Facility
RDK Forums
[RDK Conferences]
RDK Support
Archives
Papers & Presentations Archive
Firebolt as an API expects the implementation to fulfill certain basic traits as an Application platform.
In this document, we will deep dive into the Firebolt Implementation requirements.
This section will dive into more details of what traits Firebolt API expects from its implementations
Firebolt shares 3 main phases during its API lifecycle with the Apps.
Let's look into some of these in a bit more detail
Firebolt API expects the implementation to be aware of the App.
There could be 2 kinds of Apps connected to the Firebolt Implementation
Context Generation: Implementation is expected to be App aware based on the initial connection as the requests do not have an App ID field. Implementation is expected to create a context for a given connection using the connection parameter. For a System App, this could be a URL parameter, and for 3rd party apps, this could be a session ID generated by the Implementation.
Context Update: Firebolt implementation is expected to be aware of the calling Application from the Connection phase. This data is mandatory for verifying if the given App is authorized for the capabilities to make the request.
Capability Resolution: Firebolt Open RPC specification defines a list of capabilities and their mapping to the request methods in Firebolt. Every implementation is expected to consume a single or multiple Open RPC files to resolve a set of capabilities expected for a given request.
Capability Verification: Each Firebolt request undergoes a rigorous set of checks from supported, available, permitted and user grants to get authorized. This stage expects the implementation to have a list of data sources like manifests, services, and app providers to power the validation.
Firebolt Implementation needs a configurable router that forwards the authorized requests to the right handlers. These handlers could be internal to the implementation or external components like Apps, Device Platforms (Thunder), or Cloud services.
Firebolt Implementation is expected to resolve the right handler for the request, this routing could be
For an External sourced API the implementation is still expected to