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
. Это другое понятие по сравнению с другими понятиями, которые я описал ранее.