Соглашения об услугах отдыха

Question

В службах «Rest» мы обычно используем запросы «GET», когда хотим получить некоторые данные с сервера, однако мы также можем извлекать данные с помощью запроса «POST». Мы используем «POST» для создания, «PUT» для обновления и «DELETE» для удаления, однако мы можем даже создавать новые данные с помощью запроса «DELETE».

Так что я просто задавался вопросом, что является реальной причиной этого, почему эти соглашения используются?

Answer 1

Так что я просто задавался вопросом, что является реальной причиной этого, почему эти соглашения используются?

Так что мир не разваливается!

Нет, но серьезно, почему есть любой созданы протоколы или стандарты? Возьмите этот исторический сценарий. Еще в ранние дни Google многие разработчики (по сравнению с сегодняшними) не слишком разбирались в HTTP-протоколе. То, что вы могли поймать, было кучей сайтов, которые просто использовали хорошо известный (возможно, только) метод GET. Таким образом, будут ссылки, которые будут GET-запросами, но будут выполнять операции, которые должны были быть POST-запросом, что изменило бы состояние сервера (иногда очень важные изменения состояния). Войдите в Google, который проводит свои дни в Интернете. Итак, теперь у вас есть все эти ссылки, которые Google сканирует, все эти ссылки, которые являются запросами GET, но изменяющие состояние сервера. Таким образом, все эти компании получают кучу хитов на своих серверах, меняющих свое состояние. Они все думают, что на них нападают! Но Google не делает ничего плохого. HTTP-семантика утверждает, что запросы GET не должны иметь изменения состояния поведения. Это должен быть метод «только для чтения». Итак, наконец, эти компании придумали и начали следовать HTTP-семантике. Правдивая история.

Мораль истории: следуйте протоколам, вот для чего они предназначены - следовать.

Вы, кажется, смотрите на него с точки зрения реализации сервера. Да, вы можете реализовать свой сервер, чтобы принять запрос DELETE, чтобы «получить» что-то. На самом деле дело не в этом. При внедрении сервера вам нужно подумать о том, чего ожидает клиент. Я имею в виду, в конечном счете, вы создаете API. Посмотрите на это с точки зрения API кода.

public class Foo { 

    public Bar bar; 

    public Bar deleteBar() { 
     return bar;   // Really?! 
    } 

    public void getBar() { 
     bar = null;   // What the..??! 
    } 
} 

Я не знаю, как долго разработчик продержится в игре, написав код так.Любые абоненты, ожидающие «получить» Bar (просто путем семантики имен), приходит еще одна вещь. То же самое касается ваших услуг REST. Это, в конечном счете, WEB API, и должен следовать семантике протокола (а именно HTTP), на котором он построен. Те, кто понимает протокол, будут иметь представление о том, что делает API (по крайней мере в смысле CRUD), просто на основе типа запроса, который они делают.

Мое предложение вам или любому, кто пытается изучить REST, - это получить хороший дескриптор HTTP. Я бы сохранил следующий документ. Читайте один раз, а затем сохранить его в качестве ссылки

• Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content

Answer 2

GET кэшировано прокси POST и DELETE нет!

Да, вы можете создавать данные с помощью GET, но теперь вам нужно уничтожить этот кеш. Зачем делать дополнительную работу.

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

Answer 3

Я рекомендую прочитать spec, в котором четко указано, как каждый каждый http-метод следует использовать.

Почему эти соглашения используются?

Это конвенции, то есть лучшие практики, принятые в качестве стандарта. Вы не должны придерживаться стандарта, но большинство потребителей услуги REST предполагают, что вы это делаете. Таким образом, проще понять реализацию/интерфейс.