Я нахожусь в процессе разработки REST API и быть настолько RESTful, насколько это возможно. Я хочу включитьHATEOAS в ответы JSON.

Добавление URL-адресов к связанным ресурсам достаточно просто, но было некоторое обсуждение структуры, которая будет использоваться для этих ссылок.

Множество статей, которые я нашел, используют структуру, заимствованную изАТОМ каналы:

"links": [ 
    {"rel": "self", "href":"http://example.org/entity/1"},
    {"rel": "friends", "href":"http://example.org/entity/1/friends"}, ... 
]

Это подняло некоторые вопросы:

Зачем использовать массив в качестве контейнера? По словам известного разработчика javascript, доступ к ссылкам будет проще, если ссылки являются свойствами объекта. Например:

"self":    { "href":"http://example.org/entity/1" }, /* (facebook uses this) */  
"friends": { "href":"http://example.org/entity/1/friends", "type": "..."}

Есть ли общая структура JSON (кроме адаптации атома снова)описать ссылки в свойствах ресурса? (например, отправитель сообщения).

Ссылка, вероятно, должна быть снова преобразована в URL-адрес, но будет ли плохо также включать простой идентификатор? вроде как:

"sender": { 
    "id": 12345,
    "href": "resource-uri"
}

Я думаю, что, хотя HATEOAS делает так, чтобы клиенту не требовалось много знаний для использования API, я неохотно отказываюсь от возможности использовать эти знания (например, для доступа к изображению профиля путем создания ссылки). на стороне клиента без предварительного поиска пользователя).