tools.ietf.org
Много хороших уточнений, но на этот раз они "взяли и все сломали": сделали список ключей фиксированным, что в общем-то и правильно, но стало многословней.
joelonsql.com
До чего прогресс дошел... Интересно, будут ли попытки создать на этом PostgreSQL-based web-сайт и все такое?
#1745984 решил погуглить вопрос о версионировании http api и, собственно, большая часть идей сводится к двум ответам на stackoverflow:
stackoverflow.com
1. Версионирование через ветки url. Например: example.com/2.1/foo/bar/baz ; example.com/1.4/gav/gav/gav. В добавок к этому, есть ветка без указания версии example.com/foo/bar/baz, которая должна делать редирект на актуальную версию. Все бы прекрасно, но как-то через-чур избыточно.
2. Версионирование через медиа тип. Например: application/vnd.example.myapp-v3+json. Красиво, но если только у нас свой формат. В случае json большинство средств его обработки ожидает медиа тип application/json, для xml — application/xml. Соответственно мы рискуем получить множество проблем с кодированием/декодированием данных, поскольку вряд ли большинство библиотек проектировалось с с мыслью, что стандартные медиа типы могут измениться внезапно завтра.
3. Версионирование через данные. Например <?xml version="1.0"?><foo version="2.3.4-dev"/>. Вроде данные явно указывают согласно какой версии спецификации их обрабатывать, но такая информация должна быть размещена в заголовках — не зря их называют метаданными — иначе серверу возможно придется прочитать полностью все 500 мегабайт данных просто чтобы понять, что указанная версия более не поддерживается, а следовательно время и ресурсы потрачены зря.
В качестве развития мысли второго варианта можно использовать свой произвольный заголовок, например X-API-VERSION, и его значение обрабатывать согласно, например, тому же semver.org
Мне кажется такой вариант хорошим компромиссом т.к. мы не плодим кучу ресурсов, не заменяем стандартные медиа типы на вендорные,. но в тоже время следуем семантике HTTP протокола и наш заголовок несет атомарную функциональность. Да, тут #1740551 оказывается предлагают X- выкинуть как анархизм, но это тянет на холивар и уже совсем другая история(:
После stackoverflow.com
1. Версионирование через ветки url. Например: example.com/2.1/foo/bar/baz ; example.com/1.4/gav/gav/gav. В добавок к этому, есть ветка без указания версии example.com/foo/bar/baz, которая должна делать редирект на актуальную версию. Все бы прекрасно, но как-то через-чур избыточно.
2. Версионирование через медиа тип. Например: application/vnd.example.myapp-v3+json. Красиво, но если только у нас свой формат. В случае json большинство средств его обработки ожидает медиа тип application/json, для xml — application/xml. Соответственно мы рискуем получить множество проблем с кодированием/декодированием данных, поскольку вряд ли большинство библиотек проектировалось с с мыслью, что стандартные медиа типы могут измениться внезапно завтра.
3. Версионирование через данные. Например <?xml version="1.0"?><foo version="2.3.4-dev"/>. Вроде данные явно указывают согласно какой версии спецификации их обрабатывать, но такая информация должна быть размещена в заголовках — не зря их называют метаданными — иначе серверу возможно придется прочитать полностью все 500 мегабайт данных просто чтобы понять, что указанная версия более не поддерживается, а следовательно время и ресурсы потрачены зря.
В качестве развития мысли второго варианта можно использовать свой произвольный заголовок, например X-API-VERSION, и его значение обрабатывать согласно, например, тому же semver.org
Мне кажется такой вариант хорошим компромиссом т.к. мы не плодим кучу ресурсов, не заменяем стандартные медиа типы на вендорные,. но в тоже время следуем семантике HTTP протокола и наш заголовок несет атомарную функциональность. Да, тут #1740551 оказывается предлагают X- выкинуть как анархизм, но это тянет на холивар и уже совсем другая история(:
tools.ietf.org
После множества статей про REST у меня сложилось стойкое déjà vu, хотя, наверное, имеет право на жизнь.
tools.ietf.org
428 Precondition Required
429 Too Many Requests
431 Request Header Fields Too Large
511 Network Authentication Required