Golang: Что нужно вернуть при создании SDK для взаимодействия с веб-API?

Question

Я создаю SDK для веб-приложения с использованием Go.

Мне было интересно, какой будет наилучшая форма возврата данных пользователям SDK.

Например, нижеэто функция, которая принимает объект http.RequestКакой предпочтительный объект / структура должен быть возвращен из этой функции?

func runRequest(request *http.Request) map[string]interface{} {
    resp, err := http.DefaultClient.Do(request)
    //handle error
    defer resp.Body.Close()

    body, err := ioutil.ReadAll(resp.Body)
    var data map[string]interface{}
    err2 := json.Unmarshal([]byte(body), &data)
    //handle error

    return data
}

Answer 1

В этом простом примере вы можете использовать тот же подход, что и json.Unmarshal.То есть ваша функция получает указатель на значение, в которое вы хотите разархивировать тело ответа.

func RunRequest(request *http.Request, dst interface{}) error {
    resp, err := http.DefaultClient.Do(request)
    if err != nil {
        return err
    }
    defer resp.Body.Close()

    return json.NewDecoder(resp.Body).Decode(dst)
}

Answer 2

Если вы подписаны на «Чистая архитектура» или «Гексагональная архитектура» runRequest, то вы должны вернуть что-то из вашего домена.Т.е. что вы на самом деле запрашиваете?(как называется ресурс? Страница? Автомобиль? Учетная запись?)

Я бы сказал, что приведенный вами пример обратен чистой архитектуре.Он показывает протоколы и технологии и задает вопрос, что является оптимальным, когда Чистая архитектура предполагает, что транспортные протоколы являются деталями реализации.Сосредоточение внимания на вашем домене (т. Е. На том, что вы выбираете, и на тех операциях, которые вы разрешаете выполнять на них), поможет отделить их от ваших протоколов реализации или транспорта.

Например, представьте, что ваш запрос относится к пользователю и связан с ним.Аккаунт и Страницы, принадлежащие этому пользователю.Сосредоточив внимание на их отношениях

, то есть User.Accounts () или Account.Pages () - это хороший трюк для создания более несвязанного программного обеспечения.Что, если вы предлагаете соединение GRPC?Что если вы хотите поддерживать несколько типов возврата?JSON, XML, Protobuf?

Чистая архитектура решает эту проблему, фокусируясь на объектах домена в первом цикле, а затем на кодировке во внешнем круге.Это означает, что внутренний круг ничего не знает о кодировках (т.е. кодировки зависят от ваших доменных объектов, но ваши доменные объекты не зависят от кодировок)

Если ваша функция выше запрашивает учетную запись

type Account struct {
   Name string
   ID string
   Location string
}

Тогда будет еще один слой, который знает, как кодировать учетную запись:

type JSONAccount struct {
    Account
}

func (ja JSONAccount) Encode() ([]byte, error) {
   return json.Marshal(ja)
}

Ваша функция runRequest может работать на интерфейсе

type Encoder interface {
   Encode() ([]byte, error)
}

Теперь вы можете поддерживать несколько разных кодировок для возвращаемых типов и выставлять их в качестве флага для вызывающей стороны.Поскольку ваша функция зависит от интерфейса, она сможет работать или возвращать несколько различных кодеров данных, если они соответствуют интерфейсу !!