Каким должен быть стандарт для ReSTful URLS?

Question

Поскольку я не могу найти работу, я читал о ReST и создавал веб-сервисы. В моем понимании, будущее за созданием веб-службы для всех ваших данных до того, как вы создадите веб-приложение. Что кажется хорошей идеей.

Однако, похоже, что существует множество противоречивых мнений о том, какая схема лучше всего подходит для URL-адресов ReSTful.

Некоторые люди защищают простые красивые URL

http://api.myapp.com/resource/1

Кроме того, некоторым людям нравится добавлять версию API в URL, например:

http://api.myapp.com/v1/resource/1

И чтобы еще больше запутать, некоторые люди рекомендуют добавлять тип контента для получения запросов

http://api.myapp.com/v1/resource/1.xml
http://api.myapp.com/v1/resource/1.json
http://api.myapp.com/v1/resource/1.txt

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

Оооооооооо .... Это много вариаций, из-за которых я не уверен, какая из лучших схем URL-адресов. Я лично вижу достоинства наиболее полного URL, который включает номер версии, локатор ресурса и тип контента, но я новичок в этом, поэтому я могу ошибаться.

С другой стороны, вы можете утверждать, что вам следует делать «все, что лучше для вас». Но, насколько я могу судить, это не совсем соответствует менталитету ReST, поскольку цель состоит в том, чтобы иметь стандарт.

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

Каким должен быть стандарт для URL ReSTful?

Answer 1

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

REST не является отличным решением для предоставления услуг передачи данных для вашего веб-приложения. «Веб-сервисы» (или SOAP, XML-RPC, WSDL, HTTP-POX) могут быть хороши для этого, но архитектурный стиль REST гораздо больше ориентирован на сценарии клиент-сервер, чем сценарии сервер-сервер.

Хватит думать о том, как выглядят URL. То, как они выглядят, имеет гораздо больше общего с тем, какую серверную часть вы используете для реализации службы RESTful, чем с дизайном самой службы. Клиент должен обнаруживать URL-адреса из ранее извлеченных представлений, поэтому ему все равно, как выглядят эти URL-адреса.

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

Не версии ресурсов. То есть, если у вас есть ресурс, к которому обращается URL http://example.org/TodaysWeather, никогда не создавайте ресурс на http://example.org/V2/TodaysWeather. Существует множество других лучших способов создания версий версий, чем создание целого нового ресурса. Ищите так много других обсуждений по этому вопросу.

Что касается создания разных ресурсов для разных типов контента, я считаю, что это решение зависит от контекста. Если ваш конечный пользователь использует браузер для доступа к службе REST, и он достаточно сложен, чтобы понять разницу между JSON и XML, тогда создайте два ресурса. Если это клиент компьютера, я бы использовал согласование содержимого для получения необходимого формата.

И, наконец, будьте осторожны, поскольку REST стал умным словом du jour, вокруг гораздо больше неверно информированного контента, чем допустимого контента.

Answer 2

Я с S.Lott - там не должен быть * глагол *, так как вы хотите использовать тот же URL-адрес для чтения записи и для ее обновления, чтобы она квалифицировалась как REST.

Тип содержимого - это что-то еще, что можно пропустить, так как это та же запись, но с несколькими форматами кодирования. (Читайте о FRBR больше, чем вы когда-либо хотели узнать о проблемах различия). Решение о том, какую версию отправлять в ответ, можно обработать с помощью заголовков HTTP Accept.

Единственный, на котором меня рвут, это номер версии, так как я не могу лично придумать подходящий HTTP-заголовок для обработки этого аспекта. (Ожидайте? Accept-Encoding? Pragma? Может быть, даже Upgrade, но вы бы хотели чаще переходить на более старую версию из соображений совместимости, я бы подумал) Возможно, у меня был бы аксессор без версии, который давал бы самую последнюю версию производственная версия, но может потребоваться версия для существенных изменений, которые не были обратно совместимы.

обновление: проблема с версией, вероятно, зависит от того, насколько вы контролируете клиентов, подключающихся к вашим службам ... если у вас есть доступ от широкой публики (чего нет у меня), вы можете больше интересоваться обратной совместимостью. В зависимости от внесенных изменений, возможно, вы также сочтете «версию 2» совершенно новым ресурсом, а не просто новой «версией» оригинала.

Answer 3

Versioning: я обычно видел это место, где у вас есть это в вашем примере URL, и если версия не указана, вы должны ответить с самой последней рабочей версией. Одно из соображений заключается в том, стоит ли помещать версию API в строку ответа для целей отладки клиента.

Форматы ответов. Формат возврата должен быть указан в заголовке HTTP Accept, отправляемом пользовательским агентом.

Глаголы в строке запроса: Абсолютно нет.

Answer 4

Глагол не может быть помещен в URL. Это бессмысленно. Это уже в заголовке запроса. Когда вы отправляете запрос POST с GET в URL, это безумие.

Формат ответа обычно лучше всего помещать в URL, потому что заголовки не обеспечивают простого, однозначного места для размещения этой информации.