Какова лучшая практика в REST-Api для передачи структурированных данных или пары ключ-значение?

Question

У меня есть структура данных, подобная приведенной ниже, которую я должен обработать. Я разрабатываю API, который должен принимать запрос POST, аналогичный приведенному ниже. (игнорируйте заголовки и т. д. c)
{ "Name" : "Johny English", "Id": "534dsf", "Message":[ { "Header":"Country of origin", "Value":"England" }, { "Header":"Nature of work", "Value":"Secret Agent/Spy" } ] }

Некоторые, как я не чувствую, это правильный способ передачи / приема данных. Здесь я говорю о структурированных данных против пары ключ-значение. Хотя я могу извлекать поля («Имя», «Идентификатор») напрямую в атрибуты объекта, но для пар «ключ-значение» мне нужно провести l oop через коллекцию и сравнить со строками (например, «Характер работы»). ) чтобы извлечь значения.
Я искал несколько сайтов, искал лучшие практики, не мог прийти ни к какому заключению. Есть ли лучшая практика, предложения и др. c.

Answer 1

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

На практике нет большой разницы

{
    "Name" : "Johny English",
    "Id": "534dsf",
    "Message":[
        {
            "Header":"Country of origin",
            "Value":"England"
        },
        {
            "Header":"Nature of work",
            "Value":"Secret Agent/Spy"
        }
    ]
}

или

{
    "Name" : "Johny English",
    "Id": "534dsf",
    "Message": {
        "Country of origin": "England",
        "Nature of work": "Secret Agent/Spy"
    }
}

В первые дни всемирной паутины «все» - это пары ключ-значение, потому что было легко описать набор пар ключ-значение в таком так, чтобы с ним мог работать компонент общего назначения, такой как веб-браузер (ie, определения форм HTML). Он сделал свою работу.