diff --git a/docs/Clients.md b/docs/Clients.md index 3b1e8f2..c2f4465 100644 --- a/docs/Clients.md +++ b/docs/Clients.md @@ -3,6 +3,8 @@ title: General usage nav_order: 2 --- +## How to use the library + Each implementation generally provides two different clients, which will be the access point for the API's. First of the rest client, which is typically available via [ExchangeName]Client, and a socket client, which is generally named [ExchangeName]SocketClient. For example `BinanceClient` and `BinanceSocketClient`. ## Rest client diff --git a/docs/FAQ.md b/docs/FAQ.md index a39c217..58e8c67 100644 --- a/docs/FAQ.md +++ b/docs/FAQ.md @@ -3,6 +3,8 @@ title: FAQ nav_order: 11 --- +## Frequently asked questions + ### I occasionally get a NullReferenceException, what's wrong? You probably don't check the result status of a call and just assume the data is always there. `NullReferenceExecption`s will happen when you have code like this `var symbol = client.GetTickersAync().Result.Data.Symbol` because the `Data` property is null when the call fails. Instead check if the call is successful like this: ```csharp diff --git a/docs/Glossary.md b/docs/Glossary.md index 2a6a8b7..efd7074 100644 --- a/docs/Glossary.md +++ b/docs/Glossary.md @@ -2,6 +2,7 @@ title: Glossary nav_order: 10 --- +## Terms and definitions |Definition|Synonyms|Meaning| |----------|--------|-------| @@ -19,7 +20,7 @@ nav_order: 10 |Ticker|Stats|Statistics over the last 24 hours| |Client implementation|Library|An implementation of the `CrytpoExchange.Net` library. For example `Binance.Net` or `FTX.Net`| -### Other naming constraints +### Other naming conventions #### PlaceOrderAsync Methods for creating an order are always named `PlaceOrderAsync`, with and optional additional name for the type of order, for example `PlaceMarginOrderAsync`. diff --git a/docs/Interfaces.md b/docs/Interfaces.md index ee38733..c95a22d 100644 --- a/docs/Interfaces.md +++ b/docs/Interfaces.md @@ -3,6 +3,7 @@ title: Common interfaces nav_order: 5 --- +## Shared interfaces Clients have a common interface implementation to allow a shared code base to use the same functionality for different exchanges. The interface is implemented at the `API` level, for example: ```csharp var binanceClient = new BinanceClient(); diff --git a/docs/Logging.md b/docs/Logging.md index 5f72eef..512e40c 100644 --- a/docs/Logging.md +++ b/docs/Logging.md @@ -3,6 +3,7 @@ title: Log config nav_order: 4 --- +## Configuring logging The library offers extensive logging, for which you can supply your own logging implementation. The logging can be configured via the client options (see [Client options](https://github.com/JKorf/CryptoExchange.Net/wiki/Options)). The examples here are using the `BinanceClient` but they should be the same for each implementation. Logging is based on the `Microsoft.Extensions.Logging.ILogger` interface. This should provide ease of use when connecting the library logging to your existing logging implementation. diff --git a/docs/Migration Guide.md b/docs/Migration Guide.md index 3133a2f..fd45d04 100644 --- a/docs/Migration Guide.md +++ b/docs/Migration Guide.md @@ -3,7 +3,10 @@ title: Migrate v4 to v5 nav_order: 9 --- -Changes from 4.x to 5.x: +## Migrating from version 4 to version 5 +When updating your code from version 4 implementations to version 5 implementations you will encounter a fair bit of breaking changes. Here is the general outline for changes made in the CryptoExchange.Net library. For more specific changes for each library visit the library migration guide. + +*NOTE when updating it is not possible to have some client implementations use a V4 version and some clients a V5. When updating all libraries should be migrated* ## Client structure The client structure has been changed to make clients more consistent across different implementations. Clients using V4 either had `client.Method()`, `client.[Api].Method()` or `client.[Api].[Topic].Method()`. diff --git a/docs/Options.md b/docs/Options.md index 9121fb4..e7a12fa 100644 --- a/docs/Options.md +++ b/docs/Options.md @@ -3,7 +3,7 @@ title: Client options nav_order: 3 --- -## Setting options +## Setting client options Each implementation can be configured using client options. There are 2 ways to provide these, either via `[client].SetDefaultOptions([options]);`, or in the constructor of the client. The examples here use the `BinanceClient`, but usage is the same for each client. diff --git a/docs/Orderbooks.md b/docs/Orderbooks.md index 32115f3..118ad56 100644 --- a/docs/Orderbooks.md +++ b/docs/Orderbooks.md @@ -3,6 +3,7 @@ title: Order books nav_order: 6 --- +## Locally synced order book Each implementation provides an order book implementation. These implementations will provide a client side order book and will take care of synchronization with the server, and will handle reconnecting and resynchronizing in case of a dropped connection. Order book implementations are named as `[ExchangeName][Type]SymbolOrderBook`, for example `BinanceSpotSymbolOrderBook`. diff --git a/docs/RateLimiter.md b/docs/RateLimiter.md index fbdc149..223b525 100644 --- a/docs/RateLimiter.md +++ b/docs/RateLimiter.md @@ -3,6 +3,7 @@ title: Rate limiting nav_order: 7 --- +## Rate limiting The library has build in rate limiting. These rate limits can be configured per client. Some client implementations where the exchange has clear rate limits will also have a default rate limiter already set up. Rate limiting is configured in the client options, and can be set on a specific client or for all clients by either providing it in the constructor for a client, or by using the `SetDefaultOptions` on a client. @@ -51,6 +52,8 @@ A rate limit for the total amount of requests for all requests send from the cli A rate limit for all requests send to a specific endpoint. Requests that do not fully match the endpoint will not be counted to this limit. ### AddPartialEndpointLimit +|Parameter|Description| +|---------|-----------| |endpoint|The partial endpoint this limit is for. Partial means that a request will match this limiter when a part of the request URI path matches this endpoint| |limit|The request weight limit per time period. Note that requests can have a weight specified. Default requests will have a weight of 1| |perTimePeriod|The time period over which the limit is enforced| @@ -61,6 +64,8 @@ A rate limit for all requests send to a specific endpoint. Requests that do not A rate limit for a partial endpoint. Requests will be counted towards this limit if the request path contains the endpoint. For example request `/api/v2/test` will match when the partial endpoint limit is set for `/api/v2`. ### AddApiKeyLimit +|Parameter|Description| +|---------|-----------| |limit|The request weight limit per time period. Note that requests can have a weight specified. Default requests will have a weight of 1| |perTimePeriod|The time period over which the limit is enforced| |onlyForSignedRequests|Whether this rate limit should only be counter for signed/authenticated requests|