API method name collisions

HTTP method is removed from the beginning of API paths, and this can cause methods to overwrite each other. Example, where only a privateGetOrder will be available, but no privateGetGetOrder.

[Deathamns]

One more thing about method naming. Exchanges use a wide range of URL parameter names for the same thing. For example: ticker/:traiding_pair, ticker/:pair, ticker/:coin, ticker/:symbol and so on. How should the library handle these cases? Use a unified name for the same thing, or respect how the exchange named it? In both cases it’s possible to have a collision (URL param is symbol, and there could be a query param with the name symbol), so that should not matter when choosing.

[kroitor]

One more thing about method naming. Exchanges use a wide range of URL parameter names for the same thing. For example: ticker/:traiding_pair, ticker/:pair, ticker/:coin, ticker/:symbol and so on. How should the library handle these cases? Use a unified name for the same thing, or respect how the exchange named it?

We think preserving them as per exchange is better, because later we could add a swagger-importer or a parser of this kind of format which is common to many exchanges (their API docs) and could make it much easier importing new exchanges later:

GET https://.../markets
POST https://.../trade
GET https://.../order/{id}

The parser should also support other types of brackets around named url params, like in <id> and [id] or :foobar, etc…

If we find some naming that is not consistent with their original schema, we better make the URL listings look as similar as possible to the exchanges’ originals from docs.

In both cases it’s possible to have a collision (URL param is symbol, and there could be a query param with the name symbol), so that should not matter when choosing.

Most of the time we can resolve these types of collisions. but so far we haven’t encountered them.