Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rates add REST Endpoint request exchange rates #14

Open
kabl opened this issue May 31, 2018 · 1 comment
Open

Rates add REST Endpoint request exchange rates #14

kabl opened this issue May 31, 2018 · 1 comment
Labels
feature New feature or request

Comments

@kabl
Copy link

kabl commented May 31, 2018

Why communicate with the Rates over a Queue? I guess if you request a FX Rate you expect to receive the response immediately. A blocking HTTP GET gives you that feature. In addition HTTP interfaces are more easy to integrate.

Add a REST interface to request FX rates for a specific time. Always work with UTC time in request and response.

Example:

GET https://HOST/api/fx/time?time=2018-05-02T13:51:45Z

{"id":82,"utcTime":"2018-05-02T13:51:19Z","btcUsd":9068.6,"ethUsd":673.01,"btcChf":9028.6982,"ethChf":670.0488,"btcEur":7549.6095,"ethEur":560.2808}
```
@gsmachado gsmachado added the feature New feature or request label Jun 2, 2018
@gsmachado
Copy link
Member

Hello @kabl

It's a good idea providing a REST API interface to fetch rates of different cryptocurrencies or fiat currencies. Such interface can provide an easier way for operators to fetch rates. I added a "feature" label to further develop it. Thanks.

However, I think you totally overlooked the code since we are not using (yet) amqp in the whole rates application! Thus, the question "Why communicate with the Rates over a Queue?" does hold true at the present moment, at all. But, we are planning to use it.

So, related to the previous paragraph:
Your statement "In addition HTTP interfaces are easier to integrate" is indeed true. But, this project aims not to provide the easiest or the fastest way to integrate to our interfaces. We aim to be reliable. One of the backbone parts of the ICOnator project is the AMQP 0.9.1 protocol, in which we add events which should be processed by consumers. We believe that this is a more scalable approach -- without relying on HTTP load balancers, but relying on a queue broker server.

Thanks once again!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants