Версионирование RESTful сервисов?

У меня есть веб-служба RESTful, развернутая по адресу http://example.com/v1/SomeResource. Однажды новая версия протокола (которая не имеет обратной совместимости) развернута на http://example.com/v2/SomeResource. С точки зрения клиента, это обновление может произойти в любое время между двумя HTTP-запросами.

Как сервер указывает клиенту, что он больше не поддерживает вызовы v1, и ожидается, что клиент обновится до v2? Можно ли использовать соответствующий код ответа?

Я хотел бы предоставить клиенту следующую информацию:

  1. Произошло несовместимое обновление. Клиент не может использовать новую услугу, поскольку протокол может быть совершенно другим.
  2. URL нового клиентского программного обеспечения.
  3. Сообщение, объясняющее пользователям, что они должны обновить.
Источник

4 ответа

Решение

Лучшая практика:

Вероятно, лучше не указывать версии в URL и сделать новые ресурсы обратно совместимыми со старыми.

Обратная совместимость:

Если вы должны сохранить v1 в URL-адресе и создавать v2-URL-адреса, то вам нужно решить, хотите ли вы поддерживать оба формата или сделать старый v1 устаревшим. Если вы решите сделать старый v1 устаревшим, тогда я рекомендую вернуть 303 или 401 для любого, кто запрашивает URL v1.

Как сделать старые URL устаревшими:

Я бы порекомендовал использовать 303 См. Другое. Или, если нет никакого связанного перенаправления, тогда используйте 410 Gone.

Источник

303 См. Другое

Ответ на запрос может быть найден под другим URI и ДОЛЖЕН быть получен с использованием метода GET для этого ресурса. Этот метод существует главным образом для того, чтобы позволить выводу сценария, активированного POST, перенаправить пользовательский агент на выбранный ресурс. Новый URI не является заменой ссылки на первоначально запрошенный ресурс. Ответ 303 НЕ ДОЛЖЕН кэшироваться, но ответ на второй (перенаправленный) запрос может быть кэширован.

Другой URI ДОЛЖЕН быть задан в поле Location в ответе. Если метод запроса не был HEAD, объект ответа ДОЛЖЕН содержать краткую гипертекстовую заметку с гиперссылкой на новый URI.

Примечание. Многие пользовательские агенты до HTTP/1.1 не понимают статус 303. Когда взаимодействие с такими клиентами является проблемой, вместо этого может использоваться код состояния 302, поскольку большинство пользовательских агентов реагируют на ответ 302, как описано здесь для 303.

Документируйте все:

Главное, о чем следует беспокоиться, это то, что вы решили вернуть, просто запишите это в своей документации. Вы можете решить, как вы хотите, чтобы ваша служба работала, а другие, которые захотят ее использовать, будут следовать документации.

Источник

Я рекомендую следующую статью Питера Уильямса

Источник

Я думаю, вы не должны делать это в первую очередь, но, вероятно, уже слишком поздно.

URI также должны быть статическими, чтобы при изменении ресурса или реализации службы ссылка оставалась прежней. Это позволяет делать закладки. Также важно, чтобы отношения между ресурсами, закодированными в URI, оставались независимыми от способа представления отношений там, где они хранятся.

Из статьи RESTful Web-сервисы: Основы.

Источник

Я бы рекомендовал вместо этого использовать 301 (301 перемещено навсегда). Прочитайте почему.

Надеюсь, это поможет, Бруно Фигейредо

Источник
Другие вопросы по тегам