JSON, REST, SOAP, WSDL и SOA: как они все связаны друг с другом

В настоящее время я сдаю некоторые экзамены, и я пытаюсь понять некоторые концепции. Они все были «упомянуты» в моих заметках, но я не совсем понял, как они все связаны друг с другом. Насколько я понимаю:

SOA - решение для общения потребителей / поставщиков услуг. (насколько я понимаю это общий термин для всего остального)

WSDL - язык, который описывает сервис провайдера.

SOAP - «оболочка» протокола XML, используемая сервисами для отправки сообщений. Работает совместно с WSDL как предоставить параметры?

ОТДЫХ - Шаблон проектирования, который похож на SOAP по функции, но избегает XML? (действительно не уверен насчет этого)

JSON - альтернатива XML, которая использует JavaScript? (не уверен насчет этого тоже)

Оглядываясь в Интернете, кажется, нет четкого определения того, что все это и как они взаимосвязаны.

Представьте, что вы разрабатываете веб-приложение и решили отделить функциональность от представления приложения, поскольку оно предоставляет большую свободу.

Вы создаете API и позволяете другим реализовывать свои собственные внешние интерфейсы. Здесь вы только что внедрили методологию SOA , то есть с помощью веб-сервисов.

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

Итак, вы разрабатываете механизм обмена между серверной частью (веб-сервисом), которая выполняет обработку и генерацию чего-то полезного, и интерфейсной частью (которая потребляет данные), которая может быть чем угодно. (Веб, мобильное или настольное приложение или другой веб-сервис). Единственным ограничением здесь является то, что внешний и внутренний интерфейсы должны «говорить» на одном и том же «языке».

Вот где вступают SOAP и REST. Это стандартные способы общения с веб-сервисом.

МЫЛО:

SOAP внутренне использует XML для отправки данных туда и обратно. Сообщения SOAP имеют жесткую структуру, и тогда необходимо проанализировать XML-ответ. WSDL - это спецификация того, какие запросы могут быть сделаны, с какими параметрами и что они будут возвращать. Это полная спецификация вашего API.

ОСТАЛЬНОЕ:

REST - это концепция дизайна.

Всемирная паутина представляет собой крупнейшую реализацию системы, соответствующей архитектурному стилю REST.

Это не так жестко, как SOAP. Веб-службы RESTful используют стандартные URI и методы для вызова веб-службы . Когда вы запрашиваете URI, он возвращает представление объекта, с которым вы затем можете выполнять операции (например, GET, PUT, POST, DELETE). Вы не ограничены выбором XML для представления данных, вы можете выбрать что-нибудь действительно (включая JSON)

REST API от Flickr идет дальше и позволяет вам возвращать изображения.

JSON и XML , функционально эквивалентны и распространены. Существуют также основанные на RPC фреймворки, такие как GRPC на основе Protobufs и Apache Thrift, которые можно использовать для связи между производителями и потребителями API. Наиболее распространенным форматом, используемым веб-API, является JSON, поскольку его легко использовать и анализировать на любом языке.

WSDL : обозначает язык описания веб-сервисов

В SOAP (простой протокол доступа к объектам), когда вы используете веб-службу и добавляете веб-службу в свой проект, ваши клиентские приложения не знают о функциях веб-службы. В настоящее время это как-то старомодно, и для каждого типа клиента вы должны реализовать разные WSDLфайлы. Например, вы не можете использовать один .Netи тот же файл для phpклиента. В WSDLфайле есть некоторые описания функций веб-сервиса. Тип этого файла XML. SOAPявляется альтернативой для REST.

ОТДЫХ : стенды для представительского государственного трансферта

Это еще один вид API-сервиса, он действительно прост в использовании для клиентов. Им не нужно иметь специальные расширения WSDLфайлов, такие как файлы. Операция CRUD может быть реализована различными HTTP Verbsспособами (GET для чтения, POST для создания, PUT или PATCH для обновления и DELETE для удаления требуемого документа). Они основаны на HTTPпротоколе и в большинстве случаев ответ находится в формате JSONили XMLформате. С другой стороны, клиентское приложение должно точно вызывать связанные HTTP Verbчерез точные имена и типы параметров. Из-за отсутствия специального файла для определения, например WSDL, это ручная работа с использованием конечной точки. Но это не имеет большого значения, потому что теперь у нас есть много плагинов для различных IDE для генерации реализации на стороне клиента.

SOA : стенды для сервис-ориентированной архитектуры

Включает в себя все программирование с концепциями и архитектурой веб-сервисов. Представьте, что вы хотите реализовать крупномасштабное приложение. Одной практикой может быть использование нескольких разных сервисов, называемых микросервисами, и весь механизм приложения будет вызывать необходимый веб-сервис в нужное время. Оба RESTи SOAPвеб-сервисы являются своего рода SOA.

JSON : стоит дляjavascript Object Notation

когда вы сериализуете объект для javascript, типом формата объекта является JSON. представьте, что у вас есть человеческий класс:

class Human{
 string Name;
 string Family;
 int Age;
}

и у вас есть несколько экземпляров из этого класса:

Human h1 = new Human(){
  Name='Saman',
  Family='Gholami',
  Age=26
}

когда вы сериализуете объект h1 в JSON, результат будет:

  [h1:{Name:'saman',Family:'Gholami',Age:'26'}, ...]

javascriptможет оценить этот формат по eval()функции и сделать ассоциативный массив из этой JSONстроки. Эта концепция отличается от других концепций, которые я описал ранее.