Nümunə Dövlət Transfer (REST) ​​və Simple Object Access Protocol (SOAP)

Kimsə RESTolduğunuSOAP düz İngilis dilində nə olduğunu izah edə bilərmi? Və veb xidmətləri necə işləyir?

708
16 окт. Vicky 16 oktyabr təyin etdi . 2008-10-16 22:24 '08 saat 22: 00-da 2008-10-16 22:24
@ 15 cavab

SOAP və REST-in sadə izahı

SOAP - "Simple Object Access Protocol"

SOAP İnternet vasitəsilə mesajlar və ya kiçik miqdarda məlumat göndərmək üçün bir yoldur. SOAP mesajları XML formatlıdır və ümumiyyətlə HTTP (Hypertext Transfer Protocol) protokolu ilə göndərilir.


Rahatlıq - baxış vəziyyətinin ötürülməsi

İstirahət, bir müştəri ilə server arasındakı məlumatları göndərmək və qəbul etmək üçün sadə bir üsuldur və çox sayda müəyyən edilmiş standartlara malik deyildir. JSON, XML və ya hətta düz mətn kimi məlumatları göndərə və qəbul edə bilərsiniz. SOAP ilə müqayisədə yüngüldür.


border=0

2019

1576
24 янв. cavab Nakkeeran Jan 24 verilir 2012-01-24 10:02 '12 at 10:02 2012-01-24 10:02

Hər iki üsul bir çox əsas oyunçu tərəfindən istifadə olunur. Bu üstünlük məsələsi. RESTi üstün tuturam çünki istifadə etmək və anlamaq daha asandır.

Sadə Nesne Erişimi Protokolu (SOAP):

  • SOAP HTTP və ya bəzən TCP / IP üzərində XML yaradır.
  • SOAP funksiyaları və məlumat növlərini təsvir edir.
  • SOAP XML-RPC-nin varisidir və çox oxşardır, lakin standart rabitə üsulunu təsvir edir.
  • Bəzi proqramlaşdırma dilləri daxili SOAP dəstəyinə malikdir, adətən bir web xidmətinin URL-ə daxil olur və öz veb xidmətlərinin funksiyalarını xüsusi kod olmadan zəng edə bilərsiniz.
  • Göndərilən ikili məlumatlar əvvəlcədən bazlı kodlanmış bir formatda kodlaşdırılmalıdır.
  • Bununla əlaqədar bir neçə protokol və texnologiya var: WSDL, XSD, SOAP, WS-Addressing

Nümunə Dövlət Tərcümə (REST):

border=0
  • REST'in HTTP vasitəsilə olması lazım deyil, ancaq aşağıdakı məntəqələrimin bir hissəsi HTTP ofsetinə malik olacaq.
  • REST çox asandır, bir dəqiqə gözləyin, SOAP yaradılan bütün kompleksliyə ehtiyacımız yoxdur.
  • Adətən, hər şeyi təsvir edən böyük bir XML formatı yerinə normal HTTP üsulları istifadə edir. Məsələn, bir qaynaq almaq üçün HTTP GET istifadə edirsiniz və bir serverda bir resurs yerləşdirmək üçün HTTP PUT istifadə edirsiniz. Serverdə bir resurs silmək üçün HTTP DELETE istifadə edirsiniz.
  • REST serverdə resursları yeniləmək üçün HTTP GET, POST və PUT üsullarını istifadə etdiyi üçün çox sadədir.
  • REST, ən yaxşı şəkildə resurs yönümlü bir arxitektura (ROA) ilə istifadə olunur. Bu düşüncə tərzində hər şey bir qaynaqdır və bu qaynaqlarda fəaliyyət göstərəcəksiniz.
  • Proqramlaşdırma diliniz bir HTTP kitabxanası olduğundan və çoxu bunu edirsə, HTTP REST protokolunu çox asanlıqla istifadə edə bilərsiniz.
  • İkili məlumatlar və ikili resurslar sadəcə istek əsasında verilə bilər.

REST vs SOAP Google-da sonsuz müzakirələrə sahibdir .

Sevdiyim bu . 27 Noyabr 2013-də yeniləmə: Paul Prescod veb-saytının offline keçdiyini görünsə də, bu nüsxə Wayping Machine-də və ya CiteSeerX- də PDF formatında tapıla bilər.

317
16 окт. Brian R. Bondy tərəfindən verilən cavab 16 oktyabr. 2008-10-16 22:33 '08 saat 22:33 'da 2008-10-16 22:33

REST

REST'in əsas fikri son dərəcə sadə olduğunu başa düşürəm. İllərcə veb-brauzerlərdən istifadə etdik və nə qədər asan, çevik, effektiv və s. Veb saytlar. HTML saytlar hiperlink və formaları istifadəçi qarşılıqlı təsir vasitəsi kimi istifadə edir. Onların əsas məqsədi, müştərilərimizin, mövcud vəziyyətdə istifadə edə biləcəyimiz yalnız əlaqələri bilməsi üçün bizə imkan verməkdir. Və REST sadəcə deyir: "Niyə tətbiqi ilə insan müştəriləri ilə deyil, kompüter idarəetmə üçün eyni prinsiplərdən istifadə etməyin?" WWW infrastrukturunun gücüylə birləşdirin və böyük paylanmış proqramların qurulması üçün bir qatil alətini əldə edin.

Riyazi baxımdan düşünülmüş insanlar üçün başqa bir izahat. Hər bir ərizə əsasən dövlət keçidləri olan işgəncə hərəkətləri olan dövlət maşındır. REST ideyası hər bir keçid bir qayda üçün müəyyən bir tələbə keçirmək və müştərilərə hazır vəziyyətdə olan keçidləri təmsil edən əlaqələr göstərməkdir. Beləliklə, dövlət maşınını baxış və bağlantılar vasitəsilə modelləşdirir. Ona görə də təmsil edən dövlətin köçürülməsini çağırdı.

Şaşırtıcı biçimde, bütün cavablar ya mesaj formatında və ya HTTP fiillerinin istifadə edilməsinə yönəlmiş görünür. Əslində, mesajın formatı heç bir əhəmiyyət kəsb etməz, REST, xidməti sənədin tərtibçisi tərəfindən təqdim edildiyi halda istifadə edə bilər. HTTP fe'lləri xidmətə yalnız bir CRUD xidməti təqdim edir, lakin hələ RESTful deyil. Bir REST xidmətinə çevrilən həqiqət, serverin verdikləri cavablarla əlaqəli hiperlinklər (hipermedia nəzarətləri kimi) və hər hansı bir müştəri bu əlaqələrdən sonrakı hərəkətləri seçə bilməsi üçün kifayət qədər olmalıdır.

Roy Fielding'in tezisləri istisna olmaqla, təəssüf ki, İnternetdə doğru REST məlumatlarını tapmaq çox çətindir. (O REST almışdır). SOAP-dan REST-ə necə inkişaf etməklə bağlı ətraflı bir addım-addım təlimat verdiyindən, "REST in Practice" kitabını tövsiyə edirəm.

SOAP

Bu RPC (Remote Procedure Call) arxitekturasının mümkün bir formasıdır. Əslində, bu, müştərilərin xidmət üsulları (şəbəkə, proseslər, və s.) Arasında server metodlarını zənginləşdirmək üçün imkan verir ki, onlar yerli üsulları çağırırlar. Əlbəttə ki, bu sürət, etibarlılıq və s. Üçün yerli üsulları çağırmaqdan fərqlənir. Ancaq fikir sadədir.

Müqayisədə

Nəqliyyat protokolu, mesaj formatları, xsd, wsdl, və s. Kimi məlumatlar REST ilə hər hansı bir RPC formasını müqayisə edərkən vacibdir. Əsas fərq, RPC xidmətinin, RPC API-dakı öz tətbiq protokolunu yaradan, yalnız bildiyi semantik ilə bisiklet yaratmasıdır. Buna görə də, bütün müştərilər xidmətdən istifadə etməzdən əvvəl bu protokolu anlayacaqlar və bütün sorğuların semantikası səbəbindən önbelleklər kimi heç bir ümumi infrastruktur yaradılmır. Bundan əlavə, RPC API-ləri mövcud vəziyyətdə hansı hərəkətlərə icazə verildiyini təklif etmir, bu əlavə sənədlərdən əldə edilməlidir. Digər tərəfdən REST, fərqli müştərilərin hər bir haldakı mövcud variantları vurğulamaq üçün API-nın semantikası ilə yanaşı, köprü köməyi idarə alətlərini (bağlantılar) də bir anlayışa malik olmasına imkan verən vahid interfeyslərin istifadəsini nəzərdə tutur. Beləliklə, əlavə sənədlər olmadan geniş miqyaslı xidmətlərə cavabların cache və API düzgün istifadə imkan verir.

Bir mənada, SOAP (hər hansı digər RPC kimi) yalnız mesaj ötürmək qabiliyyətinə malik olan qara qutu kimi əlaqəli mühiti nəzərə alaraq, xidmət hüdudları arasında tunel cəhdidir. REST, interneti dünyadakı kimi qəbul etmək, onu necə idarə etmək və bununla mübarizə etmək üçün böyük bir paylanmış informasiya sistemi olduğunu qəbul etmək qərarıdır.

SOAP, server və müştərilərə nəzarət edərkən daxili şəbəkə API'ları üçün böyük görünür və qarşılıqlı təsir çox mürəkkəb deyil. İstehsalçılar üçün istifadə etmək daha təbii. Lakin, bir çox müstəqil tərəflər tərəfindən istifadə edilən ictimai API üçün, kompleks və böyük, REST daha uyğun olmalıdır. Lakin son müqayisə çox qeyri-müəyyəndir.

Yeniləmə

Mənim təcrübə təəccüblə göstərir ki, REST-in inkişafı SOAP-dan daha çətindir. Ən azı. NET üçün. ASP.NET Web API kimi böyük çərçivələr olmasına baxmayaraq, müştəri tərəfində avtomatik olaraq bir proxy server yaratmaq üçün heç bir vasitə yoxdur. "Veb xidmətinə bir keçid əlavə et" və ya "WCF xidmətinə link əlavə edin" kimi bir şey yoxdur. Serializasiya və xidmət tələbi üçün bütün tələbi yazmalısınız. Və insan, bu bir çox şablondur. Hesab edirəm ki, REST-in inkişafı WSDL və hər bir inkişaf platforması üçün alətlərin tətbiqi kimi bir şey tələb edir. Əslində yaxşı bir təməl var: WADL və ya WSDL 2.0 , lakin standartlardan heç biri dəstəklənmir.

Güncelleme (yanvar 2016)

İndi REST API müəyyənləşdirmək üçün geniş alətlər var . Mənim şəxsi seçimim hazırda RAML .

Veb xidmətlər necə işləyir?

Bəli, bu çox geniş bir sualdır, çünki müəyyən bir web xidmətində tətbiq edilən arxitektura və texnologiyadan asılıdır. Ancaq ümumiyyətlə, bir web xidməti sadəcə müştərilərdən sorğu ala biləcək və cavabları geri ala biləcək İnternetdə tətbiq olunur. İnternetə açıqdır, buna görə də bir web xidmətidir və adətən 24/7 mövcuddur, buna görə də bir xidmətdir. Əlbəttə, bu müştərilər üçün bəzi problemləri həll edir (əksinə, bəziləri bir web xidməti istifadə edir).

244
19 сент. Cavab Pavel Gatilov 19 sentyabr 2012-09-19 21:41 '12 saat 09:41 'da 2012-09-19 21:41

Bu heç tapa bilməyəcək ən sadə izahatdır.

Bu yazıda həyat yoldaşı həyat yoldaşı REST ilə əlaqədar açıq-aydın peşəkar bir planda izah edən həyat yoldaşına xəbər verir. Oxumağa əmin olun!

necə-i-izah-istirahət-to-my-arvad (orijinal link)
necə-i-izah-istirahət-to-my-arvad (2013-07-19 iş link)

39
13 июля '12 в 10:33 2012-07-13 10:33 Cavab Vinay Wadhwa tərəfindən 13 iyul 2012-ci ildə saat 10:33 da verilir 2012-07-13 10:33

SOAP - Simple Object Access Protocol bir protokoldur!

BÖLÜM - Təqdimat statusu transferi memarlıq üslubudur!

SOAP , HTTP vasitəsilə adətən mesaj ötürmək üçün istifadə olunan XML protokudur.

RESTSOAP birindən SOAP bilməz . RESTful architecture HTTP və ya SOAP və ya digər bir rabitə protokolunu istifadə edə bilər. REST şəbəkə üçün optimize edilmişdir və buna görə də HTTP ideal seçimdir. HTTP , Roy Fielding'in yazısında da müzakirə edilən tək protokoldur.

REST və SOAP bir-birindən fərqli olmasına baxmayaraq, sual RESTHTTP nin tez-tez tandemdə istifadə olunduğunu vurğulayır. Bu, əsasən, HTTP-nin sadəliyini və onun təbii Xəritəçəkməini RESTFUL prinsipləri ilə bağlıdır.

Əsas REST prinsipləri

Müştəri server rabitəsi

Müştəri-server mimarileri problemlərin çox dəqiq bir şəkildə ayrılmasına səbəb olur. RESTful üslubunda yaradılan bütün ərizələr də printerdə müştəri-server olmalıdır.

Vətənsiz

Serverin hər bir müştəri sorğusu onun vəziyyətinin tam şəkildə göstərilməsini tələb edir. Server, hər hansı bir server vəziyyəti və ya server iclas vəziyyəti istifadə etmədən müştəri tələbini tam başa düşməlidir. Bundan budur ki, bütün dövlət müştəridə saxlanılmalıdır. Daha sonra daha ətraflı olaraq vətəndaşlığı olmayan nümayəndəliyi müzakirə edəcəyik.

Cacheable

Önbelleğe alınmış məhdudiyyətlər istifadə edilə bilər ki, cavab verilərini cacheable və ya cache-cacheable kimi göstərə bilərsiniz. Önbellekli olaraq qeyd olunan hər hansı bir məlumat, eyni sonrakı sorğuya cavab olaraq təkrar istifadə edilə bilər.

Uniforma interfeysi

Bütün komponentlər bir vahid interfeys vasitəsilə qarşılıqlı olmalıdır. Bütün komponentlərin qarşılıqlı əlaqəsi bu interfeysdən ibarət olduğundan, müxtəlif xidmətlərlə qarşılıqlı əlaqə çox sadədir. İnterfeys eyni! Bu, həmçinin həyata keçirilmə dəyişikliklərinin təcrid olunmasında da deməkdir. Belə dəyişikliklər əsas komponentlərin qarşılıqlı təsirinə səbəb olmayacaq, çünki vahid interfeys həmişə eynidır. Diqqətlərin bir hissəsi siz interfeysdə sıxışdığınızdır. İnteqrasiya interfeysini dəyişdirərək xüsusi bir xidmətə təqdim oluna bilərsə, REST bunu inkar etdiyinə görə uğursuzluqdan qaçın. Lakin, parlaq tərəfdə, REST İnternet üçün optimallaşdırılmışdır, beləliklə HTTP üzərində REST inanılmaz populyarlıq!

Yuxarıda göstərilən anlayışlar REST-in müəyyən xüsusiyyətləridir və REST mimarisini web xidmətləri kimi digər mimarlardan ayırır. REST xidmətinin bir web xidməti olduğunu qeyd etmək faydalıdır, lakin web xidməti mütləq REST xidməti deyildir.

REST və yuxarıda göstərilən markalar haqqında ətraflı məlumat üçün REST Design Principles-da bu blog yazısına baxın.

37
14 марта '14 в 23:28 2014-03-14 23:28 cevap 14 mart '14 'də saat 23:28' də verilir. 2014-03-14 23:28

Brian R. Bondi sevirəm. Mən yalnız Vikipediyanın REST-in dəqiq təsviri olduğunu əlavə etmək istərdim. Məqaləni SOAPdan ayırır.

REST, statusu məlumatların mübadiləsi, mümkün qədər sadədir.

SOAP XML istifadə edən bir mesaj protokolu.

Bir çox insanların SOAP-dan REST-ə köçürülməsinin əsas səbəblərindən biri, SOAP-based web xidmətlərinə aid WS- * standartlarının (WS splat) olduqca mürəkkəbdir. Spesifikasiyalar siyahısına görə Vikipediya baxın. Bu xüsusiyyətlərin hər biri çox mürəkkəbdir.

EDIT: heç bir səbəblə əlaqələr səhv göstərilir. REST = http://en.wikipedia.org/wiki/REST

WS- * = http://en.wikipedia.org/wiki/WS- *

12
16 окт. Cavab David G Oct 16 2008-10-16 22:47 '08 saat 10:47 'da 2008-10-16 22:47

Hər iki SOAP veb xidmətləri və REST web xidmətləri də HTTP protokolunu və digər protokollardan istifadə edə bilər (yalnız SOAP əsas REST protokolu ola bilər). SOAP və REST ilə əlaqəli HTTP protokolundan danışacağam, çünki bu, ən çox yayılmış istifadədir.

SOAP

SOAP (Simple Object Access Protocol) protokol (və W3C standartıdır ). SOAP mesajlarının necə yaradılacağını, göndərilməsini və işlədilməsini müəyyən edir.

  • SOAP mesajları xüsusi bir strukturu olan XML sənədləridir: bir başlıq və bədən bölməsi olan bir zərfdən ibarətdir. Bədən faktiki məlumatları ehtiva edir - göndərmək istəyirik - XML ​​formatında. İki kodlama üslubu var , amma biz adətən bir literal seçirik , yəni tətbiqi və ya SOAP sürücüsü XML serializasiyası və məlumatların qeyri-materializasiyasıdır.

  • SOAP mesajları, MIME SOAP + XML alt tipli HTTP mesajları kimi köçürülür. Bu HTTP mesajları çoxpartiyalı ola bilər, belə ki SOAP mesajlarına faylları əlavə edə bilərik.

  • Aydındır ki, bir müştəri-server mimarisini istifadə edirik, belə ki SOAP müştəriləri SOAP veb saytlarına müraciət göndərir və xidmətlər müştərilərə cavablar göndərir. Çox web xidmətləri xidməti təsvir etmək üçün WSDL faylı istifadə edir. WSDL faylı, göndərmək istədiklərimizin XML şemasını (bundan sonra XSD) və veb xidmətinin HTTP protokoluna necə bağlı olduğunu müəyyən edən WSDL məcburiyyətini ehtiva edir. İki bağlayıcı üslub var : RPC və Sənəd. RPC stilində bağlama prosesində SOAP cədvəli parametrləri (HTTP istəkləri) və ya qaytarma dəyərləri (HTTP cavab) ilə əməliyyat çağırışının bir təmsilçisini ehtiva edir. Parametrlər və qaytarma dəyərləri XSD üçün yoxlanılır. Sənəd stilini bağlayaraq, SOAP gövdəsi XSD üçün təsdiq edilmiş bir XML sənədini ehtiva edir. Sənədin məcburi tərzinin hadisə mərkəzli sistemlər üçün daha uyğun olduğunu düşünürəm, amma bu məcburi tərzini heç vaxt istifadə etməmişəm. RPC məcburi tərzi daha çox yayılmışdır, buna görə istifadəçilərin çoxu SOAP paketini yaymaq üçün XML / RPC məqsədləri üçün istifadə edirlər. Web xidmətləri, bir UDDI server göstərərək adətən bir- birlərini tapır . UDDI serverləri web xidmətlərinin yerini saxlayan qeydlərdir.

SOAP RPC

Beləliklə, mənim fikrimcə, ən çox yayılmış SOAP veb xidməti RPC bağlama stilini və alfabetik kodlama stilindən istifadə edir və aşağıdakı xüsusiyyətlərə malikdir:

  • İşlemler üçün URL'ler gösterilir.
  • Bir SOAP + XML MIME alt növü ilə mesajlar göndərir.
  • Server tərəfindəki sessiyanın saxlanması ola bilər, bunun üçün heç bir məhdudiyyət yoxdur.
  • SOAP müştəri sürücüləri RPC əməliyyatlarını metodlara çevirmək üçün WSDL xidmət faylını istifadə edir. Müştəri proqramı, bu üsulları tətbiq edərək SOAP web xidməti ilə qarşılıqlı əlaqə yaradır. Beləliklə, SOAP müştərilərinin bir çoxu interfeys dəyişiklikləri ilə nəticələnir (nəticədə metod adları və / və ya parametr dəyişikliyi).
  • RDF'yi istifadə edərək interfeys dəyişikliklərinə getməyən və semantikləri tapmaqda çətinlik çəkən SOAP müştərilərini yaza bilərsiniz, ancaq semantik web xidməti çox nadirdir və müvəffəqiyyətsiz bir müştəriyə (düşünürəm) sahib olmalısan.

REST

REST (nümayəndənin dövlət transferi) Roy Fielding dissertasiyasında təsvir edilmiş bir memarlıq üslubudur. Bu SOAP kimi protokollara tətbiq edilmir. Bu, heç bir məhdudiyyətə malik olmayan bir sıfır memarlıq növü ilə başlayır və REST arxitekturasının məhdudiyyətlərini tək-tək müəyyən edir. İnsanlar REST-in bütün məhdudiyyətlərini yerinə yetirən web xidmətləri üçün RESTful termini istifadə edirlər, lakin, Roy Fielding görə, REST səviyyəsi kimi elementlər yoxdur. Bir web xidməti hər REST məhdudiyyəti ilə baş vermədikdə, REST web xidməti deyildir.

REST məhdudiyyətləri

  • Müştəri-server mimarisi. Hesab edirəm ki, bu hissə hər kəsə tanışdır. REST müştəriləri REST veb xidmətləri ilə əlaqə quracaqlar, veb xidmətlər gələcəkdə bir qaynaq olan məlumatların ümumi vəziyyətini qoruyurlar və müştərilərə xidmət edirlər.
  • Vatansız - paraqrafın "dövlətin köçürülməsi" kısaltması: REST. Müştərilər müştərinin vəziyyətini saxlayır (iclas / ərizə vəziyyəti), beləliklə xidmətlərin seans dükanı olmamalıdır. Müştərilər, hər bir tələb üçün resurs dövlətinin müvafiq hissəsinə cavab verən xidmətlərə (onların dəstəyi ilə) müştəri dövlətinin müvafiq hissəsini ötürür. Buna görə, istəklər heç bir kontekstə malik deyil, həmişə onları işləyib hazırlamaq üçün lazımi məlumatları ehtiva edir. Məsələn, HTTP əsas authdə istifadəçi adı və şifrə müştəri tərəfindən saxlanılır və hər bir tələb ilə onları göndərir, beləliklə, hər bir sorğuda identifikasiya baş verir. Bu ad veriliş yalnız girişdə baş verən adi web tətbiqlərindən çox fərqlənir. Istədiyiniz təqdirdə müştərilərin hər hansı bir hissəsini saxlamaq üçün yaddaşda (javascript), çerezlərdə, localStorage və s. Kimi hər hansı bir müştəri məlumatı saxlama mexanizmindən istifadə edə bilərik. Vətəndaşsızlığın səbəbi, serverin hər bir fərdi müştəri üçün bir sessiya saxlamağa ehtiyac olmadığı halda, hətta çox yüksək yüklərlə (milyonlarla istifadəçi) yaxşı tərəzi.
  • Önbellek cevabı müşteri tarafından önbelleğe alınabilir olub olmadığına dair məlumatları içermelidir. Bu da ölçeklenebilirliği artırır.
  • Uniforma interfeysi

    • Resurs Təsviri - REST resursu RDF resursu ilə eynidır. Согласно Филдингу, если вы можете что-то назвать, тогда это может быть ресурс, например: "текущая местная погода" может быть ресурсом, или "ваш мобильный телефон" может быть ресурсом, или "конкретный веб-документ" может быть ресурс. Чтобы идентифицировать ресурс, вы можете использовать идентификаторы ресурсов: URL и URN (например номер ISBN по книгам ). Один идентификатор должен принадлежать только определенному ресурсу, но один ресурс может иметь много идентификаторов, которые мы часто используем, например, путем разбивки на страницы с URL-адресами, такими как https://example.com/api/v1/users?offset=50> . URL-адреса имеют некоторые спецификации , например URL-адреса с одинаковыми адресами, но разные запросы не идентичны, или часть пути должна содержать иерархические данные URL-адреса, а часть запроса должна содержат неиерархические данные. Вот основные сведения о том, как создавать URL-адреса с помощью REST. Btw. структура URL имеет значение только для разработчиков услуг, настоящий клиент REST не относится к нему. Другой часто задаваемый вопрос - это управление версиями API, что является простым, потому что, согласно Fielding, единственная постоянная вещь по ресурсу - это семантика. Если семантика изменится, вы можете добавить новый номер версии. Вы можете использовать классическое 3-мерное число версий и добавить только основное число в URL-адреса ( https://example.com/api/v1/ ). Таким образом, благодаря обратным совместимым изменениям ничего не происходит, благодаря изменениям, не связанным с обратной совместимостью, у вас будет несовместимая семантика с новым API root https://example.com/api/v2/ . Таким образом, старые клиенты не будут ломаться, потому что они могут использовать https://example.com/api/v1/ со старой семантикой.
    • Манипулирование ресурсами через представления. Вы можете манипулировать данными, относящимися к ресурсам (состояние ресурса), отправив предполагаемое представление ресурсов - вместе с методом HTTP и идентификатором ресурса - в службу REST. Например, если вы хотите переименовать пользователя после вступления в брак, вы можете отправить запрос PATCH https://example.com/api/v1/users/1 {name: "Mrs Smith"} , где {name: "Mrs Smith"} является представлением JSON для предполагаемого состояния ресурса, другими словами: новое имя. Это происходит наоборот, служба отправляет представления ресурсов клиентам, чтобы изменить их состояния. Например, если мы хотим прочитать новое имя, мы можем отправить запрос на поиск GET https://example.com/api/v1/users/1?fields="name" , в результате получим ответ 200 ok, {name: "Mrs Smith"} . Поэтому мы можем использовать это представление для изменения состояния клиента, например, мы можем отобразить "Добро пожаловать на нашу страницу, миссис Смит!" mesajı. Ресурс может иметь множество представлений в зависимости от идентификатора ресурса (URL) или заголовка accept , который мы отправили с запросом. Например, мы можем отправить изображение миссис Смит (возможно, не обнаженное), если запрошено image/jpeg .
    • Самоописательные сообщения. Сообщения должны содержать информацию о том, как их обрабатывать. Например, метод URI и HTTP, заголовок типа контента, заголовки кеша, RDF, который описывает смысл данных и т.д. Важно использовать стандартные методы. Важно знать спецификацию методов HTTP. Например, GET означает получение информации, идентифицируемой URL-адресом запроса, DELETE означает запрос сервера на удаление ресурса, идентифицированного данным URL-адресом, и так далее... Коды состояния HTTP имеют спецификацию , например, 200 означает успех, 201 означает, что новый ресурс создан, 404 означает, что запрошенный ресурс не найден на сервере и т.д. Использование существующих стандартов является важной частью REST.
    • Hypermedia как двигатель состояния приложения (HATEOAS в дальнейшем) - Hypermedia - это тип носителя, который может содержать гиперссылки. В Интернете мы следим за ссылками, описанными в формате гипермедиа (обычно HTML) - для достижения цели вместо ввода URL-адресов в панель addres. REST следует той же концепции, представления, отправленные службой, могут содержать гиперссылки. Мы используем эти гиперссылки для отправки запросов в службу. С ответом мы получаем данные (и, возможно, больше ссылок), которые мы можем использовать для создания нового состояния клиента и т.д. Итак, почему гипермедиа - это двигатель состояния приложения (состояние клиента). Вы, наверное, задаетесь вопросом, как клиенты узнают и следуют гиперссылкам? У людей это довольно просто, мы читаем название ссылки, возможно, заполняем поля ввода, а после этого всего один клик. По машинам мы должны добавить семантику к ссылкам с RDF ( JSON-LD с Hydra ) или с конкретными решениями гипермедиа (например Связи IANA и специфические для поставщика типы MIME HAL + JSON ). Есть много машиночитаемых XML и форматов гиперссылки JSON , всего лишь краткий список из них:

      Иногда трудно выбрать...

  • Многоуровневая система. Мы можем использовать несколько уровней между клиентами и службами. Ни один из них не должен знать обо всех этих добавочных слоях, просто рядом с ним. Эти слои могут улучшить масштабируемость, применяя кеши и балансировку нагрузки, или они могут применять политики безопасности.
  • Код по требованию - мы можем отправить обратно код, который расширяет функциональность клиента, например код JavaScript в браузере. Это единственное необязательное ограничение REST.

REST webservice - Различия в веб-сервисах SOAP RPC

Таким образом, веб-сервис REST сильно отличается от веб-службы SOAP (с использованием стиля привязки RPC и стиля литерала)

  • Он определяет единый интерфейс (в соответствии с протоколом).
  • Он сопоставляет URL-адреса ресурсам (а не операциям).
  • Он отправляет сообщения с любыми типами MIME (вместо SOAP + XML).
  • Он имеет связь без состояния и поэтому не может иметь хранилище сеансов на стороне сервера. (SOAP не имеет ограничений по этому поводу)
  • Он обслуживает гипермедиа, и клиенты используют ссылки, содержащиеся в этой гипермедиа, чтобы запросить услугу. (SOAP RPC использует привязки операций, описанные в файле WSDL)
  • Он не прерывается изменениями URL только с помощью семантических изменений. (Клиенты SOAP RPC без использования семантики RDF в результате изменения файла WSDL.)
  • Он масштабируется лучше, чем веб-сервис SOAP из-за его поведения без гражданства.

və s

Веб-сервис SOAP RPC не отвечает всем ограничениям REST:

  • архитектура клиент-сервер - всегда
  • stateless - возможно
  • cache - возможно
  • единый интерфейс - никогда
  • многоуровневая система - никогда
  • код по запросу (необязательно) - возможно
7
ответ дан inf3rno 07 сент. '14 в 6:42 2014-09-07 06:42

Хорошо, я начну со второго вопроса: что такое веб-службы?, по понятным причинам.

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

В следующей ссылке говорится о REST и SOAP в чрезвычайно ясной форме.

REST vs SOAP

Если вы также хотите знать, когда выбрать, что (REST или SOAP), тем больше причин пройти через это!

6
ответ дан Sayan 11 окт. '12 в 10:39 2012-10-11 10:39

SOAP и REST ссылаются на способы взаимодействия разных систем.

REST делает это, используя методы, которые напоминают связь, которую ваш браузер имеет с веб-серверами: с помощью GET для запроса веб-страницы, POSTing в поля формы и т.д.

SOAP обеспечивает нечто подобное, но делает все путем отправки блоков XML взад и вперед. Другим ключевым компонентом SOAP является WSDL, который является документом XML, который описывает, какие функции и элементы данных поддерживаются. WSDL могут использоваться для программного "обнаружения", какие функции поддерживаются, а также для генерации программных кодов.

4
ответ дан pbreitenbach 04 июля '09 в 9:09 2009-07-04 09:09

Проблема с SOAP заключается в том, что она противоречит идеалам, стоящим за стекю HTTP. Любое промежуточное программное обеспечение должно работать с HTTP-запросами без понимания содержимого запроса или ответа, но, например, обычный HTTP-кеширующий сервер не будет работать с запросами SOAP, не зная только, какие части содержимого SOAP имеют значение для кэширования. SOAP просто использует HTTP в качестве оболочки для своего собственного протокола связи, например прокси.

2
ответ дан aehlke 20 июля '09 в 20:54 2009-07-20 20:54

Я думаю, что это так же просто, как я могу это объяснить. Пожалуйста, кто-нибудь может исправить меня или добавить к этому.

SOAP - это формат сообщений, используемый отключенными системами (например, через Интернет) для обмена информацией/данными. Это происходит с XML-сообщениями, идущими назад и вперед.

Веб-службы передают или получают сообщения SOAP. Они работают по-разному в зависимости от того, на каком языке они написаны.

2
ответ дан StingyJack 16 окт. '08 в 22:30 2008-10-16 22:30

REST - это стиль архитектуры для проектирования сетевых приложений. Идея состоит в том, что вместо использования сложных механизмов, таких как CORBA, RPC или SOAP для соединения между машинами, простой HTTP используется для совершения вызовов между машинами.

2
ответ дан Hulk1991 11 июня '13 в 13:13 2013-06-11 13:13

SOAP - "Протокол простого доступа к объектам"

SOAP - это небольшая передача сообщений или небольшое количество информации через Интернет. Сообщения SOAP отформатированы в XML и обычно отправляются с контролем HTTP .

REST - "Передача состояния препроцессора"

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

1
ответ дан user4502652 04 февр. '15 в 19:34 2015-02-04 19:34

Вот хороший пример, если вы знаете немного С#: массив DataTable (т.е. DataTable []), список DataTable (т.е. List...) и IEnumerable из DataTables (т.е. IEnumerable...) и DataSet - это одно и то же в json (они выглядели бы как [[..first table - это массив объектов...], [.. second table..], [. etc.....]]. В С# это совершенно разные вещи IEnumerable - это интерфейс, DataSet - совершенно другой класс.

Вопрос под рукой "какова цель?" Если вы хотите показать свою базу данных (или небольшую часть вашей базы данных) всему миру (скажем, вы - аэропорт, и вы хотите, чтобы каждый Джон, Джейн и Дик знали, как совершали посадку и отправления), вы наверняка захотите отправиться в путь. с JSON (отдых). Им действительно все равно, как вы храните ваши данные - они просто хотят, чтобы они были в json. С другой стороны, если это внутренняя служба внутри вашей компании, вы хотите, чтобы она была очень точной. Это может быть хорошей идеей предоставить конечную точку с интерфейсом или абстрактными классами для полиморфных целей. (скажем, ваша авиакомпания хочет, чтобы ее самолеты очень эффективно сообщали о погоде практически в режиме реального времени в ходе полета). конечно, вы хотите SOAP поверх WCF в этом случае. Эта ясность классов, интерфейсов, рефератов окупится с точки зрения внутреннего программирования и простоты.

0
ответ дан LongChalk 21 янв. '19 в 10:25 2019-01-21 10:25

SOAP-based Web Services Короче говоря, модель SOAP-based Services рассматривает мир как экосистему равных партнеров, которые не могут контролировать друг друга, но должны работать вместе, соблюдая опубликованные контракты. Это действительный модель беспорядочного реального мира, а контракты на основе метаданных образуют интерфейс SOAP Service.

мы все равно можем связать SOAP с удаленными вызовами процедур на основе XML, но технология SOAP-based Web Services превратилась в гибкую и мощную модель обмена сообщениями.

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

Контракты между системами коллективно называются метаданными и содержат описания сервисов, поддерживаемые шаблоны обмена сообщениями и политики, определяющие качества обслуживания (услуга может должны быть зашифрованы, надежно доставлены и т.д.). Описание услуги, в свою очередь, представляет собой подробную спецификацию данных (документов сообщений), которые будут отправляться и приниматься системой. Документы описанных с использованием языка описания XML, такого как определение схемы XML. Пока все системы соблюдают свои опубликованные контракты, они могут взаимодействовать, а изменения во внутренних системах никогда не влияют на другие. Каждая система отвечает за перевод собственных внутренних реализаций в свои контракты и из своих контрактов.

REST - Передача трансформирующего состояния. Физическое протокол HTTP. В принципе, REST - это то, что все уникальные ресурсы в Интернете однозначно идентифицируются по URL-адресу. Все операции, которые могут выполняться на этих ресурсах, могут быть описаны ограниченным набором глаголов (глаголы "CRUD" ), которые, в свою очередь, сопоставляются с HTTP-глаголами.

REST намного меньше "тяжеловеса", чем SOAP.

Работа с веб-сервисом

-4
ответ дан kapil das 19 окт. '13 в 9:46 2013-10-19 09:46

Другие вопросы по меткам или Задайте вопрос