Exchange Rates - Starter Guide
Welcome to the CoinAPI developer documentation. This document should contain all the information required to properly implement applications using our API.
Overview of the APIs
3 main interfaces can be used to access CoinAPI:
| API | Data | Communication | Description |
|---|---|---|---|
| RESTful | Live and Historical | Request-response | Stateless API provides the widest range of data, not capable of streaming, only pooling. |
| WebSocket | Live | Publish-subscribe | Stateful API providing streaming of real-time market data. Using a single connection, clients are able to subscribe to multiple data streams. |
Comparison: REST vs. Streaming Protocols (WebSocket)
Understanding the differences between REST and streaming protocols like WebSocket is essential for developers when designing and implementing financial applications. Here's a detailed comparison to guide your choice.
| Feature | REST API | WebSocket |
|---|---|---|
| Communication Model | Request-response model, where the client sends a request and the server responds | Continuous, bidirectional communication allowing for real-time data streaming |
| Use Case | Ideal for operations that do not require real-time updates, such as retrieving historical data | Suited for applications requiring real-time market data updates |
| Complexity | Generally simpler to implement due to the stateless nature of HTTP requests | More complex due to the need for handling continuous connections and real-time data management |
| Data Freshness | Data is only as fresh as the last request made by the client | Data is continuously updated in real-time, providing the latest market information |
| Scalability | Can be more easily scaled using standard web infrastructure | Scaling requires careful management of connection resources and data throughput |
| Latency | Higher latency due to the overhead of making HTTP requests | Lower latency, optimized for real-time data delivery |
| State Management | Stateless, with each request being independent | Stateful, maintaining a continuous connection state |
Key Takeaways
- REST API is straightforward and effective for operations that can tolerate the latency inherent in the request-response model. It's widely used for accessing historical data, account management, and other non-time-sensitive operations.
- WebSocket is tailored for real-time applications, such as live market data feeds, trading platforms, and other scenarios where immediate data access is crucial. It offers lower latency and continuous data streams but comes with added complexity in implementation and resource management.
Choosing between REST and streaming protocols depends on your application's specific needs regarding data freshness, real-time updates, and the complexity you're prepared to manage.
SDK
Our Software Development Kit (SDK) is available on GitHub at https://github.com/coinapi/coinapi-sdk. If possible then we are strongly recommending using our tested libraries available on GitHub, rather than creating new ones. However, if you decide to create your implementation or to change the existing one, then we encourage you to create a Pull Request to our main repository with the proposed changes, we will able to include your code in our official repository for use by other users, effectively creating collaboration.
In the repository, you can find libraries or examples for languages or environments like:
- Python
- R
- Matlab
- C#
- C++
- .NET
- Java
- Ruby
- Go
- JavaScript
- TypeScript
- Node.js
- PHP
- Haskell
- Objective-C
- Swift
Security
The use of encryption is optional, and the decision to use it is on you. On the encrypted endpoints, we are using protocols that are considered the best security practices.
You should assume that we are always providing certificates signed by the Trusted Certification Authority.
Standards and conventions
This section represents used standards and conventions across all documents and API's.
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
Variables naming
All variables are named using the Snake case (or snake_case) naming convention.
This means that words are separated by a single underscore _ character, no spaces are used, and letters are lowercase.
Asset codes
ISO 4217 currency code standard is used for fiat money identifications. Cryptocurrency assets are identified using codes used by the general public or adopted by the majority of exchanges.
Numbers precision
Numbers in our platform can have a maximum of 19 digits overall, but no more than 9 decimal places. In cases when the number represents aggregate value then we allow 38 digits overall, but still no more than 9 decimal places.
Time
For all input and output time values ISO 8601 standard is used.
| Format specifier | Description |
|---|---|
yyyy | The year is a four-digit number. |
MM | The month, from 01 through 12. |
dd | The day of the month, from 01 through 31. |
HH | The hour, using a 24-hour clock from 00 to 23. |
mm | The minute, from 00 through 59. |
ss | The second, from 00 through 59. |
fff | The milliseconds in a date and time value. |
fffffff | The ten-millionths of a second in a date and time value. |
Input time values are parsed using the following formats as far as possible:
yyyy-MM-ddTHH:mm:ss.fffffffyyyy-MM-ddTHH:mm:ss.fffyyyy-MM-ddTHH:mm:ssyyyy-MM-ddTHH:mmyyyy-MM-ddTHHyyyy-MM-ddyyyyMMddTHHmmssfffffffyyyyMMddTHHmmssfffyyyyMMddTHHmmssyyyyMMddTHHmmyyyyMMddTHHyyyyMMdd
When time zone information is not supplied, we will assume the UTC zone.
Output time values are formatted using the following patterns:
yyyy-MM-ddTHH:mm:ss.fffffffZyyyy-MM-dd
All time values we provide are UTC zones. Do not assume otherwise.