Incorrect Response from API for unsupported currencies

[marination]

Issue: Consider the currency TMM, which is not supported by this API (which is fine): While fetching exchange rate TMM -> INR, we get 86.809808. This seems like it defaults to the value of **EUR** to INR Similarly, TMM -> USD, we get 1.168879. Again value of **EUR** to USD

Rather for any currency that does not exist, lets say ABC: ABC -> USD = 1.168879 USD -> ABC = 0

This is really not the best API design. It should maybe give back some exc/exception that says that this currency is not supported. The response is not predictable.

It does not obstruct any other currencies, except TMM (poor Turkmenistanis).

[Jadarma]

Yes, this seems to be a problem in the way the API handles base currencies. See also #34 and #70.

As a workaround I would suggest not querying for base currencies that are not returned in the /symbols response. Though this wouldn't really work for historical data with out-of-use currencies since the /symbols endpoint only returns the supported currencies at the time of request.

A (hacky) workaround for the time being:

Unsupported currencies are just removed from the response if they are not the base. If your use case allows for small rounding errors, you could always use the default base of EUR and calculate by proxy. Suppose you have:

{
  "base": "EUR",
  "rates": {
    "USD": 1.19397,
    "INR": 89.041089,
  }
}

Then you could get the rate from INR to USD like so: inrToUsd = 1 / rates.INR * rates.USD. In my example this would be: 1 / 89.041089 * 1.19397 ~= 0.013409 which seems to match what the API returns when requesting INR to USD directly, though do note that rounding errors may occur for very inflated currencies like IRR or VES.

Of course, if instead of INR you'd use TMM or other unsupported currency, you won't have the rates.TMM property, and you can treat that as a Not Found.

[rtdany10]

As a workaround I would suggest not querying for base currencies that are not returned in the /symbols response.

It will be an extra API call each time since we use the /convert endpoint to get historical data. Hoping a fix is on the way!