Введение В первый Частично я начал делиться своими наблюдениями по поводу реализации HTTP/GET в REST. В этой статье мы попытаемся рассмотреть вопросы версионирования и архитектуры.
Начнем?
Управление версиями — это то, без чего ваш API бесполезен.
Помните последнюю публикацию? URL/URN/URI/resource/slug — мы рассмотрели все эти понятия.
Что еще? Все обращения из первой статьи синтетические и не имеют никакого отношения к реальному проекту.
ЭТО НЕ СПОСОБ НАПИСАТЬ API! Это невозможно, поскольку в URI полностью отсутствует такая важная вещь, как управление версиями .
Почему УРИ? Почему не URL? Почему не УРН? Да, потому что наш API предоставляет доступ к состояниям объектов внутри коллекций.
Те.
Нам не важно, какой URL (читай «на каком сервере») или какой URN (читай «какой бэкенд») будет у объекта, нам важно знать, какую версию объекта мы используем.
Тема версионирования API фигурирует в различных источниках, но сформулирована она, на мой взгляд, не очень удачно.
Считается, что управление версиями позволит избежать смешивания различных реализаций API (т. е.
версии связаны с URL/URN).
И сейчас откровение : А кто запретил демону (URN), работающему на сервере (URL), обслуживающем коллекцию (ресурс), версии v2, принимать объекты версии v1? Поскольку объект имеет версию v1, он перестает быть действительным? Объект пользователя перестал быть пользователем? Не понятно? ХОРОШО.
Давайте по порядку.
Архитектура
Из материалов Википедия В разделе «REST архитектура» есть следующие строки:Клиент может взаимодействовать не напрямую с сервером, а с произвольным количеством промежуточных узлов.есть также список целей, которых мы пытаемся достичьПри этом клиент может не знать о существовании промежуточных узлов, за исключением случаев передачи конфиденциальной информации.
Чего хотел добиться автор? Нет, «мир во всем мире» — это понятно, но все же… Попробуем декомпозировать задачу и использовать «типичные» решения горизонтального масштабирования:
- масштабируемость
- портативность компонентов
- простота внесения изменений
- способность развиваться
- Мы реализуем множество серверов, обслуживающих клиентские запросы через DNS.
- На каждом сервере у нас есть балансировка между несколькими бэкэндами на разных внутренних серверах.
- Каждый бэкэнд имеет от 1 до n коллекций
- Сервер №1 с серверной частью, содержащей коллекцию пользователей
- Сервер №2 с серверной частью, содержащей коллекцию групп.
При извлечении пользователей из групп определите, существует ли еще этот пользователь в коллекции пользователей, и если нет, удалите его из коллекции групп и не передавайте информацию о нем пользователю.
Давайте теперь оставим тонкости URL/URN/URI/и т.д. и того, что через них передается.
Вопрос в том, как добиться согласованного состояния в распределенной системе? Первое, что приходит на ум — использовать тот же REST для следующей коллекции, но где взять отказоустойчивый сервер с кэшированием и балансировкой нагрузки?! ОСТАНАВЛИВАТЬСЯ! Так что все уже есть! Бери и пользуйся! Хм.
ок, у нас есть масштабируемый http-кластер (да, я знаю, что это не кластер в строгом смысле этого слова), но причем здесь версионирование? И несмотря на то, что в распределённой системе, поддерживающей коммуникации между участниками, городить сад со старым стеком API не рационально (читай «сделать ещё один кластер поменьше»).
А в некоторых случаях перетаскивать серверные части между версиями.
Например, во 2 версии изменилась только коллекция пользователей и добавились контакты.
Как группы перейдут на версию 2?
Критикам
Предсказывая вопросы, постараюсь прояснить некоторые моменты.О чем мы говорим? Какая ерунда? Дело в том, что управление версиями — это свойство коллекции, а не API. В противном случае никакого масштабирования.
У вас проблемы с архитектурой.
Должно быть что-то вроде этого: /groups/имя_группы/users/имя_пользователя.
Да, это правда, но: .
пока пользователь может находиться в одной группе, иначе у вас будет 2 или более URI, возвращающих один и тот же объект. .
при условии, что у пользователя должна быть группа, иначе придется вводить фейковые группы (по умолчанию, глобальные, системные, все - неужели информативно?) REST для связи в распределенной системе? Ты сошел с ума?! Не волнуйтесь, я знаю, что «белые люди» используют для этого асинхронные кластерные брокеры сообщений поверх транспортных каналов с гарантированной пропускной способностью и прочих прелестей корпоративных систем.
Это «синтетический» пример, и не так уж и плохо в пределах 3-5 серверов.
Это все, что у вас есть для версионирования? О, нет! Я только начал! P.S. Друзья, сейчас 3 часа, а это значит, что пора спать.
Прошу всех высказаться в комментариях.
Очень сложно писать без вашего отзыва.
Теги: #rest #restful #rest api #crud #json #api #programming
-
Как Быстро Включится Windows 8?
19 Oct, 24 -
Сайты Google Открыты Для Всех
19 Oct, 24 -
Интерфейс Adsense – На Любом Сайте
19 Oct, 24
