Существует ли тип носителя по умолчанию для GET и других методов

Question

Существует ли тип носителя по умолчанию, когда в запросе не указан ни один из поддерживаемых типов носителей в RESTCONF?

Answer 1

Нет. Стандартного значения по умолчанию нет. Это зависит от реализации сервера, поэтому не полагайтесь на него.

Из https://tools.ietf.org/html/draft-ietf-netconf-restconf-17, Кодировка сообщений:

Сервер ДОЛЖЕН поддерживать поле заголовка "Accept" и строку состояния "406 Not Acceptable", как определено в [RFC7231]. Форматы кодирования содержимого вывода ответа, которые будет принимать клиент, идентифицируются с помощью поля заголовка Accept в запросе. Если он не указан, СЛЕДУЕТ использовать формат кодировки входного запроса, или сервер МОЖЕТ выбрать любой поддерживаемый формат кодирования контента.

Если не было входного запроса, то выходной кодировкой по умолчанию является XML или JSON, в зависимости от предпочтений сервера. Расширения файлов, закодированные в запросе, не используются для идентификации формата кодирования.

И из https://tools.ietf.org/html/draft-ietf-netconf-restconf-17, Сообщение об ошибке:

Клиенту СЛЕДУЕТ указать желаемую кодировку (-и) для ответных сообщений, указав соответствующий медиа-тип (-ы) в заголовке Accept. Если клиент не указал заголовок Accept, СЛЕДУЕТ использовать тот же суффикс имени структурированного синтаксиса, который используется в сообщении запроса, или сервер МОЖЕТ выбрать любой поддерживаемый формат кодировки сообщений. Если сообщение с запросом отсутствует, сервер ДОЛЖЕН выбрать "application/yang-data+xml" или "application/yang-data+json", в зависимости от предпочтений сервера.

Answer 2

Окончательный RFC поддержал проект, как сказал @predi:

О кодировании сообщений, раздел 5.2:

Если не было входного запроса, то выходной кодировкой по умолчанию является XML или JSON, в зависимости от предпочтений сервера. Расширения файлов, закодированные в запросе, не используются для идентификации формата кодирования.

И ответ на сообщение об ошибке, раздел 7.1

Если клиент не указал заголовок "Принять", то ДОЛЖЕН использоваться тот же суффикс имени структурированного синтаксиса, который используется в сообщении запроса, или сервер МОЖЕТ выбрать любой поддерживаемый формат кодировки сообщений. Если сообщение с запросом отсутствует, сервер ДОЛЖЕН выбрать "application/yang-data+xml" или "application/yang-data+json", в зависимости от предпочтений сервера.