ulx_logo_400ulx_logo_400ulx_logo_400ulx_logo_400
  • MEGOLDÁSAINK
    • Konténerizáció és hibrid felhő
      • Automatizált DMZ-létrehozás
      • Hibrid load-menedzsment operátor
    • DevOps és felhőnatív fejlesztés
    • Adatközponti és felhőautomatizáció
    • Szolgáltatásközpontú transzformáció
    • Klasszikus és felhőalapú rendszerek integrációja
    • Nagyvállalati adatbáziskezelés
  • SZOLGÁLTATÁSAINK
    • Kritikus rendszerek támogatása
    • Fejlesztői támogatás
    • Nagyvállalati OpenShift integráció
      • Automatizált DMZ-létrehozás
      • Hibrid load-menedzsment operátor
    • Klasszikus és felhőalapú integráció
    • Komplex rendszerek tervezése, megvalósítása
    • Automatizáció, szolgáltatáskialakítás
    • Oktatás
    • Tanácsadási szolgáltatások
  • OKTATÁSOK
    • Red Hat Enterprise Linux alap- és intenzív tanfolyamok
      • RH124 – Red Hat Rendszeradminisztráció I.
      • RH134 – Red Hat Rendszeradminisztráció II.
      • RH199 – Intenzív RHCSA tanfolyam
      • RH294 – Red Hat Rendszeradminisztráció III: Linux automatizáció
    • Red Hat Automatizáció tanfolyamok
      • DO417 – Microsoft Windows automatizálás Red Hat Ansible segítségével tanfolyam
      • DO457 – Hálózatautomatizáció Red Hat Ansible használatával tanfolyam
      • DO467 – Nagyvállalati automatizálás Red Hat Ansible Automation Platform segítségével tanfolyam
    • Speciális Red Hat Enterprise Linux tanfolyamok
      • RH342 – Red Hat Enterprise Linux Diagnosztika és Hibaelhárítás
      • RH358 – Red Hat Szolgáltatás-menedzsment és automatizáció tanfolyam
      • RH403 – Red Hat Satellite 6 adminisztráció tanfolyam
      • RH442 – Red Hat Enterprise Performance Tuning tanfolyam
    • Red Hat felhő, köztesréteg és storage tanfolyamok
      • CL110 – Red Hat OpenStack adminisztráció tanfolyam
      • CL210 – Red Hat OpenStack adminisztráció II. tanfolyam
      • DO180 – Bevezetés a konténerizációba és a Kubernetes technológiába
      • DO280 – Red Hat OpenShift adminisztrációI: Élesüzemű Kubernetes klaszterek üzemeltetése
      • DO288 – Red Hat OpenShift fejlesztés: Alkalmazások konténerizációja
      • DO322 – Red Hat OpenShift telepítése a gyakorlatban tanfolyam
      • DO380 – Skálázható Kubernetes környezetek készítése vállalati környezetben
    • Fejlesztői tanfolyamok
      • AD183 – Red Hat Alkalmazás fejlesztés I: Programozás Java EE környezetben
      • DO288 – Fejlesztés Red Hat OpenShiften – Konténerizált alkalmazások tanfolyam
      • DO378 – Red Hat Cloud-native Microservices fejlesztése Quarkus-szal tanfolyam
      • AD482 – Eseményvezérelt alkalmazások fejlesztése Apache Kafka és Red Hat AMQ Streams segítségével tanfolyam
    • Hivatalos Red Hat tanúsítványok
      • EX200 – Red Hat Certified System Administration (RHCSA) vizsga
      • EX294 – Red Hat Certified Engineer (RHCE) vizsga
    • PostgreSQL / EnterpriseDB tanfolyamok
      • Bevezető PostgreSQL adminisztráció tanfolyam
      • Haladó PostgreSQL adminisztráció tanfolyam
      • Átfogó PostgreSQL adminisztráció tanfolyam
      • PostgreSQL adminisztráció és fejlesztés tanfolyam
      • Bevezető PostgreSQL fejlesztői tanfolyam
      • Postgres Plus Advanced Server adminisztráció tanfolyam
    • Előzetes szintfelmérők a tanfolyamokhoz
      • PostgreSQL / EnterpriseDB Szintfelmérő
    • Tanfolyami naptár
    • Red Hat Academy
  • TERMÉKEK
    • Red Hat Enterprise Linux
      • Red Hat Enterprise Linux
      • Red Hat Satellite
      • Red Hat Insights
      • Red Hat Smart Management
    • Red Hat OpenShift
      • OpenShift Container Platform
      • Red Hat ACM for Kubernetes
      • Red Hat OpenShift Advanced Cluster Security for Kubernetes
      • Red Hat OpenShift Data Foundation
      • Red Hat Quay
    • Red Hat Ansible Automation
    • Red Hat OpenStack Platform
    • Red Hat JBoss middleware
      • Red Hat JBoss Enterprise Application Platform
      • Red Hat JBoss Web Server
      • Red Hat Data Grid
      • Red Hat Runtimes
      • Red Hat Fuse
      • Red Hat A-MQ
      • Red Hat 3Scale
      • Red Hat Decision Manager
      • Red Hat Process Automation Manager
    • EnterpriseDB
      • EnterpriseDB PostgreSQL
      • EDB Postgres Advanced Server
    • Nagios
  • Rólunk
    • Hírek és események
  • Red Hat Summit 2023

Gondolatok a REST-ről 10 pontban, I. rész

  • Home
  • Híreink és eseményeink
  • Technológiai újdonságok
  • Gondolatok a REST-ről 10 pontban, I. rész
2008-08-26
Categories
  • Technológiai újdonságok
Tags

Továbbra is igaz, hogy ha valamit megtudunk a REST-ről, végül azon kezdünk el gondolkodni, hogy a fogalom mennyire alkalmazható a mi saját, adott forgatókönyvünk esetén. Maga a REST a Representational State Transfer rövidítése, mely egy olyan architektúra, ami meghatározza, hogy a webes erőforrásokat hogyan definiáljuk és címezzük.Mivel valószínűleg teljesen más architekturális megközelítéshez vagyunk hozzászokva, természetes, ha kétségbe vonjuk, hogy a REST vagy inkább a RESTesített HTTP a gyakorlatban is működik, vagy úgy gondoljuk, hogy egyszerűen nem működik, ha komolyabb dolgokra szeretnénk használni. Ebben a cikkben a REST-tel kapcsolatban előforduló tíz leggyakoribb kétséget taglaljuk, melyek főleg akkor jelentkeznek, amikor az emberek elkezdik felfedezni, és különösen akkor, ha a SOAP/WSDL alapú webszolgáltatásokkal kapcsolatban már rendelkeznek szilárd architekturális háttérrel.

1. A REST talán alkalmazható CRUD-hoz, de nem alkalmazható a „valós” üzleti logikához

Ez a leggyakoribb reakció, melyet a REST előnyeivel kapcsolatos szkepticizmus megnyilvánulásaként tapasztalhatunk. Végül is, ha csak CRUD műveleteket (Create – létrehozás, Read – olvasás, Update – frissítés, Delete –törlés) hajtunk végre, akkor hogyan lehetséges, hogy összetettebb alkalmazási szemantikát fejezzünk ki?

Először is, a HTTP műveletek – Get, Put, Post és Delete – nem képezhetők le egy az egyben a CRUD adatbázis műveletekhez. Például mind a Post mind a Put művelet felhasználható új erőforrások létrehozása során, azonban különböznek abban, hogy a Put esetén a kliens az, aki meghatározza az erőforrás URI-ját (amit majd frissítenek vagy létrehoznak), míg a Post egy „collection” vagy „factory” erőforráshoz kapcsolódik, és a szervernek a feladata, hogy az URI-t hozzárendelje. Térjünk azonban vissza a kérdésre, hogy hogyan kezelünk összetettebb üzleti logikát?

Bármilyen művelet (calc (a, b)), mely egy adott c eredménnyel tér vissza, átalakítható egy olyan URI-vá, mely a számítás eredményét azonosítja. Például az x= calc (2,3) az alábbi URI-t eredményezi: http://example.com/calculation?a=2&b=3. Először ez úgy tűnik, mintha csúnyán visszaélnénk a RESTesített HTTP-vel; az URI-kat nem erőforrások azonosításához kellene használni a műveletek azonosítása helyett? Igen, de lényegében ezt is tesszük: a http://example.com/sum?augend=2&addend=3 egy erőforrást azonosít, mégpedig a 2 és 3 összeadásának eredményét. Ha ebben az adott (nyilvánvalóan jól kigondolt) példában a Get műveletet arra használjuk, hogy az eredményt visszakapjuk, ez egy jó ötlet; végül is gyorstárazható (cache), hivatkozhatunk rá, és a számítás valószínűleg biztonságos és nem nagyon költséges.

Természetesen sok esetben rossz megközelítésnek bizonyulhat, ha a Get műveletet valaminek a kiszámítására használjuk. Emlékezzünk rá, hogy a Get „biztonságos” művelet kell, hogy legyen, azaz a kliens nem fogad el semmi kötelezettséget (például, hogy fizessen a szolgáltatásunkért), vagy nem feltételez semmilyen felelősséget, amikor csak a hivatkozást követi, a Get parancson keresztül. Sok más esetben ezért ésszerű, ha beviteli adatot nyújtunk a szervernek, így az új erőforrásokat tud létrehozni a Post műveleten keresztül. A szerver a válaszában jelezni tudja az eredmény URI-ját (és lehetőleg egy átirányítást eszközölhet, hogy odavigyen). Ennek az eredménye aztán újból használható, könyvjelzők közé hozzáadható, és a megjelenítés után gyorstárazható. Alapjában véve ezt a modellt bármilyen olyan műveletre kiterjeszthetjük, melynek van eredménye, tehát gyakorlatilag mindegyikre.

2. Nincs formális kontraktus és leíró nyelv

Az RPC-től a CORBA-ig, a DCOM-tól a webszolgáltatásokig, hozzá vagyunk ahhoz szokva, hogy van egy interfész leírás, ami a műveleteket, azok nevét, illetve a beviteli és kiviteli paramétereiket listázza. Hogyan használhatjuk a REST-et az interfész leíró nyelv nélkül? Erre a gyakran feltett kérdésre három válasz van.

Először is, ha amellett döntünk, hogy RESTesített HTTP-t használunk XML-lel együtt, ami egy nagyon gyakori választás, még mindig elérhetők számunkra az XML séma nyelvek, csakúgy, mint a DTD-k, az XML Schema, a RELAX NG vagy a Schematron. A WSDL használatával létrehozott leírások 95 százaléka egyáltalán nincs WSDL-hez kötve, hanem inkább azokhoz az XML Schema-ban lévő összetett típusokhoz kapcsolódik, melyeket meghatározunk. Amit a WSDL ehhez hozzáad, az leginkább a műveletek és azok nevei; ezek leírása meglehetősen unalmassá válik a REST egységes interfészével. Végül is a Get, Put, Post és Delete az összes lehetséges művelet. Az XML Schema használatát illetően ez azt jelenti, hogy a kedvenc adat kapcsolati eszközünket (már ha van ilyan) használhatjuk az adat kapcsolati kód generálásához a választott nyelvhez, még akkor is, ha RESTesített interfészre támaszkodunk. (ez nem a teljes válasz, lásd később)

Másodszor, fontos, hogy megkérdezzük magunktól, hogy miért is van szükségünk a leírásra. A leggyakoribb, habár nem az egyetlen felhasználási eset, hogy a leírandó interfész stubjainak és skeletonjainak generálásához használjuk a leírást. Ez általában nem a dokumentáció, mivel a leírás (például WSDL formátumban) nem mond semmit a műveletek szemantikájáról, csak egy nevet tartalmaz. Szükség van valami olvasható dokumentációra, hogy tudjuk hogy kell meghívni a műveletet. Egy tipikus REST megközelítés esetén HTML formátumú dokumentációt nyújtunk, lehetőleg közvetlen hivatkozásokkal az erőforrásokhoz. Ha azt a megközelítést alkalmazzuk, hogy több reprezentációt használunk, talán önmagukat dokumentáló erőforrásaink is lehetnek, csak ki kell egy HTTP Get parancsot adnunk egy erőforráson a böngészőnkben, és egy HTML dokumentumot kapunk, ami adatokat, valamint a rajta elvégezhető műveletek listáját is tartalmazza (HTTP műveletek), illetve a tartalom típusokat, melyeket elfogad és nyújt.

Végül, ha ragaszkodunk a leíró nyelv használatához a RESTesített szolgáltatásaink esetén, akkor webes alkalmazás leíró nyelvet (WADL) használhatunk, vagy bizonyos korlátokkal WSDL 2.0-át, ami a szerzői szerint képes a RESTesített szolgáltatások leírására is. Sem a WADL sem a WSDL 2 nem használhatók hatékonyan hipermedia leírására, noha a REST-nek ez az egyik alapvető tulajdonsága.

Copyright: ULX, 2023