9 ms·

Very well. I have two questions. Why should one use this service, instead of using directly ecb(https://www.ecb.europa.eu/stats/eurofxref/eurofxref-daily.xml h

Very well. I have two questions. Why should one use this service, instead of using directly ecb(https://www.ecb.europa.eu/stats/eurofxref/eurofxref-daily.xml https://www.ecb.europa.eu/stats/eurofxref/eurofxref-daily.xm...)? How do you keep this service free since there is a server cost?

arzzen 6y ago
hi @aaronedam, thanks for your question, - default api response is json format, this format is easy to parse then xml (eg directly usage in js/nodejs app..) - server cost is not too hight , api response is only static json data (data are sync. on midnight), so price is only for bandwige - i plan added crypto and comodities (like gold,silver etc)
- dang 6y ago
  Please reply directly to the question rather than posting a top-level comment. (I've moved this one.)
amerine 6y ago
Based on how I understand the service, I’d posit you could run such a thing on Heroku for free forever, maybe spending a few dollars (7 usd) a month eventually if you needed some scale.
- toomuchtodo 6y ago
  Wouldn’t it be more reliable to ask the ECB to support JSON alongside xml? Or require them to provide JSON by law? Shims are fine, but technical debt. Fix the problem at the source.
  - sambe 6y ago
    You'd enshrine in law a particular technical format? What is the cost of making such a law vs the cost of a different - but still very much usable - format?
    - toomuchtodo 6y ago
      I would, with lifecycle and sunsetting requirements. Laws are requirements docs with more ceremony and stakeholder participation, but also with much more authority.
      - sambe 6y ago
        That all seems well-intentioned and plausible in terms of how things should have been originally. However, 1) I can't help but think of all the problems that apply in general to specifying requirements (too vague, too constraining, too expensive to hammer out to sufficient precision). 2) That's different from changing it retroactively. Would you change it again when JSON goes out of fashion? Or mandate HTTPS? I've not read the OP in detail, but the impression I have is that the existing service is very much functional. Even ignoring the cost of changing the law, do we really want our public institutions to be in breach of law whenever fashions change? I'd rather let them set their own priorities to a large extent - for example, specify a very general, minimal set of requirements and do better when they have capacity to do so. I'm fine with people building on top of that where convenient. It seems like a good thing, in fact.
        toomuchtodo 6y ago
        I think your points are important, but it's likely we won't reach an agreement on this issue. Appreciate you raising the points though!
  - polote 6y ago
    What is the issue with XML ?
    - deleted 6y ago
      [deleted]
    - XCSme 6y ago
      I don't see the problem with XML, especially today, when you can get a package/libray to parse any format the API might be in.
    - LoSboccacc 6y ago
      there's some hip environment that handles xml quite badly compared to json and people with little cross experience think the problem is xml
  - hombre_fatal 6y ago
    This doesn't make any sense to me. Whether you have to use xmlParse() or jsonParse() is completely inconsequential. It's like writing laws that require languages to have a built-in XML parser. Or a fetchAndParseXml() function. If these kinds of laws infected tech, we'd still be maintaining government mandated SOAP/WSDL services and other overly complicated tech that someone somewhere thought was the global maximum.
  - rixed 6y ago
    Off-topic, and regularly repeated, but people up/downvoting based on (dis)agreement is the second biggest annoyance of web forums (right after Android keyboard autocompletion).
- dmurray 6y ago
  Yeah. It's one rate a day x 33 currencies x 19 years, so a total of 250,000 numbers. You could compress the whole thing (500 KB?) and serve it to a million customers a month for free.
jbaudanza 6y ago
Thank you for posting this! I had no idea this existed. It looks like all the rates are published with EUR as a base currency, so if you wanted to get the USD <> KRW exchange rate, you would have to use EUR at an intermediate. This is probably good enough for most applications. For anyone else that was wondering, this XML feed is linked off of this page (as well as CSV, RSS, and PDF): https://www.ecb.europa.eu/stats/policy_and_exchange_rates/euro_reference_exchange_rates/html/index.en.html https://www.ecb.europa.eu/stats/policy_and_exchange_rates/eu...
dhruval 6y ago
Bank of Canada has a similar free API https://www.bankofcanada.ca/valet/docs https://www.bankofcanada.ca/valet/docs
tzs 6y ago
That ECB link gives the latest rates. They also have one that give the last 90 days of rates [1]. There is a more general system for accessing ECB data that includes a vast amount beyond exchange rates, described here [2]. I think that lets you get anything they have in their statistical data warehouse. (If you don't need to get it programmatically, they have a web GUI [3]). The general system is also vastly more complex to use. I was quite happy when I found that 90 day link and did not have to deal with figuring out how to get what I wanted out of the general system. [1] https://www.ecb.europa.eu/stats/eurofxref/eurofxref-hist-90d.xml https://www.ecb.europa.eu/stats/eurofxref/eurofxref-hist-90d... [2] https://sdw-wsrest.ecb.europa.eu/help/ https://sdw-wsrest.ecb.europa.eu/help/ [3] https://sdw.ecb.europa.eu/ https://sdw.ecb.europa.eu/

arzzen 6y ago

hi @aaronedam, thanks for your question, - default api response is json format, this format is easy to parse then xml (eg directly usage in js/nodejs app..) - server cost is not too hight , api response is only static json data (data are sync. on midnight), so price is only for bandwige - i plan added crypto and comodities (like gold,silver etc)

dang 6y ago
Please reply directly to the question rather than posting a top-level comment. (I've moved this one.)

amerine 6y ago

Based on how I understand the service, I’d posit you could run such a thing on Heroku for free forever, maybe spending a few dollars (7 usd) a month eventually if you needed some scale.

toomuchtodo 6y ago
Wouldn’t it be more reliable to ask the ECB to support JSON alongside xml? Or require them to provide JSON by law? Shims are fine, but technical debt. Fix the problem at the source.
- sambe 6y ago
  You'd enshrine in law a particular technical format? What is the cost of making such a law vs the cost of a different - but still very much usable - format?
  - toomuchtodo 6y ago
    I would, with lifecycle and sunsetting requirements. Laws are requirements docs with more ceremony and stakeholder participation, but also with much more authority.
    - sambe 6y ago
      That all seems well-intentioned and plausible in terms of how things should have been originally. However, 1) I can't help but think of all the problems that apply in general to specifying requirements (too vague, too constraining, too expensive to hammer out to sufficient precision). 2) That's different from changing it retroactively. Would you change it again when JSON goes out of fashion? Or mandate HTTPS? I've not read the OP in detail, but the impression I have is that the existing service is very much functional. Even ignoring the cost of changing the law, do we really want our public institutions to be in breach of law whenever fashions change? I'd rather let them set their own priorities to a large extent - for example, specify a very general, minimal set of requirements and do better when they have capacity to do so. I'm fine with people building on top of that where convenient. It seems like a good thing, in fact.
      - toomuchtodo 6y ago
        I think your points are important, but it's likely we won't reach an agreement on this issue. Appreciate you raising the points though!
- polote 6y ago
  What is the issue with XML ?
  - deleted 6y ago
    [deleted]
  - XCSme 6y ago
    I don't see the problem with XML, especially today, when you can get a package/libray to parse any format the API might be in.
  - LoSboccacc 6y ago
    there's some hip environment that handles xml quite badly compared to json and people with little cross experience think the problem is xml
- hombre_fatal 6y ago
  This doesn't make any sense to me. Whether you have to use xmlParse() or jsonParse() is completely inconsequential. It's like writing laws that require languages to have a built-in XML parser. Or a fetchAndParseXml() function. If these kinds of laws infected tech, we'd still be maintaining government mandated SOAP/WSDL services and other overly complicated tech that someone somewhere thought was the global maximum.
- rixed 6y ago
  Off-topic, and regularly repeated, but people up/downvoting based on (dis)agreement is the second biggest annoyance of web forums (right after Android keyboard autocompletion).
dmurray 6y ago
Yeah. It's one rate a day x 33 currencies x 19 years, so a total of 250,000 numbers. You could compress the whole thing (500 KB?) and serve it to a million customers a month for free.

jbaudanza 6y ago

Thank you for posting this! I had no idea this existed. It looks like all the rates are published with EUR as a base currency, so if you wanted to get the USD <> KRW exchange rate, you would have to use EUR at an intermediate. This is probably good enough for most applications. For anyone else that was wondering, this XML feed is linked off of this page (as well as CSV, RSS, and PDF): https://www.ecb.europa.eu/stats/policy_and_exchange_rates/euro_reference_exchange_rates/html/index.en.html https://www.ecb.europa.eu/stats/policy_and_exchange_rates/eu...

dhruval 6y ago

Bank of Canada has a similar free API https://www.bankofcanada.ca/valet/docs https://www.bankofcanada.ca/valet/docs

tzs 6y ago

That ECB link gives the latest rates. They also have one that give the last 90 days of rates [1]. There is a more general system for accessing ECB data that includes a vast amount beyond exchange rates, described here [2]. I think that lets you get anything they have in their statistical data warehouse. (If you don't need to get it programmatically, they have a web GUI [3]). The general system is also vastly more complex to use. I was quite happy when I found that 90 day link and did not have to deal with figuring out how to get what I wanted out of the general system. [1] https://www.ecb.europa.eu/stats/eurofxref/eurofxref-hist-90d.xml https://www.ecb.europa.eu/stats/eurofxref/eurofxref-hist-90d... [2] https://sdw-wsrest.ecb.europa.eu/help/ https://sdw-wsrest.ecb.europa.eu/help/ [3] https://sdw.ecb.europa.eu/ https://sdw.ecb.europa.eu/