Если вы посмотрите на все эти так называемые REST-API, ваше наблюдение может показаться верным, хотя на самом деле REST — это нечто совершенно другое. В нем описывается архитектура или философия, целью которой является разделение клиентов. с серверов, что позволит последнему развиваться в будущем, не нарушая работу клиентов. Это очень похоже на типичное взаимодействие с веб-страницей в том смысле, что сервер обучает клиента тому, что ему нужно, и реагирует только на запросы, инициированные клиентом. При проектировании REST-сервисов нужно быть очень осторожным и осторожным, так как слишком легко включить связь, которая может повлиять на клиентов при введении изменения, особенно со всем прагматизмом в (коммерческой) разработке программного обеспечения. Стефан Тилков выступил с отличным докладом о REST еще в 2014, который вместе с Джим Уэббер или Asbjørn Ulsberg, можно использовать в качестве вводных лекций о том, что такое REST по своей сути.
Общая предпосылка REST всегда должна заключаться в том, что сервер обучает клиентов тому, что им нужно и чего ожидает сервер, и предлагает выбор клиенту через ссылки. Если сервер ожидает получить данные от клиента, он отправит представление формы, чтобы проинформировать клиента о соответствующих полях, которые он поддерживает, и на основе доступность соответствующих элементов, содержащихся в форме, клиент знает, следует ли выбрать один или несколько вариантов, ввести произвольный текст или ввести значение даты и т.д. К сожалению, большинство мультимедийных форматов, пытающихся имитировать формы HTML, все еще находятся в черновых версиях.
Если вы посмотрите, в частности, на HTML-формы, вы, возможно, почувствуете, что Я имею в виду. Каждый из элементов, которые могут встречаться внутри формы, четко определен, чтобы избежать двусмысленности и улучшить взаимодействие. Это де-факто конечная цель REST, иметь один клиент, который может взаимодействовать с огромным количеством других сервисов без необходимости явно адаптироваться к каждому отдельному API.
Прелесть REST в том, что он не ограничен одной формой представления, то есть JSON, фактически существует почти бесконечное количество возможных форматов представления, которыми можно обмениваться в среде REST. Обычный application/json — это ужасный медиа-тип для приложений REST IMO, поскольку он не включает никаких определений в отношении ссылок и форм и не описывает семантику определенных полей, которые могут быть отправлены в запросах и ответах. Отсутствие семантического описания обычно приводит к типизированным ресурсам где получатель ожидает, что получение данных, т.е. /api/users, вернет некоторые определенные пользовательские данные, которые могут отличаться от хоста к хосту. Если вы просмотрите реестр типов носителей IANA, вы найдете несколько форматов медиа-типа, которые вы могли бы использовать для передачи данных, связанных с пользователем, и любой клиент, поддерживающий эти форматы представления, сможет взаимодействовать с этой точкой без каких-либо проблем. Сам Филдинг утверждал, что
API REST должен тратить почти все свои описательные усилия на определение типа (типов) мультимедиа, используемых для представления ресурсов и управления состоянием приложения, или на определение расширенных имен отношений и/или разметки с поддержкой гипертекста для существующих стандартных типов мультимедиа. Любые усилия, затрачиваемые на описание того, какие методы использовать для интересующих URI, должны быть полностью определены в рамках правил обработки для типа носителя (и, в большинстве случаев, уже определены существующими типами носителя). (Источник)
Через согласование типа контента клиент и сервер будут договариваться о формате представления, который поддерживает и понимает. Поэтому вопрос должен заключаться не в том, кого поддерживать, а в том, сколько вы хотите поддержать. Чем больше типов мультимедиа ваш API или клиент может обменивать полезными нагрузками, тем выше вероятность взаимодействия с другими участниками.
Большинство из этих так называемых REST API на самом деле представляют собой просто службы RPC, предоставляемые через HTTP, которые могут учитывать или не поддерживать определенные операции HTTP. Таким образом, HTTP является просто транспортным уровнем, чьей областью является передача файлов или данных через Интернет< /а>. Многие люди по-прежнему считают, что вы не должны помещать глаголы в URI, когда на самом деле сценарий или процесс обычно этого не делают ( и не должны) заботиться о том, содержит ли URI глагол или нет. Сам URI — это всего лишь указатель, которому клиент будет следовать и вызывать, когда он заинтересован в получении полезной нагрузки. Мы, люди, также не очень заинтересованы в самом URI в отношении контента, который он может вернуть после вызова этого URI. То же самое справедливо и для произвольных клиентов. Более важно, что вы отправляете вместе с этим URI. В Интернете ссылка может быть аннотирована определенным текстом и/или именами отношений ссылок, которые устанавливают содержание ссылок по отношению к текущей странице. Это может намекнуть клиенту, что определенный контент может быть вызван до того, как весь ответ будет проанализирован, поскольку вполне вероятно, что клиент также захочет узнать об этом. preload т. е. такое имя отношения ссылки, которое намекает на клиент об этом. Если существуют определенные доменные термины, можно использовать схему расширения, определенную веб-ссылками или повторно использовать общеизвестные сведения или специальные микроформаты.
Все взаимодействие в среде REST похоже на игру в текстовую компьютерную игру или следуя определенному потоку процессов (например, заказ и оплата продуктов), определенному протоколом домена приложения, который может быть спроектирован как конечный автомат. Таким образом, клиент проходит через весь процесс. По сути, он просто следует приказам, которые ему дал сервер, с некоторыми вариантами выхода из процесса (например, отменить заказ перед оплатой).
С другой стороны, SOAP, как вы сказали, основанный на XML протокол RPC, повторно использующий подмножество HTTP для обмена запросами и ответами. Вероятность того, что когда вы что-то измените в своем WSDL, множество клиентов придется адаптировать и перекомпилировать, довольно высока. SOAP даже определяет свой собственный механизм безопасности вместо повторного использования TLS, который поэтому требует явной поддержки со стороны клиентов. Поскольку у вас есть модель связи один-к-одному из-за состояния, которое может поддерживаться в процессе, масштабирование служб SOAP не так просто. В среде REST это просто вопрос добавления балансировщика нагрузки перед сервером, а затем зеркалирования сервера n раз. Балансировщик нагрузки может отправить запрос на любой из серверов благодаря ограничение без сохранения состояния
Как обычно называют «смесь» (кроме, может быть, плохого API). Есть ли для этого слово? или концепция, на которую я могу сослаться, чтобы большинство разработчиков поняли, о чем я говорю, без необходимости произносить весь абзац, который я сделал выше?
Это просто «JSON SOAP API?», «Сервисный REST API?» - как бы вы это назвали?
Общий термин для API, который взаимодействует поверх HTTP, будет Web API или HTTP API IMO. В этой статье также используется этот срок. Кроме SOAP, в нем также перечислены XML-RPC и JSON-RPC. Однако я согласен с Voice в том, что вы получите 5 ответов, если спросите 4 человек о правильном термине. Хотя было бы удобно иметь соответствующий термин, с которым все согласны, реальность показывает, что люди не заинтересованы в четком разделении. Просто посмотрите здесь, в SO вопросы, помеченные тегом остальное . Нет ничего плохого в том, чтобы не быть «RESTful», хотя следует избегать термина REST для настоящих служб RPC. Хотя я думаю, что мы уже находимся в ситуации, когда термин REST нельзя спасти от неправильного использования и в маркетинговых целях.
Для чего-то, что требует использования внешней документации и поставляется с собственным нестандартным форматом представления или просто предоставляет CRUD для объектов предметной области, я бы добавил к нему -RPC, так как это более или менее то, что в его основе. Поэтому, если API отправляет JSON, а ожидаемое представление задокументировано через Swagger или какую-либо другую внешнюю документацию,JSON-RPC вероятно, будет наиболее подходящим именем IMO.
Подводя итог этому посту, я надеюсь, что смог пролить некоторый свет на то, что такое REST на самом деле, и как ваше наблюдение испорчено всеми этими прагматичными попытками, которые, к сожалению, являются RPC насквозь. Если что-то изменить в их реализации, сколько клиентов сломается? В дополнение к этому вы не можете повторно использовать клиент, который вы реализовали для API A, для взаимодействия с API B (другой компании или поставщика) из коробки, и поэтому вам придется либо адаптировать свой клиент, либо создать новый исключительно для этого API. Это настоящий RPC, и поэтому его название должно как-то отражаться, чтобы намекнуть разработчикам на будущие ожидания. К сожалению, процесс правильного именования вещей, особенно в отношении REST, кажется, уже потерян. Есть прекрасная, но крошечная группа, которая пытается распространять истинный смысл, например Голос, Кассио и некоторые другие, хотя это похоже на борьбу с ветряными мельницами. Лучшим советом здесь было бы сначала обсудить соглашения об именах и то, что каждый участник понимает, какой термин, а затем согласовать схему именования, с которой все согласны, чтобы избежать путаницы в будущем.
person
Roman Vottner
schedule
30.08.2019
