REST на самом деле является архитектурным стилем, и, по словам Роберта С. "Дядя Боб" Мартин , архитектура имеет намерение . Цель REST состоит в том, чтобы отделить клиентов от серверов, чтобы последние могли свободно развиваться в будущем, не опасаясь взлома клиентов. Чтобы добиться разъединения, клиенты и серверы должны придерживаться определенного набора ограничений.
Поэтому REST нельзя сократить только на стороне сервера. Это общая характеристика взаимодействия или поведение между клиентом и сервером, которые определяют, следует ли распределенная система архитектуре REST или нет. Если хотите, вы можете заняться этим с точки зрения SOA и сказать, что сервер предлагает услуги клиентам. Даже если у вас реализована служба, которая придерживается всех ограничений, наложенных Fielding, взаимодействие между сервером и клиентами может быть не «RESTful», если клиенты полагаются на определение семантики из URI или ожидают, что определенные конечные точки будут возвращать определенные типы вместо того, чтобы полагаться насогласование типа содержимого или реализация других видов соединений с соответствующим сервером.
Джим Уэббер указал , что в архитектуре REST вы в первую очередь реализуете протокол приложения домена, который клиент будет выполнять, пока ониполучить всю информацию, обслуживаемую сервером, либо через ссылки, либо в виде формы, похожей на HTML-формы. Эта концепция обобщена как HATEOAS. HTTP, кроме того, является транспортным протоколом, доменом которого является передача документов через Интернет. Вы не вызываете сервисы, вы просто копаете документы. Любые бизнес-правила, которые вы выводите из файловых передач, являются лишь побочным эффектом фактического управления документами. Таким образом, вызов службы REST, вероятно, также не является правильным термином.
API REST сам по себе вводит в заблуждение в экосистеме REST, поскольку REST определяется для повторного использования общего интерфейса, предоставляемого его транспортным уровнем, в большинстве случаев HTTP. , но это не ограничивается этим на самом деле. Здесь HTTP ie является общим интерфейсом, который используют как клиенты, так и серверы, и ни сервер, ни клиенты не должны применять к нему настройку, которая может вызвать проблемы взаимодействия. Конечная цель в среде REST состоит в том, чтобы один клиент мог взаимодействовать с множеством служб из коробки, в то время как сервер может обслуживать множество различных клиентов, особенно тех, которые не находятся под собственным контролем разработчиков, без необходимости внешней документации и накладных расходов на настройку. , за исключением интеграции стандартных форматов документов, таких как HTML или другие форматы мультимедийных типов, управляемых гипертекстом, и связей ссылокСвязь должна быть не между клиентом и серверами, а между одноранговым узлом (сервером или клиентом) и согласованным форматом представления, определенным стандартизированным медиа-типом, хотя посредством надлежащего согласования типа контента и сервер, и клиент согласовали формат представления и поддержки, ипонимать.
К сожалению, существует широко распространенное заблуждение о том, что такое REST. Если вы посмотрите здесь на SO или в Интернете в целом, у вас может сложиться впечатление, что REST означает выставление произвольных полезных нагрузок JSON через чрезмерно спроектированные URL-адреса на некоторых конечных точках HTTP. Такие системы ведут себя как настоящие API-интерфейсы RPC, аналогично SOAP или CORBA. Они поставляются со своей собственной документацией или определениями типов, которые допускают де-сериализацию сообщений, клиенты обычно ломаются, если что-то изменяется в структуре и подобных вещах, и клиенты, ориентированные на один из этих API, обычно не могут повторно использоваться для других API изкоробка. Это сильные советы для связывания и RPC-подобного поведения. Такие «сервисы» должны документировать «API», чтобы другие разработчики могли реализовывать клиентов, способных взаимодействовать с этими системами. Поскольку клиенты требуют такой документации, документация становится фактической истиной, которой должна следовать реализация сервера, иначе клиенты могут перестать работать. Такая связь также означает, что сервис не может развиваться свободно в будущем, поскольку он может нарушить работу клиентов из-за тесной связи между документацией API и реализацией.
Как вы, наверное, можете видеть, термин API - этоВ общем, немного рискованно, если вы говорите об истинной модели архитектуры REST, предложенной Филдингом. Если вы хотите рассказать о том, что большинство разработчиков считают REST, но на самом деле это RPC, термин API может быть более подходящим. В ИМО термин «сервис» более точно охватывает предмет, предоставляемый сервером, так как он точно охватывает оба определения.