В последнем разделе мы узнали о протоколе SOAP на основе XML. В чем смысл МЫЛА? Это просто, но совсем не кажется легким.
Проблема транспортного протокола
Например, для SOAP, когда я создаю заказ, я использую POST, чтобы указать действие в XML как CreateOrder; когда я удаляю заказ, я использую POST, чтобы указать действие в XML как DeleteOrder. На самом деле, при создании заказа можно полностью использовать действие POST, а затем поместить информацию о заказе в XML. Удалите действие с помощью команды УДАЛИТЬ, а затем введите идентификатор заказа в XML.
Таким образом, мыло выше становится простым взглядом ниже.
POST /purchaseOrder HTTP/1.1 Host: www.cnblog.com Content-Type: application/xml; charset=utf-8 Content-Length: nnn2018-07-01 < className > Braised Chicken with Chestnut58
И формат XML также может быть изменен на другой формат представления простого текстового объекта JSON.
Следовало бы обнаружить, что часто написание веб-приложений-это то, как выглядят API в формате RESTful.
Вопрос о соглашении
RESTful, однако,-это не просто API, а архитектурный стиль, полное название Репрезентативной передачи состояний, выражающее переход состояний, от важных бумажных архитектурных стилей и Проектирования Сетевых программных архитектур.
Эта статья более глубоко и абстрактно демонстрирует основы дизайна интернет-приложения. Эти основы проектирования стали проблемами, которые необходимо учитывать при разработке всех приложений с высокой параллельностью, которые мы увидим позже. Кроме того, REST API является относительно простым и прямым, поэтому он практически стал стандартным интерфейсом интернет-приложения.
Поэтому, в отличие от МЫЛА, ОТДЫХ-это не строго предписанный стандарт, а стиль дизайна. Если дизайн выполнен в этом стиле, может быть достигнут как интерфейс RESTful, так и интерфейс SOAP, но последняя архитектура поддерживается REST, в то время как SOAP уделяет больше внимания первому интерфейсу.
Более того, из-за возможности генерировать ванну клиента через WSDL, SOAP часто используется способом, аналогичным традиционному RPC, то есть удаленный вызов совпадает с локальным вызовом.
Однако, в конце концов, локальные вызовы и удаленные межсетевые вызовы отличаются друг от друга. Разница здесь заключается не только в разделении клиента и сервера, вызванном сетью, но и в проблемах с производительностью сети. Что еще более важно, кто поддерживает состояние между клиентом и сервером? Так называемое состояние-это степень, в которой в настоящее время обрабатываются определенные данные.
Вот несколько примеров, например, какой каталог я просматривал, страницу, которую я видел, я хочу что-то купить, нужно вычесть инвентарь, это статус. Локальные вызовы на самом деле никого не беспокоят, потому что все данные являются локальными, и все обрабатывают их одинаково, и одна сторона обрабатывает их, а другая сторона видит их сразу.
Когда RPC доступен, мы ожидали бы, что он будет прозрачен для верхнего уровня, как говорилось в предыдущем разделе: “Далеко за горизонтом, далеко перед нами”. Поэтому, когда используется RPC, состояние не слишком учитывается.
Как и в NFS, клиент сообщит серверу, в какой каталог я хочу войти. Сервер должен поддерживать состояние для клиента, в какой каталог клиент просматривает в настоящее время. Например, когда клиент вводит CD hello, сервер где-то запоминает, что в последний раз, когда он просматривал/root/liuchao, на входе клиента должен отображаться список файлов в/root/Liuchao/hello. Если есть другой клиент, введите также CD hello, и сервер где-то запомнит, что при последнем просмотре/var/lib он покажет клиенту/var/lib/hello.
Не только NFS, если мы просматриваем страницы, мы часто реализуем функцию next (), чтобы перейти на следующую страницу в списке, но для этого сервер должен помнить, что клиент A в последний раз просматривал 20-30 страниц, затем он вызывает next (), он должен отображать 30-40 страниц, в то время как клиент B в последний раз просматривал 100-110 страниц, вызов next () должен отображать 110-120 страниц.
Все приведенные выше примеры относятся к сценариям RPC, в которых сервер поддерживает состояние, и многие интерфейсы SOAP разработаны в этом режиме. Эта модель не была проблемой, потому что не было никакого дисбаланса между клиентом и сервером. Поскольку обычно одновременно подключается не слишком много клиентов, NFS также может запоминать статус каждого клиента.
Если используемая в компании ERP – система реализована способом SOAP, и сервер поддерживает статус перехода на страницу отчета для каждого зарегистрированного пользователя, поскольку в компании не так много людей, ERP также можно запомнить, установив его на мощную физическую машину.
Но в интернет-сценарии клиент и сервер полностью выведены из равновесия. Вы можете себе представить, сколько людей совершают покупки одновременно, как сервер, может ли он запомнить? Конечно, это невозможно. Существует только множество серверов, предоставляющих услуги одновременно. Давайте поделимся ими. Но есть одна проблема. Как сервер может сообщить другому серверу состояние клиента, которое он помнит? Другими словами, если вы позволите мне поделиться с вами вашей работой, вы также должны четко объяснить мне причины и последствия вашей работы.
Затем нужно подумать о стороне обслуживания, поскольку клиентов так много, давайте разделим работу. Сервер записывает только состояние ресурсов, таких как файлы, отчеты и инвентаризация, в то время как клиент сохраняет свой собственный статус. Например, какой каталог вы посетили, какую страницу отчета и так далее.
Это также влияет на API, то есть, когда клиент поддерживает свое собственное состояние, он не может вызывать сервер таким образом. Например, клиент говорит, что я хочу получить доступ к пути приветствия в текущем каталоге. Сервер сказал: “Как я могу узнать ваш текущий путь?” Поэтому клиент сначала просматривает свой текущий путь,/root/liuchao, а затем сообщает серверу, что я хочу получить доступ к пути/root/Liu chao/Hello.
Например, клиент говорит, что я хочу перейти на следующую страницу, а сервер спрашивает, как мне узнать, какую страницу вы посещаете в данный момент? Поэтому клиент должен сначала просмотреть свой доступ к 100-110 страницам, а затем сообщить серверу, что я хочу получить доступ к 110-120 страницам.
Это и есть безгражданство сервера. Таким образом, сервер можно расширить горизонтально, чтобы 100 человек обслуживали его вместе, без передачи, каждый может справиться с этим.
Так называемое безгражданство-это фактически состояние ресурсов, поддерживаемых сервером, и состояние сеанса, поддерживаемого клиентом. Для сервера только при изменении состояния ресурса клиент вызывает методы POST, PUT и DELETE, чтобы найти меня; если состояние ресурса не меняется, но состояние клиента меняется, не говорите мне, для меня это единый GET.
Хотя это только улучшает GET, это принесло большой прогресс. Потому что для интернет-приложений большинство из них больше читают и меньше пишут. И пока состояние ресурсов сервера остается неизменным, это дает нам возможность кэширования. Например, состояние может быть кэшировано на уровне доступа или даже на пограничных узлах CDN, что является преимуществом инвариантного состояния ресурсов.
Таким образом, дизайн API постепенно стал ориентирован на ресурсы, а не на процессы. То есть клиент просто сообщает серверу, каким вы хотите видеть статус ресурса, вместо того, чтобы сообщать мне о процессе и действиях.
Или пример каталога файлов. К какому абсолютному пути должен обращаться клиент, а не к действию, я введу путь. Опять же, при вызове инвентаризации следует посмотреть текущее количество запасов, а затем вычесть количество покупок, чтобы получить результаты инвентаризации. На этом этапе следует установить целевой инвентарный номер (но текущий инвентарный номер должен совпадать), а не указывать, сколько запасов вычитается.
При проектировании этого API необходимо реализовать идемпотентность, потому что сеть нестабильна, будут частые ошибки, и поэтому нужно будет повторить попытку, но после повторной попытки возникнут идемпотентные проблемы, то есть один и тот же вызов, результат нескольких вызовов должен быть одинаковым, невозможно оплатить вызов, потому что три вызова в три платежа. Не можете ввести CD a, сделайте это три раза, станьте CD a/A/A. Мы также не можем вычесть акции. Если мы используем его три раза, мы можем вычесть его три раза.
Конечно, в соответствии с этим шаблоном проектирования как RESTful API, так и SOAP API могут реализовывать архитектуру как не имеющую состояния, ориентированную на ресурсы, идемпотентную, горизонтально масштабируемую и доступную.
Но в XML-тело SOAP вы можете поместить любое действие. Например, < ДОБАВИТЬ >, < МИНУС > и так далее могут быть записаны в XML. Это облегчает людям, которые используют SOAP, выполнение множества действий в API.
RESTful не так сложен и не предлагает клиентам так много возможностей. JSON в тексте в основном описывает состояние ресурсов и не может описывать действия. Более того, только CRUD, то есть POST, GET, PUT, DELETE, является изменением состояния.
Итак, с точки зрения интерфейса, это позволяет вам умереть. Конечно, существует много хитрых способов предоставления запросов с отслеживанием состояния на основе действий в случае RESTful API, который является анти-шаблоном.
Проблемы с обнаружением служб
Для RESTful API мы решили проблему транспортного протокола на основе HTTP, соглашения о протоколе на основе JSON и, наконец, проблему обнаружения служб.
Существует известная платформа межсистемных вызовов RESTful на основе API, называемая Spring Cloud. В Весеннем Облаке есть компонент под названием Эврика. Легенда гласит, что Архимед открыл принцип плавучести в своей ванне. Он был слишком счастлив, чтобы надеть брюки, и выбежал на улицу с криком: “Эврика (я нашел это)!” Таким образом, Эврика используется для реализации реестра, отвечающего за ведение зарегистрированного списка услуг.
Поставщик вспомогательных услуг, который регистрирует, обновляет и отключает услуги Eureka, регистрирует основные данные, включая имя службы, IP-адрес компьютера, номер порта, доменное имя и так далее.
С другой стороны, потребитель услуг получает регистрационную информацию поставщика услуг от Eureka. Для достижения балансировки нагрузки и отказоустойчивости поставщики услуг могут зарегистрировать несколько.
Когда потребители захотят вызвать службы, они будут считывать несколько служб из реестра. Как их вызвать? Спокойный подход, конечно.
Spring Cloud предоставляет инструмент RestTemplate для преобразования объектов запроса в JSON и запуска вызовов Rest. Вызовы RestTemplate также делятся на POST, PUT, GET и DELETE. Когда результаты возвращаются, объект анализируется в соответствии с возвращенным JSON.
Благодаря такой инкапсуляции вызов также очень удобен.
Резюме
- SOAP слишком сложен, а дизайн ориентирован на действия, поэтому параллелизм часто невелик из-за проблем с архитектурой.
- RESTful-это не только API, но и архитектурный шаблон. Он в основном ориентирован на ресурсы и предоставляет услуги без сохранения состояния, что способствует горизонтальному масштабированию для работы с высоким уровнем параллелизма.