Який тип MIME є найбільш відповідним для використання при передачі даних, структурованих за допомогою YAML через HTTP?
Пояснення, чому даний вибір є найбільш відповідним, було б вдячним.
Немає зареєстрованого типу програми чи типу тексту, який я бачу.
Приклад:
> GET /example.yaml
< Content-Type: ????
<
< --- # Favorite movies
< - Casablanca
< - North by Northwest
< - Notorious
Можливі варіанти:
text/yaml
text/x-yaml
application/yaml
application/x-yaml
Відповіді:
Ruby on Rails використовує application/x-yamlальтернативу text/yaml( джерело ).
Я думаю, що це лише питання конвенції, немає технічних причин, наскільки я можу сказати.
text/*без явного charset=параметра вважається ISO-8859-1, але речі в application/*тексті не обов'язково є текстовими. (RFC, з яким ви пов’язані, стосується XML, не впевнений, наскільки це актуально.)
If a "charset" parameter is specified, it SHOULD be a required parameter, eliminating the options of specifying a default value. If there is a strong reason for the parameter to be optional despite this advice, each subtype MAY specify its own default value, or alternatively, it MAY specify that there is no default value. Finally, the "UTF-8" charset [RFC3629] SHOULD be selected as the default.. Офіційного визначення text/yamlnі немає text/x-yaml, тому типовим є UTF-8.
US-ASCII(зауважте: ні ISO-8859-1) для text/*типів медіа в RFC 2046 застаріло Regardless of what approach is chosen, all new text/* registrations MUST clearly specify how the charset is determined; relying on the US-ASCII default defined in Section 4.1.2 of [RFC2046] is no longer permitted.в tools.ietf.org/html/rfc6838#section-4.2.1 у січні 2013 року. Ні RFC 3023, ні RFC 7303 не говорять нічого загального про text/*AFAIK.
UTF-8це стандартне значення для кожного text/*типу медіа, який не реєструє щось інше в своїй реєстрації IANA.
Хоча було прийнято ще одну відповідь, будь ласка, зверніться до цієї пропонованої реєстрації носіїв для потоку YAML у списку розсилки IANA, щоб переглянути тип медіа, в якому Бен Харріс, Університет Кембриджської служби інформації, запропонував у липні 2015 року від імені команди YAML тип ЗМІ :
text/vnd.yaml
із (запропонованим) застарілим псевдонімом:
text/yaml
text/x-yaml
application/x-yaml
Це все ще пропонується / очікує на розгляд (нитка не вказує статусу пропозиції), тому ця відповідь є не остаточнішою, ніж інші :-)
Я б сказав текст / x-yaml:
текст над програмою, оскільки це читається людиною
x-yaml над yaml, оскільки він не був внесений до зареєстрованого списку типів mime.
Редагувати: від RFC 3023 (типи носіїв XML):
"Текст" медіа верхнього рівня має деякі обмеження для об'єктів MIME, і вони описані в [RFC2045] та [RFC2046]. Зокрема, сімейства UTF-16, UCS-4 та UTF-32 заборонені (за винятком HTTP [RFC2616], який використовує MIME-подібний механізм).
Цікаво ... Не зовсім впевнений, що це означає, але їжа для роздумів.
application/yaml, як ми можемо сказати application/jsonі applicaiton/xml.
Типи носіїв "x-" не перешкоджають, див. RFC 4288, Розділ 3.4 . Правильно зробити, це використовувати особисте дерево, дерево постачальника або фактично спробувати належну реєстрацію типу медіа.
application/vnd.yamlабо text/vnd.yaml(текст , здається , краще)
x.. vnd.і prs.вимагають реєстрації. Див. Tools.ietf.org/html/rfc6838#section-3.2 та tools.ietf.org/html/rfc6838#section-3.3 .
На Chrome application/yamlзавантажуватимуть, а text/yamlвідображатимуть.
Відповідно до списку типів MIME, він є text/yaml, хоча його немає в офіційному списку IANA MIME
text/, підлягають обробці як ISO-8859-1, якщо інший тип mime не буде явно оголошено (наприклад,text/html; charset=utf-8). Типи мім, які починаються зapplication/, обробляються як UTF-8, якщо інший тип мім явно не оголошено. Наприклад,text/x-yamlне можна використовувати символи UTF-8, покиtext/x-yaml; charset=utf-8іapplication/x-yamlможе. IIRC, це визначено у RFC 3023.