JSON, REST, SOAP, WSDL i SOA: jak one wszystkie się łączą

Obecnie robię egzaminy i zmagam się z kilkoma koncepcjami. O nich tak naprawdę „wspomniałem” w moich notatkach, ale tak naprawdę nie rozumiałem, jak się one łączyły. O ile rozumiem:

SOA - rozwiązanie umożliwiające komunikację konsumentów / dostawców usług. (o ile rozumiem, jest to ogólny termin obejmujący wszystko inne)

WSDL - język opisujący usługę dostawcy.

SOAP - „opakowanie” protokołu XML używane przez usługi do wysyłania wiadomości. Działa w połączeniu z WSDL, aby zapewnić parametry?

REST - wzorzec projektowy, który jest podobny do SOAP w funkcji, ale unika XML? (naprawdę nie jestem pewien co do tego)

JSON - alternatywa dla XML, która używa javascript? (nie jestem pewien co do tego)

Rozglądając się po Internecie, nie wydaje się, aby istniała jasna definicja tego, czym one są i jak się łączą.

Wyobraź sobie, że tworzysz aplikację internetową i decydujesz się oddzielić funkcjonalność od prezentacji aplikacji, ponieważ zapewnia ona większą swobodę.

Tworzysz interfejs API i pozwalasz innym implementować w nim również własne interfejsy. To, co właśnie zrobiłeś, to zaimplementowanie metodologii SOA , tj. Wykorzystanie usług internetowych.

Usługi sieciowe udostępniają funkcjonalne bloki konstrukcyjne za pośrednictwem standardowych protokołów internetowych niezależnych od platform i języków programowania.

Zatem projektujesz mechanizm wymiany między zapleczem (usługą internetową), który przetwarza i generuje coś użytecznego, a front-endem (który zużywa dane), którym może być wszystko. (Aplikacja internetowa, mobilna lub komputerowa albo inna usługa internetowa). Jedynym ograniczeniem jest tutaj to, że front-end i back-end muszą „mówić” tym samym „językiem”.

Tutaj wkraczają SOAP i REST. Są to standardowe sposoby komunikacji z usługą internetową.

MYDŁO:

SOAP wewnętrznie używa XML do przesyłania danych tam iz powrotem. Komunikaty SOAP mają sztywną strukturę, a następnie XML odpowiedzi musi zostać przeanalizowany. WSDL to specyfikacja tego, jakie żądania można składać, z jakimi parametrami i co zwrócą. Jest to pełna specyfikacja Twojego API.

ODPOCZYNEK:

REST to koncepcja projektowa.

Sieć WWW stanowi największą implementację systemu zgodnego ze stylem architektonicznym REST.

Nie jest tak sztywny jak SOAP. Usługi sieciowe RESTful używają standardowych identyfikatorów URI i metod do wykonywania wywołań usługi sieciowej. Kiedy żądasz URI, zwraca reprezentację obiektu, na którym możesz następnie wykonać operacje (np. GET, PUT, POST, DELETE). Nie jesteś ograniczony do wybierania XML do reprezentowania danych, możesz wybrać naprawdę wszystko (w tym JSON)

Interfejs API REST Flickr idzie dalej i umożliwia również zwracanie obrazów.

JSON i XML są funkcjonalnie równoważne i są typowymi wyborami. Istnieją również struktury oparte na RPC, takie jak GRPC oparte na Protobufs i Apache Thrift, które mogą być używane do komunikacji między producentami API a konsumentami. Najpopularniejszym formatem używanym przez internetowe interfejsy API jest JSON, ponieważ jest łatwy w użyciu i analizowany w każdym języku.

WSDL : oznacza język opisu usługi sieci Web

W przypadku protokołu SOAP (prosty protokół dostępu do obiektu), gdy używasz usługi sieci Web i dodajesz ją do projektu, aplikacje klienckie nie wiedzą o funkcjach usługi sieci Web. W dzisiejszych czasach jest to trochę staromodne i dla każdego rodzaju innego klienta trzeba zaimplementować inne WSDLpliki. Na przykład nie można użyć tego samego pliku dla .Neti phpklienta. WSDLPlik ma jakieś opisy o funkcjach usług internetowych. Typ tego pliku to XML. SOAPjest alternatywą dla REST.

REST : oznacza reprezentacyjny transfer stanu

Jest to inny rodzaj usługi API, jest naprawdę łatwy w użyciu dla klientów. Nie muszą mieć specjalnego rozszerzenia pliku, takiego jak WSDLpliki. Operację CRUD można zaimplementować w inny sposób HTTP Verbs(GET do czytania, POST do tworzenia, PUT lub PATCH do aktualizacji i DELETE do usuwania żądanego dokumentu), są one oparte na HTTPprotokole i w większości przypadków odpowiedź jest w formacie JSONlub XML. Z drugiej strony aplikacja kliencka musi dokładnie wywoływać powiązane HTTP Verbpoprzez dokładne nazwy i typy parametrów. Ponieważ nie ma specjalnego pliku do definicji, WSDLjest to zadanie ręczne z wykorzystaniem punktu końcowego. Ale to nic wielkiego, ponieważ teraz mamy wiele wtyczek dla różnych IDE do generowania implementacji po stronie klienta.

SOA : oznacza architekturę zorientowaną na usługi

Obejmuje całe programowanie z koncepcjami i architekturą usług internetowych. Wyobraź sobie, że chcesz wdrożyć aplikację na dużą skalę. Jedną z praktyk może być posiadanie różnych usług zwanych mikrousługami, a cały mechanizm aplikacji będzie wywoływał potrzebną usługę sieciową we właściwym czasie. Obie usługi RESTi SOAPusługi internetowe są swego rodzaju SOA.

JSON : oznaczajavascript Object Notation

podczas serializacji obiektu dla javascript typem formatu obiektu jest JSON. wyobraź sobie, że masz klasę ludzką:

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

i masz kilka instancji z tej klasy:

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

kiedy serializujesz obiekt h1 do formatu JSON, wynikiem jest:

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

javascriptmoże ocenić ten format według eval()funkcji i utworzyć tablicę asocjacyjną z tego JSONciągu. To jest inna koncepcja niż inne koncepcje, które opisałem wcześniej.