Я потратил больше времени, чем хотел бы признать, пытаясь понять различия между RPC и конечными точками покоя. На самом деле, спустившись в эту кроличью нору, я даже не уверен, что полностью понимаю, что такое RPC. И я не одинок. Я вижу бесчисленное количество сообщений, которые постоянно просят разъяснений.
Вот мое понимание до сих пор:
RPC и конечные точки отдыха в основном носят концептуальный характер. Стандартов нет.
Оба являются способами вызова функции на удаленном сервере.
В случае неактивных конечных точек мы сопоставляем методы HTTP с операциями CRUD над ресурсом.
В случае RPC нас интересуют действия над объектом.
Однако в обоих случаях речь идет об удаленном вызове метода.
Я читал, что некоторые люди говорят, что restful не должен быть с состоянием, и если это так, то это не restful. Но разве самые спокойные конечные точки не используют состояние через сеансы? Я имею в виду, что я не позволю никому удалять данные без входа в систему.
И я также читал, что такие функции, как domain(.)com/login, не успокаивают, потому что это действие. Кажется, это имеет смысл, но поскольку я пишу свои функции на своем сервере не иначе, чем простые функции отдыха, действительно ли имеет значение, как мы их называем — отдых или RPC.
Я действительно просто не понимаю, чего мне не хватает, и до сих пор в StackOverflow не было сообщений, посвященных этой путанице.
Надеясь, что кто-то может дать некоторое представление, используя вышеизложенное в качестве руководства для понимания. Заранее спасибо.
Я действительно просто не понимаю, чего мне не хватает
Не твоя вина, литература отстой.
Я думаю, вы можете найти руководство Джима Уэббера 2011 года поучительным.
Используйте HTTP как прикладной протокол. HTTP — это не транспортный протокол, который удобно использовать через порт 80. HTTP — это прикладной протокол, областью применения которого является передача документов по сети.
HTTP, как и удаленные вызовы процедур, является протоколом типа запрос/ответ. Клиент отправляет сообщение серверу, сервер отправляет сообщение обратно. Большое дело.
Но в архитектурном стиле REST мы также следуем универсальному интерфейсному ограничению. Это означает (среди прочего), что все одинаково понимают запросы и одинаково интерпретируют ответы.
А это, в свою очередь, означает, что компоненты общего назначения (браузеры, поисковые роботы, прокси-серверы) могут понимать сообщения запроса и ответа и разумно реагировать на эти сообщения, не имея при этом никакой необходимости знать что-либо о специализации конкретного ресурса.
В случае HTTP мы передаем сообщения о домене документов; если мне нужна информация от вас, я прошу последнюю копию вашего документа. Если я хочу отправить вам информацию, я посылаю вам предлагаемую модификацию вашего документа. Может быть, вы отреагируете на мою модификацию, создав новый документ, и предложите мне взглянуть на него. И так далее.
Таким образом, полезная деловая активность становится побочным эффектом манипулирования этими документами. Или, выражаясь иначе, метафора документа — это фасад, который мы представляем миру.
И я также читал, что такие функции, как domain(.)com/login, не успокаивают, потому что это действие.
См. выше: литература отстой.
Рассмотрим этот идентификатор ресурса: https://www.merriam-webster.com/dictionary/login
Работает ли он как любой другой идентификатор ресурса в Интернете? Да. Браузер знает, как сделать запрос к GET
этому ресурсу, и когда Merriam-Webster отвечает, что вместо этого браузер должен смотреть на https://www.merriam-webster.com/dictionary/log%20on, он получает это ресурс тоже.
Тот факт, что «login»/«log on» являются непереходными английскими глаголами, не имеет значения; это идентификатор, и это все, что нужно знать браузеру.
В качестве альтернативы рассмотрите следующее: сокращатели URL работают.
Идентификаторы ресурсов очень похожи на имена переменных в компьютерной программе; пока идентификатор удовлетворяет производственным правилам вашего языка, вы можете использовать все, что захотите. Машины не волнуют.
Ключевая идея заключается в том, что ресурсы — это не действия, а «информация, которую можно назвать». https://www.merriam-webster.com/dictionary/log%20on — это название документа, который описывает определение Merriam-Webster глагола «войти в систему».
Поскольку машинам все равно, какие имена мы используем, мы можем воспользоваться дополнительной свободой, которая дает нам возможность выбирать имена, облегчающие жизнь людям, которые нам небезразличны.
Я читал, что некоторые люди говорят, что restful не должен быть с состоянием, и если это так, то это не restful. Но разве самые спокойные конечные точки не используют состояние через сеансы?
Связь без сохранения состояния является архитектурным ограничением REST.
каждый запрос от клиента к серверу должен содержать всю информацию, необходимую для понимания запроса, и не может использовать какой-либо сохраненный контекст на сервере.
Файлы cookie — это одна из областей, где HTTP не смог удовлетворить ограничения связи без сохранения состояния.
Я не позволю никому удалять данные без входа в систему.
Не проблема: каждый HTTP-запрос содержит собственные метаданные авторизации; вы не должны «запоминать» предыдущие сообщения в беседе. Вместо этого вы каждый раз проверяете предоставленные учетные данные.
Это удивительный вопрос. Между подходами REST и RPC есть огромная разница, я попытаюсь ее объяснить.
RPC просто позволяет вам вызвать какой-нибудь удаленный компьютер, чтобы выполнить какую-то работу. Это может быть любая работа, и она может иметь любые входы и выходы. Когда вы разрабатываете API, вы просто определяете, как назвать эту операцию задания и какие входы и выходы она будет иметь.
Например, у вас может быть такая операция foo
с одним входом и двумя выходами (я буду использовать нотацию JSight API, потому что она поддерживает как RPC, так и REST API):
JSIGHT 0.3
URL /rpc-api
Protocol json-rpc-2.0
Method foo
Params
{
"input-1": 123 // some integer
}
Result
{
"output-1": 123, // some other integer
"output-2": "some string"
}
При разработке RPC API вы можете использовать столько операций, сколько захотите.
Итак, в чем проблема с этим? Зачем нам REST, если у нас уже есть RPC?
Проблемы следующие:
foo
, вы не имеете ни малейшего представления, что он делает.Если вы опытный разработчик API и используете стиль RPC, вы попытаетесь следовать некоторому шаблону, чтобы избежать двух ошибок, упомянутых выше. Например, давайте представим, что ваш метод foo
возвращает объект клиента. Тогда вы никогда не будете называть это как foo
, вы будете называть это getCustomer
, вот так:
JSIGHT 0.3
URL /rpc-api
Protocol json-rpc-2.0
Method getCustomer
Params
{
"input-1": 123 // some integer
}
Result
{
"output-1": 123, // some other integer
"output-2": "some string"
}
Хорошо! Теперь, когда вы просто посмотрите на это описание, вы можете сказать, что этот метод возвращает клиента; этот параметр input-1
— это какой-то фильтр, скорее всего, ID; а output-1
и output-2
— некоторые свойства клиента.
Смотрите, просто используя стандартный способ именования метода, мы сделали наш API намного более простым для понимания.
И все же, зачем нам нужен ОТДЫХ? В чем проблема?
Проблема в том, что когда у вас есть десятки таких RPC-методов, ваш API выглядит беспорядочно. Например:
JSIGHT 0.3
URL /rpc-api
Protocol json-rpc-2.0
Method getCustomer
Method updateCustomer
Method getCustomerFriends
Method getCustomerFather
Method askCustomerConfirmation
# etc...
Почему не так просто разобраться в этой связке методов? Потому что так работает наш мозг. Наш мозг всегда группирует действия по объектам. Вы, естественно, думаете о сущности, а затем о действиях, которые вы можете с ней делать. напр. что можно сделать с чашкой? Взять, спрятать, сломать, помыть, перевернуть. А мозг редко думает сначала о действиях, а потом о сущностях. Что я могу взять? Чашка, мяч, мороженое, билет, жена. Не очень естественно.
Итак, что такое ОТДЫХ?
REST предназначен для группировки сущностей и определения наиболее стандартных действий с этими сущностями.
В ИТ мы обычно создаем, читаем, записываем или удаляем объекты. Вот почему у нас есть методы POST
, GET
, PUT
и DELETE
в HTTP, который де-факто является единственной реализацией стиля REST.
Когда мы группируем наши методы по сущностям, наш API становится намного понятнее. Смотреть:
JSIGHT 0.3
GET /customer/{id}
PUT /customer/{id}
GET /customer/{id}/friends
GET /customer/{id}/father
POST /customer/{id}/ask-confirmation
Теперь его гораздо легче воспринимать, чем в приведенном выше примере в стиле RPC.
Есть много других вопросов, касающихся различий между RPC и REST. У REST есть свои недостатки, как и у RPC. Но я хотел объяснить вам основную мысль:
REST — это стандарт, который помогает организовать API в удобной для пользователя форме, удобной для человеческого мозга, чтобы любой разработчик мог быстро понять структуру вашего API.
RPC — это просто способ вызова удаленных операций.
Все приведенные выше примеры собраны здесь: https://editor.jsight.io/r/g6XJwjV/1