#rest #architecture #httpverbs
#rest #архитектура #http-глаголы
Вопрос:
Если у вас есть API и вы поддерживаете операцию POST только из-за ограничений длины URL-адреса и передачи сложных параметров в запросе, можете ли вы по-прежнему утверждать, что у вас архитектура RESTful?
Что в основном подразумевает вышесказанное, так это то, что для этого конкретного (только для чтения) В API нет семантической разницы между GET и POST, поэтому то, что можно сделать с помощью GET, также может быть сделано с помощью POST (но не наоборот из-за ограничений).
Все еще ли это сделает стиль архитектуры RESTful?
Ответ №1:
Технически вы не нарушаете никаких ограничений. Однако вы серьезно снижаете самоописываемость запросов. Это приведет к потере возможности кэширования ответов. Возможность кэширования ответов является важной функцией, которая необходима для создания эффективных систем REST.
Комментарии:
1. 1 Это важный момент. Я бы также предположил, что если вы сталкиваетесь с ограничением символов URL-адреса, было бы разумно изучить вашу схему URL-адресов, чтобы увидеть, могут ли быть возможности для рефакторинга. Может быть слишком много параметров запроса, точно так же у вас может быть слишком много параметров функции или метода.
Ответ №2:
Вы определенно потеряете функциональность, предоставляемую HTTP для запросов GET. Прокси, например, делают определенные предположения о запросах GET (идемпотентность, кэшируемость).
В обработке POST perse нет ничего плохого, но, возможно, метод REPORT более подходит.
Комментарии:
1. ОТЧЕТ? Это не HTTP-метод.
2. @Darren Miller: Это не стандартный метод, нет. Но спецификация HTTP допускает пользовательские методы.
3. Да, это расширение; точно так же, как PATCH и многие другие. Действительно, в спецификациях HTTP должны быть разрешены расширения. Я полагаю, это было одной из целей HTTP / 1.1.
4. @jgauffin Спецификация HTTP допускает расширения, если вы готовы приложить усилия для продвижения новой общедоступной спецификации через IETF. Для утверждения ИСПРАВЛЕНИЯ потребовались годы
http://tools.ietf.org/html/rfc5789Вы «ДОЛЖНЫ» не просто создавать свои собственные.5. ОТЧЕТ не составлен. Смотрите: tools.ietf.org/html/draft-ietf-httpbis-method-registrations-05 . Оно появилось в нескольких HTTP-расширениях, начиная с 2002 года.
Ответ №3:
Итак, вопрос здесь касается архитектуры restful, а не веб-служб restful.Если мы будем руководствоваться информацией, приведенной в Wiki-RestfulArch-Constraints , да, это так.
Ответ №4:
Термин «Передача репрезентативного состояния» был введен и определен в 2000 году Роем Филдингом в его докторской диссертации. В разделе 6.3 объясняется, как применить REST к HTTP:http://www.ics.uci.edu /~fielding/pubs/dissertation /evaluation.htm#sec_6_3
Филдинг не утверждает, что использование POST запрещено.
Википедия также упоминает POST как легальную HTTP-операцию для веб-служб RESTful:http://en.wikipedia.org/wiki/Representational_State_Transfer#RESTful_web_services
Комментарии:
1. Использование GET для всего является нарушением стандарта HTTP, в котором четко указано, что GET следует использовать только для ресурсов, которые не изменяются . Цитата из RFC:
the convention has been established that the GET and HEAD methods SHOULD NOT have the significance of taking an action other than retrieval. Очень важно соблюдать это утверждение.2. jgauffin Никто не говорит об использовании GET для небезопасных операций, они говорят об использовании POST для безопасных операций!
3. @jgauffin Конечно, публикация разрешена. Это тоже не вопрос. Вопрос в том, можете ли вы использовать POST для вещей, которые обычно являются GET. т. Е. безопасными и идемпотентными запросами. Ответ — да, вы можете, но это не очень хорошая идея.
4. Я просто исправил ceving до того, как он отредактировал свой ответ. Я сталкивался со многими разработчиками, которые хотят использовать GET для всех вызовов. Что касается вопроса: не имеет значения, что говорится в вопросе, когда я комментирую (неправильный) ответ.
Ответ №5:
Почему бы вам просто не переключиться на включение тела в GET вместо использования строки запроса?
Обновить
В RFC говорится следующее:
Сервер ДОЛЖЕН считывать и пересылать тело сообщения по любому запросу; если метод запроса не включает определенную семантику для тела объекта, тогда тело сообщения СЛЕДУЕТ игнорировать при обработке запроса
В спецификации ничего не говорится о том, что тело не может быть включено ни в один из методов. И все прокси, серверы и т.д. Обязаны включать тело. Игнорировать тело или нет — зависит от обработчика (вас).
Что касается метода GET, ничто не указывает, что он не может включать тело.
Это означает, что вы можете использовать тело GET до тех пор, пока ваш веб-сервер поддерживает его.
Комментарии:
1. Поскольку спецификация HTTP гласит, что тело GET ничего не значит и может быть отклонено серверами или посредниками.
2. Однако это плохая идея; Хотя ваш http-стек должен поддерживать это, я сомневаюсь, что они на самом деле поддерживают. Также отсутствует семантика для «отрицания содержимого», основанная на теле запроса в GET. (хотя технически это не является согласованием содержимого, вы не можете изменять: тело .. в основном).
3. Вы правы. Я только что попробовал с
HttpListenerиHttpWebRequestв .NET, и это не сработало.4. Когда вы ссылаетесь на спецификации, хорошей идеей будет включить ссылку
http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-14#section-7.3«Тела в запросах GET не имеют определенной семантики. Обратите внимание, что отправка тела запроса GET может привести к отклонению запроса некоторыми существующими реализациями.»5. В RFC «ДОЛЖЕН» имеет очень точное значение. Перефразирование «обязан» на самом деле не помогает. Если в спецификации не указано «ОБЯЗАТЕЛЬНО», вам придется иметь дело со сценарием, когда правила не были соблюдены.