Указание структуры данных в запросе REST - PullRequest
Новая
       62

Указание структуры данных в запросе REST

0 голосов
/ 23 декабря 2019

Я пытаюсь написать базовый запрос в стиле REST для базы данных в Go. Я никогда раньше не работал с REST, поэтому мне немного неясно, насколько глубоко должен следовать принцип способности обрабатывать любые данные. Нарушает ли это принцип делать предположения о данных / типах данных, которые я получаю из базы данных в коде для клиента? Должен ли я написать первый или последний struct для распаковки данных JSON в? 

type datum struct {
    ID      int16 `json:"src_id"`
    Time    int64 `json:"timestamp"`
    Lat     float64 `json:"latitude"`
    Long    float64 `json:"longitude"`
    Thermo  float64 `json:"ir_thermo_temperature_filtered"`
    Humid   float64 `json:"relative_humidity"`
    AirTemp float64 `json:"air_temp"`
    Wind    float64 `json:"wind_speed_world_filtered"`
}

type datum struct {
    ID      interface{} `json:"src_id"`
    Time    interface{} `json:"timestamp"`
    Lat     interface{} `json:"latitude"`
    Long    interface{} `json:"longitude"`
    Thermo  interface{} `json:"ir_thermo_temperature_filtered"`
    Humid   interface{} `json:"relative_humidity"`
    AirTemp interface{} `json:"air_temp"`
    Wind    interface{} `json:"wind_speed_world_filtered"`
}

Я думаю, что, возможно, последняя структура нарушает принципы REST, потому что она делает предположения о типах данныхчто вы будете получать с сервера, поэтому он не является должным образом единообразным. Я надеюсь, что я не прав, но я вижу, что этот вывод может прийти из строгого прочтения принципов REST.

1 Ответ

1 голос
/ 23 декабря 2019

Я полагаю, что вы неправильно читаете принципы REST.

REST - это архитектура, а не протокол со строгими правилами. Ключевыми моментами являются то, что он не имеет состояния и представляет базовые ресурсы, аналогичные тому, как работает сеть.

REST описывает ресурсы (datum, в вашем случае), как вы можете получить доступ к этим ресурсам и изменить их,и как эти ресурсы должны описывать, какие другие ресурсы могут быть доступны относительно этого ресурса. Это похоже на работу веб-браузера: каждая страница имеет уникальный URI, и страница может содержать данные (поля datum) и ссылки на другие страницы, на которые вы можете перейти с этой страницы.

Так что вВ вашем случае поля datum аналогичны содержимому веб-страницы. Если у вас есть другие ресурсы, доступные из datum, вы должны предоставить их как URI для вызывающей стороны, и вызывающая сторона может следовать за ними. Это не означает, что вы должны отказаться от безопасности типов и иметь дело со всеми видами данных. Опять же, это не протокол. Если представленная информация не в ожидаемом формате, вы должны вернуть ошибку. Поскольку ваш формат связи - JSON, ваши типы данных ограничены строкой, числом и логическим значением. Вы ожидаете целое число для идентификатора, и если клиент отправляет вам строку (даже если это что-то вроде «123»), это ошибка. Используйте первую структуру, если при демаршировании ввода возвращается ошибка, верните ее вызывающей стороне.

...