JSON, REST, SOAP, WSDL и SOA: как все они соединяются вместе

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

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

WSDL - язык, описывающий службу поставщика.

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

REST - шаблон проектирования, аналогичный SOAP в функции, но избегающий XML? (действительно не уверен в этом)

JSON - альтернатива XML, которая использует javascript? (не уверен в этом).

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

ОТВЕТЫ

Ответ 1

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

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

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

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

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

МЫЛО:

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

ОСТАЛЬНОЕ:

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

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

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

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

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

Ответ 2

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

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

REST: Стенды для передачи репрезентативного состояния

Это еще один вид службы API, он очень прост в использовании для клиентов. Им не нужно иметь специальное расширение файла, например WSDL. Операция CRUD может быть реализована различными HTTP Verbs (GET для чтения, POST для создания, PUT или PATCH для обновления и DELETE для удаления желаемого документа). Они основаны на протоколе HTML, и в большинстве случаев ответ находится в 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. Это другое понятие по сравнению с другими понятиями, которые я описал ранее.