👨‍💻 Resty переоценён. Используйте net/http с тонкой обёрткой

resty делает HTTP-запросы в Go удобнее. Но платите вы за это абстракцией поверх того, что стандартная библиотека уже умеет хорошо.

Resty скрывает детали реализации. Логика ретраев, поведение таймаутов, политика редиректов — всё это настраивается через API Resty, а не через http.Transport. Когда что-то ломается в проде, вы отлаживаете через два слоя вместо одного.

Что использовать

Тонкая обёртка вокруг net/http. Пишется один раз:

type Client struct {
    base    string
    http    *http.Client
    headers map[string]string
}

func (c *Client) Get(ctx context.Context, path string, out any) error {
    req, err := http.NewRequestWithContext(ctx, http.MethodGet, c.base+path, nil)
    if err != nil {
        return err
    }
    for k, v := range c.headers {
        req.Header.Set(k, v)
    }
    resp, err := c.http.Do(req)
    if err != nil {
        return err
    }
    defer resp.Body.Close()
    return json.NewDecoder(resp.Body).Decode(out)
}


http.Transport настраивается напрямую. Таймауты выставляются на http.Client. Ретраи с экспоненциальным бэкоффом добавляются именно там, где нужны.

Для межсервисного взаимодействия, внутренних API и интеграций с внешними сервисами этой обёртки более чем достаточно. Поведение предсказуемо, отладка прямолинейна, зависимостей нет.

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека Go-разработчика

#GoToProduction