Каковы рекомендации здесь?
Как бы вы сделали это с веб-сайтом?
Это должно быть вашей первой эвристикой всякий раз, когда кто-то спрашивает вас о REST .REST - это
архитектурный стиль , разработанный для «долговечных сетевых приложений, охватывающих несколько организаций».Эталонным приложением для этого архитектурного стиля является World Wide Web.
Я занимаюсь разработкой калькулятора, который обеспечивает следующие функции: сложение, умножение, деление, вычитание двух операндов.Как мне предоставить эти методы клиентам, следуя принципам REST.
У клиента есть три элемента информации, которые необходимо передать на сервер, - операция и два операнда.В Интернете обычным способом сбора такого рода информации является предоставление формы.В этом случае это может быть выпадающий список операций и пара текстовых элементов управления для принятия чисел.Поскольку чистая функция является безопасной , мы, вероятно, использовали бы GET в качестве метода формы.Таким образом, правила обработки HTML будут принимать значения, описанные в форме, и транскрибировать их в виде пар ключ-значение в части запроса.
Таким образом, URL будет выглядеть примерно так:
/22520c7f-6207-490e-99c9-bd1bb37f4056?op=add&firstArg=6&secondArg=9
Ключевым обобщением является понимание того, что форма HTML играет роль шаблона URI - сервер передает шаблон клиенту, клиент заполняет детали и использует результат в качестве цели.запроса.
Это означает, что если вы хотите заменить HTML другим типом мультимедиа, вам потребуется указать описание для шаблонов URI, некоторый механизм для описания допустимых диапазонов и возможных значений.разумные значения по умолчанию.
Какой URI использовать для этих операций?
С REST?абсолютно не имеет значения.Это часть вопроса - клиент рассматривает URI как непрозрачные значения.
URI - это просто идентификаторы ;вы можете думать о них как об именах переменных в программе.Машины просто не заботятся о том, что такое написание (при условии, что это написание соответствует RFC 3986).
Поскольку написание не имеет значения, вы можете использовать любые местные соглашения об орфографии.Многие люди предпочитают «взломанный» URI - написание идентификатора передает полезную информацию читателю.
URI - это идентификаторы resources ;«любая информация, которая может быть названа, может быть ресурсом».Это мотивирует некоторые звуки «существительные, а не глаголы» - ресурсы - это веб-страницы, или документы, или изображения, или сценарии, или ... концепция «ресурса» намеренно расплывчата, поэтому ее можно использовать гибко.
Я не уверен, следует ли сопоставлять операцию добавления с GET, PUT или POST.
Ключом является рассмотрение семантики запроса клиента.В любое время вы выполняете запрос / поиск, то есть то, что машина делает автоматически для пользователя автоматически, затем вы смотрите на безопасную семантику, и этот метод, вероятно, будет GET или HEAD (особые обстоятельства).
Если мы просим сервер изменить представления своих собственных ресурсов, то в игру вступают PUT и POST.
В этом случае все эти операции просто выполняют поиск,поэтому GET подходит.
(Интересно отметить, что ни одна из этих операций не зависит от состояния сервера; они являются чистыми функциями. Поэтому может иметь смысл обслужить клиента с помощью code on demand -- javascript или некоторая разумная замена - и использовать процессор клиента для выполнения расчетов, а не совершать кучу обходов по сети).