REST Zend Framework, Как управлять версиями на основе модуля маршрутизации и Api Key - PullRequest
2 голосов
/ 18 сентября 2010

Я создаю сервисы RESTful API с ZF 1.10.8, так как я новичок, он немного сбивает с толку при работе с ZF-маршрутизацией.

Мне нужно иметь версию, api_key и формат ответа в URL, что-то вроде:

/: version /: response_format /: api_key /: controller ... /1.0/json/1234567890/articles/

Версия основана на модуле с последней версией по умолчанию

Как это сделать?

Ответы [ 2 ]

4 голосов
/ 03 августа 2011

Управление версиями на самом деле не так просто, как поместить / v1 / в URI.Фактически, это делает API не-REST.

Для правильного выполнения REST каждый ресурс (вещь, к которой хочет получить доступ клиент) имеет один и только один URI.URI остается неизменным для v1 & v2 & v2;что меняет то, как вы представляете этот ресурс клиенту.

  • Как узнать, какую версию они хотят?Они устанавливают его как заголовок запроса.
  • Как вы узнаете, в каком формате (json, xml, html, wml и т. Д.) Они хотят его видеть?Они устанавливают его как заголовок запроса.
  • Как вы знаете, на каком языке они хотят?Заголовок запроса.

Следует помнить, что URI, который они запрашивают , остаются теми же .Поскольку каждый ресурс имеет только 1 URI, вы никогда не захотите имя метода в URI.

Это плохо: - / edit / place / 43

Вместо этого вы должны использовать правильные методы HTTP- чтобы создать место, выполните HTTP POST в / place - для просмотра места 43, выполните HTTP GET в / place / 43 - чтобы обновить место 43, выполните HTTP PUT в / place / 43 - чтобы удалить место 43, выполнитеHTTP-УДАЛЕНИЕ в / place / 43

При возврате ответа клиенту вы должны также включить URI всех связанных битов данных, которые клиент может захотеть получить следующим.Один из принципов REST заключается в том, что после подключения клиент может найти все необходимые ему URI в самом API.Для входа в систему требуется только один URI, и с этого момента все требуемые URI предоставляются в ответах.Преимущество этого состоит в том, что вы можете изменять свои URI по желанию, поскольку клиент никогда не должен обращать внимание на то, чем они являются ... просто используя их по мере необходимости (т. Е. Клиент знает, на что указывает URI, а не на то, куда он указывает.).

Наконец, имейте в виду, что вы не хотите отправлять маркеры успеха / ошибок в формате xml или json.Они должны быть отправлены обратно как коды ответов HTTP.Есть код для создания, один для удаления, один для обновления и т. Д.

Вот несколько фантастических статей о REST в целом и выполнении REST с Zend Framework, в частности:

Я особенно рекомендую статью на weierophinney.net, для подробностей реализации.

0 голосов
/ 09 марта 2011

Это всего лишь идея, но я бы не хотел, чтобы код вообще что-либо знал о версии.(Кроме того, что является его текущим номером версии.) Вместо этого я бы сделал /: version / часть вашего URI базой в вашей схеме перезаписи.

Таким образом, вместо базы будет что-то вроде: "http://www.example.com/"

Это может быть: "http://www.example.com/1.0/"

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

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

Например: отправка GET на http://www.example.com/2.0/ с номером версии в заголовке 1.0 выдает ошибку «неправильная версия».Ваш код должен знать только то, что header_version! = Current_version, поэтому его не нужно менять по мере выпуска новых версий.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...