Какой вариант использования для помещения всего на другой уровень с именем «data» JSON API - PullRequest
1 голос
/ 24 сентября 2019

Часто я вижу, что JSON API имеет форму

{
  data: {
    ...
  }
}

Целый уровень находится под data, и все находится под ним, редко что-то рядом.Вы знаете, почему они так разрабатывают API?Каков основной вариант использования?Зачем это усложнять?Что вы кладете рядом с этим?Метаданные?Ключевые слова?Associaitions?Версии?

Ответы [ 3 ]

0 голосов
/ 24 сентября 2019

Я вижу, что есть стандарт "JSON API".https://jsonapi.org/

Они используют data там.

0 голосов
/ 24 сентября 2019

Подобные структуры являются общими с API, которые обертывают все ответы в некоторый объект метаданных.Например, учитывая класс C #:

public class Response<T>
{
    string ApplicationMessage { get; set; }
    Exception Exception { get; set; }
    object Data { get; set; }
}

Всегда возвращая классы, производные от Response<T>, клиентский код может проверять свойства метаданных, чтобы при необходимости получить дополнительное представление об ответе.

Например, скажем:

Запрос

GET api.com/users/HunorKovács

Ответ

400 Плохой запрос

Тело:

{
    "applicationMessage": "Expected a userId, not a username.",
    "exception": null,
    "data": null
}

В этом случае ApplicationMessage дает подробные сведения о том, почему был возвращен ответ 400.Исключения могут передаваться для упрощения отладки в средах разработки и т. Д.

Для обычных запросов, в которых нет проблем, вы, скорее всего, увидите только заполненные данные:

Запрос

GET api.com/users/1474495

Ответ

200 ОК

Тело:

{
    "applicationMessage": null,
    "exception": null,
    "data": {
        "userId": 1474495,
        "fullName": "HunorKovács"
    }
}
0 голосов
/ 24 сентября 2019

Я обычно резервирую корень для статуса и «данные» для фактического сериализованного объекта

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...