Сообщение Re[3]: REST API, практические вопросы от 06.05.2016 9:03
Изменено 06.05.2016 9:07 ·
Здравствуйте, Artem Korneev, Вы писали:
J>>Если переделать http, для современного веба, то по правильному http get — надо убать вообще.
J>>http post надо кешировать как сейчас http get
AK>Зачем такие сложности? Поддержка передачи параметров в "body" вполне решила бы проблему с длиной URL.
Только по стандарту это может не работать. Если ты передаёшь body в get, то сервер SHOULD игнорировать. Информация возвращаемая должна зависеть только от url.
https://tools.ietf.org/html/rfc2616#section-4.3
Т.е. один из сильных аргументов rest "а давайте чтобы всё быстрее заработало — поставим обычный кеширующий http прокси" — вдруг всё поломает, т.к. прокси (да и любые другие компоненты) может игнорировать тело get и иметь ограничение на длину url.
Как последнее средство — попробовать передизайнить ваш API чтобы не приходилось слать большие списки в get.
Так что при всём богатстве выбора — альтернативы post нет.
J>>Если переделать http, для современного веба, то по правильному http get — надо убать вообще.
J>>http post надо кешировать как сейчас http get
AK>Зачем такие сложности? Поддержка передачи параметров в "body" вполне решила бы проблему с длиной URL.
Только по стандарту это может не работать. Если ты передаёшь body в get, то сервер SHOULD игнорировать. Информация возвращаемая должна зависеть только от url.
https://tools.ietf.org/html/rfc2616#section-4.3
https://tools.ietf.org/html/rfc2616#section-9.3if the request method does not include defined semantics for an entity-body, then the message-body SHOULD be ignored when handling the request.
The GET method means retrieve whatever information (in the form of an entity) is identified by the Request-URI.
Т.е. один из сильных аргументов rest "а давайте чтобы всё быстрее заработало — поставим обычный кеширующий http прокси" — вдруг всё поломает, т.к. прокси (да и любые другие компоненты) может игнорировать тело get и иметь ограничение на длину url.
Как последнее средство — попробовать передизайнить ваш API чтобы не приходилось слать большие списки в get.
Так что при всём богатстве выбора — альтернативы post нет.
Re[3]: REST API, практические вопросы
Здравствуйте, Artem Korneev, Вы писали:
J>>Если переделать http, для современного веба, то по правильному http get — надо убать вообще.
J>>http post надо кешировать как сейчас http get
AK>Зачем такие сложности? Поддержка передачи параметров в "body" вполне решила бы проблему с длиной URL.
Только по стандарту это может не работать. Если ты передаёшь body в get, то сервер SHOULD игнорировать. Информация возвращаемая должна зависеть только от url.
https://tools.ietf.org/html/rfc2616#section-4.3
Т.е. один из сильных аргументов rest "а давайте чтобы всё быстрее заработало — поставим обычный кеширующий http прокси" — вдруг всё поломает, т.к. прокси (да и любые другие компоненты) может игнорировать тело get и иметь ограничение на длину url.
Как последнее средство — попробовать передизайнить ваш API чтобы не приходилось слать большие списки в get.
Ещё можно свой http verb ввести, это стандарт позволяет.
Так что при всём богатстве выбора — альтернативы post нет.
J>>Если переделать http, для современного веба, то по правильному http get — надо убать вообще.
J>>http post надо кешировать как сейчас http get
AK>Зачем такие сложности? Поддержка передачи параметров в "body" вполне решила бы проблему с длиной URL.
Только по стандарту это может не работать. Если ты передаёшь body в get, то сервер SHOULD игнорировать. Информация возвращаемая должна зависеть только от url.
https://tools.ietf.org/html/rfc2616#section-4.3
https://tools.ietf.org/html/rfc2616#section-9.3if the request method does not include defined semantics for an entity-body, then the message-body SHOULD be ignored when handling the request.
The GET method means retrieve whatever information (in the form of an entity) is identified by the Request-URI.
Т.е. один из сильных аргументов rest "а давайте чтобы всё быстрее заработало — поставим обычный кеширующий http прокси" — вдруг всё поломает, т.к. прокси (да и любые другие компоненты) может игнорировать тело get и иметь ограничение на длину url.
Как последнее средство — попробовать передизайнить ваш API чтобы не приходилось слать большие списки в get.
Ещё можно свой http verb ввести, это стандарт позволяет.
Так что при всём богатстве выбора — альтернативы post нет.