Для простого взаимодействия между внешним интерфейсом и бэкэндом вам не нужно начинать с REST, поскольку он нацелен на случаи, когда к серверу обращается множество клиентов, которые не находятся под вашим контролем, или клиент должен иметь доступ к множеству различных серверов и должен работать со всеми из них. REST должен быть нацелен на то, если вы видите выгоду в сервере, который может развиваться свободно в будущем, не опасаясь взлома клиентов, поскольку они довольно легко адаптируются к изменениям. Такие сильные свойства, однако, имеют свою цену с точки зрения накладных расходов на разработку и тщательного проектирования. Не поймите меня неправильно, вы все равно можете стремиться к архитектуре REST, но для такого простого сценария back-end приложения 2 это звучит как перебор.
В архитектуре REST сервер обычно сообщает клиентам, как он хочет получать входные данные. Подумайте о формах HTML, где атрибуты method и enctype указывают, какой метод HTTP использовать и в какой формат представления вводить данные для преобразования. Какой метод HTTP использовать на самом деле зависит от варианта использования. Если сервер постоянно получает один и тот же запрос для одних и тех же входных параметров, и вычисление результата может быть дорогостоящим, то кэширование ответа один раз и обслуживание дальнейших запросов из этого кэша может отнять у сервера много ненужных вычислительных затрат. Т.е. BB C утверждает, что кеш - это самая важная технология, обеспечивающая масштабируемость и быструю работу сайтов . Однажды я прочитал, что они кэшируют большинство статей всего за минуту, но этого достаточно, чтобы сэкономить их форму, извлекающую один и тот же контент снова и снова тысячи и тысячи раз, освобождая ресурсы для других запросов или задач. Неудивительно, что кеширование также относится к одному из немногих ограничений REST.
HTTP по умолчанию позволит кешам хранить представления ответов для запрошенных URI (включая любой запрос, путь или матрицу). параметры) если запрошено через безопасные операции, такие как HEAD или GET запросы. Однако любая вызванная небезопасная операция приведет к аннулированию кэша и, следовательно, к удалению любых сохраненных представлений для этого целевого URI. Следовательно, любые последующие запросы этого URI будут поступать на сервер для обработки ответа для запрашивающего клиента.
К сожалению, кеширование - не единственный фактор, который следует учитывать, когда следует выбирать между использованием GET или * 1018. * как и текущий формат представления, который клиент обрабатывает в данный момент, влияет на решение. Представьте себе, что клиент обрабатывает предыдущий ответ HTML, полученный от сервера. Ответ HTML содержит форму, которая сообщает клиенту, какие поля сервер ожидает в качестве входных данных, а также выбор, который клиент может сделать для определенных входных параметров. HTML является идеальным примером, когда тип носителя ограничивает, какие методы HTTP доступны (GET как метод по умолчанию и POST поддерживаются), а какие нет (все другие методы HTTP). Другие форматы представления могут поддерживать только POST (т. Е. В то время как application/soap+xml допускает GET или POST (по крайней мере, в SOAP 1.2), я никогда не видел GET запросов в реальности, и поэтому все обмен с POST).
Еще одним моментом, который может помешать вам использовать GET запросов, является фактическое ограничение на длину URI , которое имеется в большинстве реализаций HTTP. Если вы превысите эти ограничения, некоторые каркасы HTTP могут быть не в состоянии обработать обмен сообщениями. Однако, глядя на Интернет, можно найти небольшой обходной путь к такому ограничению. В большинстве интернет-магазинов область оформления заказа обычно разделяется на разные страницы, где каждая страница состоит из формы, которая собирает некоторые входные данные, такие как адресная информация, банковские данные или данные платежа, и далее вводит их, что в целом служит своего рода мастером, который помогает пользователю пройти через процесс оплаты. Такой стиль мастера может быть реализован и в этом случае. Части запроса отправляются через POST на выделенную конечную точку, которая занимается сбором данных, и на последней «странице» мастера сервер запрашивает окончательное подтверждение собранных данных и использует этот ресурс в качестве цели GET. , Таким образом, ответ остается кешируемым, даже если входные данные превышают типичное ограничение URL-адресов, налагаемое некоторыми платформами HTTP.
Хотя аргументы, перечисленные Always Learning, не ошибочны, я бы не стал полагаться на аргументы безопасности точка зрения. Хотя он может отфильтровывать людей с небольшим знанием, он не будет долго мешать тем, у кого есть знания (а их много), чтобы изменить запрос перед отправкой его на ваш сервер. Поэтому мне просто странно рекомендовать использовать PUT в качестве способа усложнения редактирования пользователя.
Итак, в целом, я бы основал решение, использовать ли POST или GET для отправки данных. к серверу в основном из-за того, что ответ должен быть кэшируемым, как это часто запрашивается, или нет. В тех случаях, когда URI может стать настолько большим, что некоторые HTTP-платформы могут не обработать запрос, вы в любом случае вынуждены использовать POST, если только вы не можете разделить фактический запрос на несколько более мелких запросов, которые действуют как мастер для сбора данных до окончательного запрос подтверждения запускает фактический окончательный HTTP-вызов.