Atstovaujantis valstybės perdavimo (REST) ​​ir paprasto objekto prieigos protokolas (SOAP)

Ar kas nors gali paaiškinti, kas yra „REST“ ir kokia SOAP yra paprasto anglų kalba? Ir kaip veikia interneto paslaugos?

708
16 окт. Vicky rinkinys spalio 16 d. 2008-10-16 22:24 '08, 10:24 val. 2008-10-16 22:24
@ 15 atsakymų

Paprastas SOAP ir REST paaiškinimas

SOAP - „Paprastas objekto prieigos protokolas“

SOAP - tai būdas siųsti pranešimus ar nedidelius informacijos kiekius internetu. SOAP pranešimai yra suformatuoti XML ir paprastai siunčiami naudojant HTTP (Hypertext Transfer Protocol) protokolą.


Poilsis - peržiūros būsenos perkėlimas

Poilsis yra paprastas būdas siųsti ir priimti duomenis tarp kliento ir serverio, ir jame nėra labai daug nustatytų standartų. Galite siųsti ir gauti duomenis kaip JSON, XML arba net paprastą tekstą. Tai lengvas, palyginti su SOAP.


2019

1576 m
24 янв. atsakymas pateikiamas Nakkeeran 24 d 2012-01-24 10:02 '12, 10:02 2012-01-24 10:02

Abu metodai naudojami daugeliui svarbių žaidėjų. Tai yra pirmenybės klausimas. Man labiau patinka REST, nes jį lengviau naudoti ir suprasti.

Paprastas objekto prieigos protokolas (SOAP):

  • SOAP sukuria XML per HTTP arba kartais TCP / IP.
  • SOAP aprašo funkcijas ir duomenų tipus.
  • SOAP yra XML-RPC perėmėjas ir yra labai panašus, tačiau apibūdina standartinį bendravimo metodą.
  • Kai kuriose programavimo kalbose yra įmontuota SOAP parama, paprastai perduodate interneto paslaugos URL ir galite skambinti savo interneto paslaugų funkcijomis be specialaus kodo.
  • Išsiųsti dvejetainiai duomenys pirmiausia turi būti užkoduoti tokiu formatu kaip bazinis64.
  • Jis turi keletą protokolų ir technologijų, susijusių su šiuo klausimu: WSDL, XSD, SOAP, WS-Addressing

Atstovaujantis valstybės vertimas (REST):

  • REST neprivalo būti per HTTP, tačiau dauguma mano žemiau esančių taškų turės HTTP nuokrypį.
  • „REST“ yra labai paprasta, sako palaukite minutę, mums nereikia visų sudėtingumo, kurį sukūrė SOAP.
  • Paprastai vietoj didelio XML formato, kuris apibūdina viską, paprastai naudoja normalius HTTP metodus. Pvz., Norėdami gauti išteklių, naudojate HTTP GET ir naudojate HTTP PUT, kad serveryje surastumėte išteklių. Jei norite ištrinti resursą serveryje, naudokite HTTP DELETE.
  • REST yra labai paprasta, nes naudoja HTTP GET, POST ir PUT metodus, kad atnaujintų resursus serveryje.
  • REST dažniausiai geriausiai naudojamas su ištekliais orientuota architektūra (ROA). Šiuo mąstymo būdu viskas yra ištekliai, ir jūs dirbsite šiais ištekliais.
  • Tol, kol jūsų programavimo kalba turi HTTP biblioteką, ir daugeliu atvejų, galite lengvai naudoti HTTP REST protokolą.
  • Dvejetainiai duomenys arba dvejetainiai ištekliai gali būti pristatomi paprašius.

REST vs SOAP turi begalines diskusijas „Google“ .

Mano mėgstamiausia tai . 2013 m. Lapkričio 27 d. Atnaujinimas: atrodo, kad „Paul Prescod“ tinklapis neprisijungęs, ir šis straipsnis nebepasiekiamas, nors kopijas galima rasti „ Wayback“ įrenginyje arba PDF formatu „ CiteSeerX“ .

317
16 окт. Brian R. Bondy atsakymas 16 okt. 2008-10-16 22:33 '08 at 10:33 pm 2008-10-16 22:33

REST

Suprantu, kad pagrindinė REST idėja yra labai paprasta. Jau daugelį metų naudojome žiniatinklio naršykles ir matėme, kaip paprasta, lanksti, efektyvi ir pan. Svetainės. HTML svetainės naudoja hipersaitus ir formas kaip pagrindines vartotojų sąveikos priemones. Jų pagrindinis tikslas yra leisti mums, klientams, sužinoti tik tas nuorodas, kurias galime naudoti dabartinėje būsenoje . Ir „REST“ paprasčiausiai sako: „Kodėl gi ne naudoti tuos pačius principus kompiuterių valdymui, o ne su žmogaus klientais? Sujunkite tai su WWW infrastruktūros galia ir gausite žudymo įrankį didelių paskirstytų programų kūrimui.

Kitas galimas matematiškai mąstančių žmonių paaiškinimas. Kiekviena programa iš esmės yra valstybės mašina su verslo logikos veiksmais, kurie yra valstybės perėjimai. „REST“ idėja yra rodyti kiekvieną perėjimą prie tam tikro išteklių užklausos ir suteikti klientams nuorodas, rodančias esamas būsenas. Taigi ji modeliuoja valstybės mašiną per vaizdus ir nuorodas. Štai kodėl jis pavadino reprezentatyvios valstybės perdavimą.

Stebėtina, kad visi atsakymai yra sutelkti į pranešimo formatą arba HTTP veiksmažodžių naudojimą. Tiesą sakant, pranešimo formatas visiškai nesvarbus, REST gali naudoti bet kurį, su sąlyga, kad paslaugų teikėjas jį dokumentuoja. HTTP veiksmažodžiai atlieka paslaugą tik CRUD paslauga, bet dar neatnaujina. Kas iš tikrųjų paverčia paslaugą į REST paslaugą, yra hipersaitai (pvz., Hipermedžio kontrolė), įterpti į serverio atsakymus kartu su duomenimis, ir turėtų būti pakankamai jų, kad bet kuris klientas galėtų pasirinkti kitą veiksmą iš šių nuorodų.

Deja, gana sunku rasti tinkamą informaciją apie internetą, išskyrus Roy Fielding disertacijas . (Jis yra tas, kuris gavo REST). Norėčiau rekomenduoti knygą „REST in Practice“, nes jame pateikiama išsami pamoka apie tai, kaip vystytis nuo SOAP iki REST.

SOAP

Tai viena iš galimų RPC (nuotolinio procedūros kvietimo) architektūros forma. Iš esmės tai yra tik technologija, leidžianti klientams skambinti serverio metodais per paslaugų ribas (tinklą, procesus ir pan.), Tarsi skambinant vietiniais metodais. Žinoma, tai iš tikrųjų skiriasi nuo vietinių greičio, patikimumo ir tt metodų. Tačiau idėja yra paprasta.

Palyginimui

Išsami informacija, pvz., Transporto protokolai, pranešimų formatai, xsd, wsdl ir tt, nėra svarbi, lyginant bet kokią RPC formą su REST. Pagrindinis skirtumas yra tas, kad RPC tarnyba išbando dviratį ir sukuria savo taikomųjų programų protokolą RPC API su semantika, kurią tik žino. Todėl visi klientai turi suprasti šį protokolą prieš naudodamiesi paslauga, ir dėl visų užklausų semantikos negali būti sukurta bendra infrastruktūra, pvz., Talpyklos. Be to, RPC API nesiūlo, kokie veiksmai yra leidžiami dabartinėje būsenoje, tai turi būti gaunama iš papildomų dokumentų. Kita vertus, REST naudoja vienodas sąsajas, kurios leidžia skirtingiems klientams suprasti API semantiką, taip pat hipersaitų valdymo įrankius (nuorodas), kad būtų paryškintos kiekvienoje valstybėje esančios parinktys. Tokiu būdu jis leidžia talpinti atsakymus į keičiamo dydžio paslaugas ir teisingai naudoti API, be papildomų dokumentų.

Tam tikra prasme SOAP (kaip ir bet kuris kitas RPC) yra bandymas tuneliu per visą paslaugų ribą, atsižvelgiant į jungiamąją terpę kaip juodą >

Atrodo, kad SOAP puikiai tinka vidaus tinklo API, kai valdote tiek serverį, tiek klientus, o sąveika nėra pernelyg sudėtinga. Kūrėjams labiau naudinga naudoti. Tačiau viešosios API, kurią naudoja daugelis nepriklausomų šalių, sudėtingų ir didelių, REST turėtų geriau atitikti. Tačiau paskutinis palyginimas yra labai neaiškus.

Atnaujinti

Nenuostabu, kad mano patirtis parodė, kad REST kūrimas yra sudėtingesnis nei SOAP. Bent. Nors yra didelių sistemų, tokių kaip ASP.NET Web API, nėra įrankių, kurie automatiškai generuoja tarpinį serverį kliento pusėje. Nieko panašaus į „Pridėti nuorodą į žiniatinklio paslaugą“ arba „Pridėti nuorodą į WCF paslaugą“. Jums reikia parašyti visą užklausą dėl serializavimo ir paslaugų užklausos. Ir žmogus, tai yra daug šablonų. Manau, kad kuriant REST reikia kažką panašaus į WSDL ir įrankių įgyvendinimą kiekvienai plėtros platformai. Tiesą sakant, atrodo, kad yra geras pagrindas: WADL arba WSDL 2.0 , tačiau nė vienas iš šių standartų nėra palaikomas.

Atnaujinimas (2016 m. Sausio mėn.)

Pasirodo, kad dabar yra daug įrankių REST API nustatymui. Mano asmeninė nuostata šiuo metu yra RAML .

Kaip veikia interneto paslaugos

Na, tai yra per platus klausimas, nes tai priklauso nuo architektūros ir technologijos, naudojamos konkrečioje interneto paslaugoje. Tačiau apskritai žiniatinklio paslauga yra tiesiog internetinė programa, kuri gali gauti klientų užklausas ir grąžinti atsakymus. Ji yra atvira internetui, todėl ji yra žiniatinklio paslauga, kuri paprastai teikiama visą parą, todėl tai yra paslauga. Žinoma, tai išsprendžia kai kurias problemas (kitaip, kodėl kas nors naudojasi interneto paslauga) savo klientams.

244
19 сент. Atsakyti Pavel Gatilov Rugsėjo 19 d 2012-09-19 21:41 '12, 9:41 val. 2012-09-19 21:41

Tai paprasčiausias paaiškinimas, kurį kada nors rasite.

Šiame straipsnyje vyras pasakoja savo žmonai istoriją, kurioje vyras paaiškina savo žmonai apie REST, grynai neprofesionaliame plane. Būtinai perskaitykite!

kaip-i-paaiškinti-poilsio-mano-žmona (originali nuoroda)
kaip-aš-paaiškinau-mano-žmona (2013-07-19 darbo nuoroda)

39
13 июля '12 в 10:33 2012-07-13 10:33 atsakymą pateikė „ Vinay Wadhwa “ liepos 12 d., 10:33 2012-07-13 10:33

SOAP - paprasto objekto prieigos protokolas yra protokolas!

DEPARTAMENTAS - pristatymo būsenos perdavimas yra architektūrinis stilius!

SOAP yra XML protokolas, naudojamas pranešimams perduoti, paprastai per HTTP.

REST ir SOAP gali būti tarpusavyje nesuderinami. „RESTful“ architektūra gali naudoti HTTP arba SOAP arba kitą ryšių protokolą. REST optimizuotas tinklui, todėl HTTP yra idealus pasirinkimas. HTTP pat yra vienintelis protokolas, aptartas Roy Fielding straipsnyje.

Nors „REST“ ir „SOAP“ aiškiai skiriasi viena nuo kitos, klausimas pabrėžia, kad „ REST ir „ HTTP dažnai naudojami kartu. Tai visų pirma yra dėl HTTP paprastumo ir natūralaus žemėlapio, skirto „RESTful“ principams.

Pagrindiniai REST principai

Kliento serverio ryšys

Klientų ir serverių architektūros turi labai aiškų problemų atskyrimą. Visos programos „RESTful“ sukurtos programos taip pat turėtų būti spausdintuvo kliento-serverio.

Be pilietybės

Kiekvienam kliento užsakymui serveryje reikia, kad jo statusas būtų pilnai atvaizduotas. Serveris turi sugebėti visiškai suprasti kliento užklausą nenaudodamas jokios serverio būsenos ar serverio sesijos būsenos. Iš to išplaukia, kad visa valstybė turi būti laikoma kliente. Detaliau aptarsime atstovavimą be pilietybės vėliau.

Cacheable

Galima naudoti talpyklą ribojančius apribojimus, leidžiančius rodyti atsakymo duomenis kaip įrašančius arba nepavojingus. Bet kokie talpykloje pažymėti duomenys gali būti pakartotinai naudojami kaip atsakymas į tą patį vėlesnį prašymą.

Vienoda sąsaja

Visi komponentai turi sąveikauti vienoje vienoje sąsajoje. Kadangi visų komponentų sąveika vyksta per šią sąsają, sąveika su įvairiomis paslaugomis yra labai paprasta. Sąsaja yra ta pati! Tai taip pat reiškia, kad įgyvendinimo pokyčiai gali būti atliekami atskirai. Tokie pokyčiai neturės įtakos pagrindinių komponentų sąveikai, nes vienoda sąsaja visada lieka tokia pati. Vienas iš trūkumų yra tas, kad esate įstrigę sąsajoje. Jei optimizavimas gali būti teikiamas konkrečiai paslaugai keičiant sąsają, nesisekė, nes „REST“ tai neigia. Tačiau ryškioje pusėje REST yra optimizuotas internetui, todėl neįtikėtinas populiarumas REST per HTTP!

Pirmiau minėtos sąvokos yra REST charakteristikos ir išskiria REST architektūrą nuo kitų architektūrų, pvz., Interneto paslaugų. Naudinga pažymėti, kad „REST“ paslauga yra žiniatinklio paslauga, tačiau žiniatinklio paslauga nebūtinai yra „REST“ paslauga.

Daugiau informacijos apie REST ir pirmiau minėtus prekės ženklus žr. Šio dienoraščio įrašąREST Design Principles “.

37
14 марта '14 в 23:28 2014-03-14 23:28 atsakymas pateikiamas cmd kovo 14, 14, 23:28 2014-03-14 23:28

Man patinka Brian R. Bondi. Aš tik norėjau pridurti, kad Vikipedija pateikia aiškų REST aprašymą. Straipsnyje ji išskiriama nuo SOAP.

„REST“ yra keitimasis informacija apie statusą, padarytas kuo paprastesnis.

SOAP yra pranešimo protokolas, kuris naudoja XML.

Viena iš pagrindinių priežasčių, dėl kurių daugelis žmonių persikėlė iš SOAP į REST, yra tai, kad WS-* standartai (vadinami WS splat), susiję su SOAP pagrindu veikiančiomis žiniatinklio paslaugomis, yra labai sudėtingi. Specifikacijų sąrašą žr. Wikipedia . Kiekviena iš šių specifikacijų yra labai sudėtinga.

EDIT: dėl tam tikrų priežasčių nuorodos rodomos neteisingai. REST = http://en.wikipedia.org/wiki/REST

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

12
16 окт. Atsakyti David G Oct 16 2008-10-16 22:47 '08, 10:47 pm 2008-10-16 22:47

Tiek SOAP žiniatinklio paslaugos, tiek REST žiniatinklio paslaugos taip pat gali naudoti HTTP protokolą ir kitus protokolus (tik paminėdami, kad SOAP gali būti pagrindinis REST protokolas). Kalbėsiu tik apie HTTP protokolą, susijusį su SOAP ir REST, nes tai yra dažniausiai naudojamas.

SOAP

SOAP (Simple Object Access Protocol) yra protokolas (ir W3C standartas ). Jis apibrėžia, kaip kurti, siųsti ir apdoroti SOAP pranešimus.

  • SOAP pranešimai yra XML dokumentai, turintys tam tikrą struktūrą: juose yra voko, kuriame yra antraštė ir kūno dalis. Kūno sudėtyje yra faktinių duomenų, kuriuos norime siųsti - XML ​​formatu. Yra du kodavimo stiliai , tačiau mes paprastai renkamės pažodinį , o tai reiškia, kad mūsų programa arba jos SOAP tvarkyklė yra XML serializacija ir duomenų neformalizavimas.

  • SOAP pranešimai perkeliami kaip HTTP pranešimai su MIME SOAP + XML potipiu. Šie HTTP pranešimai gali būti daugiapartiniai, todėl galime pridėti failus į SOAP pranešimus.

  • Akivaizdu, kad mes naudojame kliento-serverio architektūrą, todėl SOAP klientai siunčia užklausas į SOAP svetaines ir paslaugos siunčia atsakymus klientams. Daugelis žiniatinklio paslaugų naudoja WSDL failą paslaugai apibūdinti. WSDL faile yra XML duomenų schema (toliau - XSD), kurią norite siųsti, ir WSDL privalomasis ryšys, kuris apibrėžia, kaip žiniatinklio paslauga yra susieta su HTTP protokolu. Yra du privalomi stiliai : RPC ir Dokumentas. Įjungus RPC stilių, SOAP kūnas turi operatyvinio skambučio su parametrais (HTTP užklausomis) arba grąžinimo reikšmėmis (HTTP atsakymu). Parametrai ir grąžinimo reikšmės tikrinamos pagal XSD. Sujungus dokumento stilių, SOAP korpuse yra XML dokumentas, patvirtintas „XSD“. Manau, kad dokumento įpareigojimo stilius yra geriau pritaikytas įvykių pagrindu veikiančioms sistemoms, bet aš niekada nenaudojau šio privalomo stiliaus. RPC privalomasis stilius yra labiau paplitęs, todėl dauguma vartotojų naudoja SOAP XML / RPC tikslais platinamoms programoms. Interneto paslaugos paprastai aptinka viena kitą, nurodydamos UDDI serverį. UDDI serveriai yra registrai, kuriuose saugoma interneto paslaugų vieta.

SOAP RPC

Taigi, mano nuomone, dažniausia SOAP žiniatinklio paslauga naudoja RPC privalomąjį stilių ir abėcėlinį kodavimo stilių ir turi šias savybes:

  • Jis parodo sandorių URL.
  • Jis siunčia pranešimus su SOAP + XML MIME potipiu.
  • Ji gali turėti serverio pusės sesijos saugojimo funkciją, tai nėra jokių apribojimų.
  • SOAP kliento tvarkyklės naudoja WSDL paslaugų failą, kad konvertuotų RPC operacijas į metodus. Kliento programa bendrauja su SOAP žiniatinklio paslauga, pasitelkdama šiuos metodus. Taigi, dauguma SOAP klientų yra nutraukiami sąsajos pakeitimais (dėl to gaunami metodų pavadinimai ir (arba) parametrų pakeitimai).
  • Jūs galite rašyti SOAP klientus, kurie nepažeidžia sąsajos pakeitimų, naudodami RDF ir surasdami semantiką, tačiau semantinė žiniatinklio paslauga yra labai reti, ir jūs neturite turėti nesėkmingo kliento (manau).

REST

REST (reprezentatyvus valstybės perdavimas) - tai architektūrinis stilius, aprašytas Roy Fielding disertacijoje . Tai netaikoma protokolams, tokiems kaip SOAP. Jis prasideda nulinio tipo architektūra, kuri neturi jokių apribojimų, ir apibrėžia REST architektūros apribojimus po vieną. Žmonės naudoja terminą RESTful interneto paslaugoms, kurios atitinka visus REST apribojimus, tačiau, pasak Roy Fielding, nėra tokių elementų kaip REST lygiai . Kai su kiekviena REST suvaržymu neįvyksta žiniatinklio paslauga, tai nėra REST žiniatinklio paslauga.

REST apribojimai

  • Kliento-serverio architektūra. Manau, kad ši dalis yra visiems žinoma. „REST“ klientai susisieks su „REST“ žiniatinklio paslaugomis, žiniatinklio paslaugos išlaikys bendrą duomenų būseną - ateityje išteklius - ir aptarnaus klientus.
  • Nevalstybinis - pastraipos „valstybės perdavimas“ santrumpa: REST. Klientai palaiko kliento būseną (sesijos / programos būseną), todėl paslaugos neturėtų turėti sesijos parduotuvės. Klientai perduoda atitinkamą kliento būsenos dalį kiekvienai užklausai į paslaugas, atitinkančias atitinkamą išteklių būklės dalį (jas palaiko jų). Todėl prašymuose nėra jokio konteksto, juose visada pateikiama jų apdorojimui reikalinga informacija. Pavyzdžiui, HTTP pagrindiniame auth vartotojo vardas ir slaptažodis yra saugomi kliento, ir jis siunčia juos su kiekvienu prašymu, todėl autentifikavimas atliekamas kiekviename prašyme. Tai labai skiriasi nuo įprastų žiniatinklio programų, kuriose autentifikavimas vyksta tik prisijungus. Mes galime naudoti bet kurį kliento duomenų saugojimo mechanizmą, pavyzdžiui, atmintyje („javascript“), slapukus, „localStorage“ ir pan. Neteisėtumo priežastis yra tai, kad serveris skalauja gerai - net ir su labai didelėmis apkrovomis (milijonais vartotojų), kai nereikia palaikyti sesijos kiekvienam klientui.
  • Spartusis talpyklos atsakymas turi apimti informaciją apie tai, ar klientas gali jį išsaugoti, ar ne. Tai dar labiau pagerina mastelį.
  • Vienoda sąsaja

    • Išteklių identifikavimas - REST ištekliai yra tokie patys kaip RDF ištekliai. Согласно Филдингу, если вы можете что-то назвать, тогда это может быть ресурс, например: "текущая местная погода" может быть ресурсом, или "ваш мобильный телефон" может быть ресурсом, или "конкретный веб-документ" может быть ресурс. Чтобы идентифицировать ресурс, вы можете использовать идентификаторы ресурсов: 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"} . Поэтому мы можем использовать это представление для изменения состояния клиента, например, мы можем отобразить "Добро пожаловать на нашу страницу, миссис Смит!" pranešimą. Ресурс может иметь множество представлений в зависимости от идентификатора ресурса (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 , всего лишь краткий список из них: