RPC против спокойных конечных точек

Я потратил больше времени, чем хотел бы признать, пытаясь понять различия между RPC и конечными точками покоя. На самом деле, спустившись в эту кроличью нору, я даже не уверен, что полностью понимаю, что такое RPC. И я не одинок. Я вижу бесчисленное количество сообщений, которые постоянно просят разъяснений.

Вот мое понимание до сих пор:

RPC и конечные точки отдыха в основном носят концептуальный характер. Стандартов нет.

Оба являются способами вызова функции на удаленном сервере.

В случае неактивных конечных точек мы сопоставляем методы HTTP с операциями CRUD над ресурсом.

В случае RPC нас интересуют действия над объектом.

Однако в обоих случаях речь идет об удаленном вызове метода.

Я читал, что некоторые люди говорят, что restful не должен быть с состоянием, и если это так, то это не restful. Но разве самые спокойные конечные точки не используют состояние через сеансы? Я имею в виду, что я не позволю никому удалять данные без входа в систему.

И я также читал, что такие функции, как domain(.)com/login, не успокаивают, потому что это действие. Кажется, это имеет смысл, но поскольку я пишу свои функции на своем сервере не иначе, чем простые функции отдыха, действительно ли имеет значение, как мы их называем — отдых или RPC.

Я действительно просто не понимаю, чего мне не хватает, и до сих пор в StackOverflow не было сообщений, посвященных этой путанице.

Надеясь, что кто-то может дать некоторое представление, используя вышеизложенное в качестве руководства для понимания. Заранее спасибо.

Стоит ли изучать PHP в 2023-2024 годах?
Стоит ли изучать PHP в 2023-2024 годах?
Привет всем, сегодня я хочу высказать свои соображения по поводу вопроса, который я уже много раз получал в своем сообществе: "Стоит ли изучать PHP в...
Поведение ключевого слова "this" в стрелочной функции в сравнении с нормальной функцией
Поведение ключевого слова "this" в стрелочной функции в сравнении с нормальной функцией
В JavaScript одним из самых запутанных понятий является поведение ключевого слова "this" в стрелочной и обычной функциях.
Приемы CSS-макетирования - floats и Flexbox
Приемы CSS-макетирования - floats и Flexbox
Здравствуйте, друзья-студенты! Готовы совершенствовать свои навыки веб-дизайна? Сегодня в нашем путешествии мы рассмотрим приемы CSS-верстки - в...
Тестирование функциональных ngrx-эффектов в Angular 16 с помощью Jest
В системе управления состояниями ngrx, совместимой с Angular 16, появились функциональные эффекты. Это здорово и делает код определенно легче для...
Концепция локализации и ее применение в приложениях React ⚡️
Концепция локализации и ее применение в приложениях React ⚡️
Локализация - это процесс адаптации приложения к различным языкам и культурным требованиям. Это позволяет пользователям получить опыт, соответствующий...
Пользовательский скаляр GraphQL
Пользовательский скаляр GraphQL
Листовые узлы системы типов GraphQL называются скалярами. Достигнув скалярного типа, невозможно спуститься дальше по иерархии типов. Скалярный тип...
3
0
54
2
Перейти к ответу Данный вопрос помечен как решенный

Ответы 2

Я действительно просто не понимаю, чего мне не хватает

Не твоя вина, литература отстой.


Я думаю, вы можете найти руководство Джима Уэббера 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, вы просто определяете, как назвать эту операцию задания и какие входы и выходы она будет иметь.

Шаг 1. Просто RPC

Например, у вас может быть такая операция 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?

Проблемы следующие:

  1. Когда вы смотрите на определение метода foo, вы не имеете ни малейшего представления, что он делает.
  2. При разработке API-интерфейсов RPC у вас есть абсолютная свобода, но свобода часто может быть плохой вещью. Потому что люди мыслят по-разному. Вы можете подумать, что ваш API простой и элегантный, но другие люди так не подумают.

Шаг 2. Стандартизированный RPC

Если вы опытный разработчик 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...

Почему не так просто разобраться в этой связке методов? Потому что так работает наш мозг. Наш мозг всегда группирует действия по объектам. Вы, естественно, думаете о сущности, а затем о действиях, которые вы можете с ней делать. напр. что можно сделать с чашкой? Взять, спрятать, сломать, помыть, перевернуть. А мозг редко думает сначала о действиях, а потом о сущностях. Что я могу взять? Чашка, мяч, мороженое, билет, жена. Не очень естественно.

Итак, что такое ОТДЫХ?

Шаг 3. ОТДЫХ

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

Другие вопросы по теме