1# Library Structure
 2
 3This library is generally broken into three components you need to understand.
 4
 5## Configs
 6
 7Configs are collections of fields related to a single request. For example, if
 8one wanted to use the `sendMessage` endpoint, you could use the `MessageConfig`
 9struct to configure the request. There is a one-to-one relationship between
10Telegram endpoints and configs. They generally have the naming pattern of
11removing the `send` prefix and they all end with the `Config` suffix. They
12generally implement the `Chattable` interface. If they can send files, they
13implement the `Fileable` interface.
14
15## Helpers
16
17Helpers are easier ways of constructing common Configs. Instead of having to
18create a `MessageConfig` struct and remember to set the `ChatID` and `Text`,
19you can use the `NewMessage` helper method. It takes the two required parameters
20for the request to succeed. You can then set fields on the resulting
21`MessageConfig` after it's creation. They are generally named the same as
22method names except with `send` replaced with `New`.
23
24## Methods
25
26Methods are used to send Configs after they are constructed. Generally,
27`Request` is the lowest level method you'll have to call. It accepts a
28`Chattable` parameter and knows how to upload files if needed. It returns an
29`APIResponse`, the most general return type from the Bot API. This method is
30called for any endpoint that doesn't have a more specific return type. For
31example, `setWebhook` only returns `true` or an error. Other methods may have
32more specific return types. The `getFile` endpoint returns a `File`. Almost
33every other method returns a `Message`, which you can use `Send` to obtain.
34
35There's lower level methods such as `MakeRequest` which require an endpoint and
36parameters instead of accepting configs. These are primarily used internally.
37If you find yourself having to use them, please open an issue.