Co to je REST? (diskuse)

[Miriam]

REST tak jak ho implementoval Google mi nesmí na oči, je to prasárna, prasárna a nic než prasárna.

[backinabag]

O co konkrétně jde?

[xkucf03]

+1, viděl jsem, jak se snaží zpřístupnit čistě procedurální (z principu) věci pomocí RESTu (protože ten teď přece frčí a všichni ho musí mít), prasárna, zvrácenost.

[Josef Kufner]

Pointa RESTu je v tom, že máš globální identifikátory (URI), předdefinované API a bezstavový protokol, kterým přenášíš informaci o stavu v aplikaci.

Když se to správně implementuje a to předdefinované API stačí, má to pár pěkných vlastností. Například kešovatelnost odpovědí serveru na několika úrovních (např. na HTTP proxy, klientovi i serveru), vysokou škálovatelnost (bezstavový protokol) a pak také hyerlinky, které jsou přirozenou součástí toho všeho (odkazování napříč několika aplikacema). Díky HTTP metodě OPTIONS pak může klient zjistit, co lze s entitou na dané URI dělat, takže tu je i nějaká taková možnost reflexe.

Ta disertace, ve které to bylo představeno, to opravdu popisuje dost abstraktně a za těch cca 10 let se i význam REST trochu posunul. Jsou tam ale popsány ty základní myšlenky, které se vytratily z většiny moderních blábolů, ehm, textů o RESTu.

[Bedňa]

bezstavový protokol, kterým přenášíš informaci o stavu v aplikaci

To hovorí za všetko

[Josef Kufner]

Co se ti na tom nelíbí?

[Bedňa]

Len mi tá veta prišla zaujímavá.

[backinabag]

Co přesně je bezstavový protokol? Není databáze na serveru stav?

Takže se dá říct, že REST API zveřejňuje několik podmnožin stavu serveru (resp. pohledů na stav serveru), kde každá podmnožina je reprezentována nějakou URL?

[Michal Karas]

Stateless protocol

[Josef Kufner]

Rozlišuj stav na serveru a přenos informace o tomto stavu.

[JS1]

To co me na zacatku matlo bylo to, ze to, co se puvodne oznacovalo (respektive u ceho ten termin vznikl) jako REST, to znamena WSDL a SOAP, se dnes uz za REST neoznacuje. Dnes je REST v podstate navrat k cistemu HTTP protokolu, protoze WSDL je prekomplikovane.

[podlesh]

Cože, někdo někdy někde označoval SOAP nebo dokonce WSDL za REST? To jsem neviděl a nedovedu si to ani představit...

Jo, něco jiného by byl termín "web services" - tam se skutečně význam začíná posouvat.

[JS1]

I SOAP se tusim da delat bezstavove, tudiz muzou platit pravidla RESTu. Proste REST je puvodne filozofie navrhu, nezavisla na protokolu, ale dneska se pod tim spis chape specificky navrh vyuzivajici urcitym (jednoduchym) zpusobem HTTP protokol.

[Saljack]

Jenže SOAP je RPC kdežto REST je orientován na data, pokud v tomto nespatřuješ rozdíl, tak je něco špatně.

[JS1]

SOAP/WSDL webservices jsem prilis nestudoval, jenom rikam, ze me to matlo. Evidentne se to ale, z toho co jsem o tom na zacatku cetl, tim RESTovym zpusobem (Representational State Transfer) pouzivat da.

[Josef Kufner]

Slovíčka GET, POST, PUT a další jsou označovány jako HTTP metody. To není omylem a je to úplně to samé jako RPC, jen to vypadá na první pohled trochu jinak. Narozdíl od SOAP máš u HTTP tyto metody předem dané ve specifikaci protokolu. Takže když v SOAP nadefinuješ ty samé metody, jako ty ve specifikaci HTTP, dostaneš prakticky totéž, jen s jinou syntaxí.

[xkucf03]

Rozdíl je v tom, že ve WSDL můžeš krásně specifikovat o obsah/strukturu zpráv (požadavků a odpovědí), čehož se RESTaři až křečovitě brání (WADL, WSDL pro REST?) a strojově čitelný tam máš tak leda MIME typ (ale jaká má být struktura, co posíláš, nebo jakou dostaneš, to si musíš přečíst někde jinde nebo nějak vypozorovat).

Malé shrnutí:

Primární orientace:
REST: zdroje, kolekce dat
SOAP: procedury

Základní metody:
REST: standardizované, omezená sada (CRUD, vazba na HTTP operace)
SOAP: specifikují se až operace ve WSDL, obecně standardizované nejsou (CRUD operace si můžu pojmenovat, jak chci), neomezená sada – definuji si libovolné operace

Obsah zpráv:
REST: není definovaný, maximálně jen MIME typ, nebo se strojově čitelná definice nepoužívá
SOAP: obsah zpráv resp. parametry procedur a struktura odpovědí může být velmi přesně a strojově čitelně specifikované → dá se vygenerovat dobré rozhraní v mnoha různých jazycích a snadno ho volat a zpracovávat odpovědi, typová kontrola

Podkladový protokol:
REST: velmi těsná vazba na HTTP
SOAP: zprávy lze přenášet libovolným kanálem

[backinabag]

Z mých zkušeností je mnohem příjemnější pracovat s RESTem než se SOAPem. SOAP je strašně robustní a flexibilní, REST krásně jednoduchý. Na papíře na tom sice vychází SOAP líp, ale v praxi mi přijde REST-like API s online dokumentací mnohem lepší.

[xkucf03]

Neříkám, že SOAP je obecně lepší – ono když potřebuješ čistý CRUD a máš někde jinde specifikovaný formát obsahu nebo na něm nezáleží, tak je REST fajn.

[xkucf03]

P.S. ono to hlavně nejde srovnávat a nemělo by se to brát jako konkurenční technologie – měl by ses rozhodnout podle toho, jestli jsou pro tebe primární procedury nebo zdroje.

[xvasek]

SOAP: obsah zpráv resp. parametry procedur a struktura odpovědí může být velmi přesně a strojově čitelně specifikovat

Pěkná teorie. To je asi jako napsat, že C je multiplatformní jazyk a tudíž programy v něm napsané poběží všude.

[podlesh]

No, pokud ho srovnáváme s assemblerem, tak ano...

[xkucf03]

Ano, to je klíčový rozdíl. Proto to pak dopadá celkem blbě, když si někdo vybere REST a nakonec zjistí, že potřebuje volat taky nějaké procedury. Ale má to i jiná úskalí…

[podlesh]

Ano, jistě, dá se to. Ledacos se dá.

Ale to není vysvětlení původního výroku

se puvodne oznacovalo (respektive u ceho ten termin vznikl)

[sigma]

Co považuju za velké omezení toho, co se aktuálně nazývá REST (viz komentář JS1), tedy využití čistého HTTP, je nemožnost standardním způsobem zabalit více "volání" GET do jednoho HTTP požadavku. Protože ID objektu/zdroje je URL.

Mám aplikaci, kde na zobrazení jedné stránky (pohledu, formuláře), potřebuju načíst třeba 20 zdrojů různého typu - tj. v klasickém RESTu 20 HTTP requestů, které se zařadí buď za sebe = velká latence, nebo se pošlou částečně paralelně = taky zbytečný. Částečně by to řešil SPDY protokol, ale ... Možná to ukazuje na špatný návrh API - v tomhle případě by to šlo zjednodušit vytvořením "meta-zdrojů", ale ne úplně a ztratil bych dost flexibility. XML-RPC na to má MultiCall, takže to není úplně marný use-case.

[Saljack]

Ale to je problém v tvém návrhu ne v REST. Nic ti nebrání vytvořit zdroj, který bude vracet nějakou strukturu kombinovanou z jiných zdrojů, pokud spolu nějak souvisí. Pokud spolu nesouvisí, tak je nesmysl je volat zároveň.

[sigma]

Souvisí spolu minimálně tak, že je chci zobrazit v aplikaci najednou. A nechci na ně posílat požadavky přes HTTP sériově, protože roundtrip linky × počet requestů = jednotky sekund, co by uživatel čekal.

[pavlix]

Pak je asi dobré umět postavit dotaz, který ti vrátí všechna data, co potřebuješ, najednou. A je jedno, jak tomu budeš říkat.

[sarimak]

Vypada to, ze pouzivas prilis jemne API (na urovni entit) pro pomalou meziprocesovou komunikaci. Asi by se vic hodilo API zverejnovat az na urovni metod/use cases. Patterns of EIP k tomu pise tohle:

In general we prefer well-defined, self-contained business actions such as “Change Address” and “Place Order” because they give us more flexibility in orchestrating the businesses processes. It all comes down to a question of granularity and the associated trade-offs. Fine-grained interfaces can lead to sluggish systems due to an excessive number of remote calls being made or messages being sent. For example, imagine an interface that exposes a separate method to change each address field. This approach would be efficient if the communication happens inside a single application – you only update those fields that changed. In an integration scenario sending six or seven messages to update an address would be a significant overhead plus we would have to deal with synchronizing the individual messages. Fine-grained interfaces also lead to tight coupling. If we change the address format, we have to define new message formats and change all other applications to send an additional message.

Coarse grained interfaces solve these issues. We send fewer messages and are therefore more efficient and less tightly coupled. However, interfaces that are too coarse can limit our flexibility. If Send Invoice and Change Address are combined into one external function, will we never need to change an address without sending a bill? So as always the best answer is the happy medium and depends on the specific trade-offs at work in the real-life scenario.

http://www.eaipatterns.com/Chapter1.html

[x]

REST není HTTP. Typické řešení je v těle jednoho POST requestu na speciální URL popsat v nějakém rozumném formátu víc GET požadavků (nebo jakýchkoli, nejen GET). Odpověď má formát ideálně stejný, nebo aspoň podobný.

[sigma]

Tak jsme to udělali, ale překvapilo mě, že to není nijak standardnizovaná nabo běžná věc - tedy že používané nástroje s něčím takovým zpravidla nepočítají. Že REST je určitá myšlenka, a není to striktně navázané na HTTP je mi jasné, ale když jsem k tomu hledal informace nabyl jsem dojmu že se to tak dnes v 95% případů používá, a ať serverové nebo klientské knihovny co deklarují "REST podporu" s ničím jiným moc nepočítají.

[Petr Tomášek]

REST je nadstavba nad HTTP.

[pavlix]

Citation needed.

[backinabag]

"REST je nadstavba nad HTTP."

– Petr Tomášek

[pavlix]

Ideální kandidát na reliable source.

[backinabag]

To jsou právě ty views o kterých jsem mluvil - složitější dotazy nd databází. Další typický příklad je dotazování many-to-many relationships.

[sigma]

Jenže ty views bych chápal tak, že si je předem musím předdefinovat, není to flexibilní. Mám v aplikaci řadu zdrojů, které na některých stránkách potřebuju samostatně, a pak mám jiné stránky, kde potřebuju načítat třeba 10-20 takových zdrojů zároveň, a to třeba podle uživatelského nastavení, nebo podle toho že designér frontendu řekne, že na "téhle stránce chci mít ještě X", nebo se třeba při každém přechodu na jinou stránku načítají znovu nějaké společné prvky. Prostě ten use-case tu je, a řešení je možnost zabalit do jednoho HTTP requestu víc REST requestů. Což není problém, jak tu další komentující navrhují, tak jsme to samozřejmě udělali, akorát běžné RESTové nástroje s tím nepočítají, a není na to žádný well-known standard, nebo jsme nic takového nenašli, a museli jsme si použité nástroje přiohýbat. Což mě překvapilo.

[backinabag]

Ty views by mohly být i libovolně parametrizovatelné, to co jste udělali je v podstatě view (ale jenom pokud to nemůže změnit stav na serveru).

[sigma]

Neřekl bych view, ale spíš REST MultiCall, zapouzdření víc REST GET požadavků do jednoho HTTP požadavku. I když my jsme nakonec dokonvergovali k tomu, že to není tak úplně REST, ale spíš víc RPC. Pro danou aplikaci se to nakonec hodilo víc, a lépe se s tím pracuje. Abstrakce "chci zavolat paralelně tady těch 10 funkcí, které mi vrátí nějaká data" se nakonec ukázala lepší, i když v některých místech byl zas lepší REST přístup.

[backinabag]

Osobně mi přijde ideální kombinovat REST i RPC, s tím že RPC jenom tam kde to je nezbytně nutné (složitější změny stavu serveru nebo např. odeslání mailu).

To co děláte se dá chápat i jako view složené z jiných view. (View definuju jako jakékoliv mapování stavu serveru na nějaký JSON.)

[backinabag]

Ten multicall by šel řešit přidáním RPC volání do toho API (např. POST /rpc/multicall).

[Josef Kufner]

Můžeš udělat GET nad kolekcí (URI o patro výš) a nechat si tak vrátit všecky entity v ní, nebo je nechat nějak profiltrovat (parametry GETu).

Pokud chceš více dotazů v jednom spojení, použij keep-alive.

[sigma]

Jde o získání různých typů entit, ne nějak vyfiltrované kolekce. Např. mám stránku s detailem nějaké entity, a zároveň potřebuju načíst třeba 10 různých typů reportů (taky entita) příslušných k té entitě. Krom toho se tyhle reporty používají porůznu jinde v aplikaci samostatně, ale někdy jich prostě potřebuju víc najednou. Dělat pro ně jen kvůli tomu "kolekci", nedává moc smysl. Nebo si příště někdo vymyslí, že chce udělat stránku se srovnáním 3 entit a jejich nějakých reportů nebo jiných souvisejících dat, a zas bych musel vymýšlet extra "kolekci". Není to tenhle případ. Nebo viz můj komentář kousek výše (načítání entity která je potřeba pro všechny stránky v aplikaci vždy zároveň s dalšími, které jsou zobrazené na konkrétní stránce). Bavíme o příkladu webové aplikace čistě v JS, ale obecně vlastně jakákoliv thin client aplikace.

Keep-alive je jasná věc, ale ty požadavky se vyřizují sériově - tj. třeba 20 × 200 ms roundtrip (když se aplikace používá z celého světa, vždycky odněkud bude) = latence 4 sekundy, neúnosné a zbytečné.

[xkucf03]

To je trochu dilema – ono když se ta data používají na různých stránkách, tak se hodí načítat je z mezipaměti prohlížeče – v ideálním případě se ani nemusí posílat HTTP požadavek, protože data v mezipaměti jsou ještě dostatečně čerstvá. Když ale seskupíš nějaký složitější dotaz a více odpovědí, tak tohle použít už nejde – tady se hodí to mít rozsekané na co nejmenší části. Pokud tedy jsi schopný říct: po dobu dalších X minut/hodin/dní se data nebudou měnit. Jinak je potřeba poslat alespoň HTTP požadavek a odpověď 304 Not Modified (bez dat).

Taky se tu ukazuje nevhodnost HTTP protokolu pro tvorbu aplikací – efektivní by byla obousměrná komunikace, aby i server mohl posílat události klientům (např. „data se změnila, překresli si tuhle část stránky“). Tohle se tam muselo dobastlit přes Comet nebo WebSockety.

[sigma]

Cache v prohlížeči byla při zvažování řešení braná jako plus pro REST-like API. V dané aplikaci říct "po dobu X minut" téměř nikde nejde, takže by se dalo využít tak té HTTP 304. No a pořád tam máme ten problém s latencí a větším počtem requestů.

Pojmenoval bych to tak, že "REST over HTTP" jak se běžně používá, je na HTTP navázáno hodně těsně - počítá se s využitím HTTP metod, cachování a tak. Vypadá to dobře, ale podle mě to je dost omezující. Když jsme došli k potřebě zapouzdřit do jednoho HTTP requestu víc REST requestů, dávalo najednou smysl dělat to trochu jinak. Navíc v některých případech může server optimalizovat získávání zdrojů, pokud ví, že je klient chce "najednou".

Tyhle věci tam jinak máme vyřešené. Když má aplikace nějaká data buď v paměti - je to single page app, nebo v Local Storage, může poslat spolu s požadavkem verzi/hash (vlastně něco jako Etag) a server může vrátit Not-Modified.

Další level jsou pak ty notifikace o změnách ze strany serveru. Dnes není problém použít WebSockets, ale je to pak dost komplexní problém. Server musí pro každého připojeného klienta mít mnohem větší povědomí o jeho stavu - o tom, jaká data ho "zajímají" a jaká už třeba ne. Záleží na konkrétní aplikaci, jaký by tohle mělo přínos. A taky záleží jaké má člověk k dispozici programátory, aby s takovou změnou paradigmatu byli schopni pracovat.

[backinabag]

Taky se tu ukazuje nevhodnost HTTP protokolu pro tvorbu aplikací – efektivní by byla obousměrná komunikace, aby i server mohl posílat události klientům (např. „data se změnila, překresli si tuhle část stránky“). Tohle se tam muselo dobastlit přes Comet nebo WebSockety.

Tohle mi přijde jako hodně zajímavý problém, pokud bych někdy dělal nějaký web, zkusil bych to navrhnout tak, aby se jakýkoliv změna stavu serveru okamžitě pushla klientovi. Takže pokud bych dal upvote nějakému blogu, tak by se to okamžitě projevilo u všech kdo by měli ten blog otevřený.

[sigma]

Tohle vypadá zajímavě: https://www.firebase.com/

[xkucf03]

Je nějaký standardizovaný způsob jak říct, zda „GET nad kolekcí“ má vrátit jen seznam entit nebo přímo ty entity (včetně třeba dalších vnořených dat)?

[backinabag]

Uvažovali jste o tom, že by šlo z té JS aplikace dělat přímo databázové dotazy?

[sigma]

No, zvažovali jsme všechno možné. Tohle by mělo dost ale: v databázi by se musela řešit uživatelská oprávnění; na řadu věcí co teď řeší API server by se musely použít databázové procedury; řada věcí načtených z DB se na API serveru ukládá do cache; a pak obecně nepovažuju za rozumné nechávat nedůvěryhodného klienta pouštět libovolné DB dotazy... možná by to pro nějakou aplikaci dávalo smysl, ale u nás ne.

[xkucf03]

Tady vlastně jde o to, kde udělat tu hranici mezi vrstvami. V zásadě tam jsou tři:

• datová
• obchodní (byznys) logika
• prezentační

A otázka je, co dát na klienta a co na server, kde to rozdělit. Datová musí být na serveru a minimálně část prezentační na klientovi. S tím zbytkem se dá celkem dost hýbat.

Ze serveru můžeš udělat takřka čisté úložiště dat, budeš na něm řešit jen minimum logiky (např. aby si uživatelé navzájem nepřepisovali nebo nekradli data – uživatelská oprávnění) a většina bude na klientovi. Pak potřebuješ silný jazyk/API pro dotazování a úpravy dat – tzn. SQL nebo něco podobného a budeš ho volat z klienta.

Nebo bude hodně logiky na serveru a pak ti stačí jednoduché API – pár procedur, které se volají z klienta – ten už výsledky jen naformátuje a zobrazí.

REST je něco mezi tím – předpokládá se více logiky na klientovi, ale zase tu chybí silný dotazovací jazyk, nástroj pro hromadné aktualizace záznamů, agregační funkce atd.

obecně nepovažuju za rozumné nechávat nedůvěryhodného klienta pouštět libovolné DB dotazy

V jedné své aplikaci to tak mám, dokonce je veřejně přístupná Ale pro běžné weby to není, spíš na intranet. Dá se sice omezit množství dat a časový limit pro vykonání dotazu (správě nastavená databázová oprávnění jsou samozřejmost), ale i tak je to trochu risk. Lepší by v takovém případě bylo, vytvořit si vlastní dotazovací jazyk (pravděpodobně podmnožinu SQL) a ten na serveru parsovat, zkontrolovat a pak teprve přeložit na SQL dotaz a poslat do databáze.

[sarimak]

Jen pozor, u cisteho uloziste dat se muze stat, ze bude potreba z uloziste na klienta provest neco jako SELECT * FROM a az na klientovi se bude filtrovat pres WHERE. Coz nebude skalovat.

U filtrovani dat na serveru jeste pred stazenim zas muze snadno dojit k tomu, ze je zapotrebi pouzit tak komplikovaneho dotazovaciho jazyka, ze se kod stane neprehledny. Dotazovaci jazyky navic muzou mit vykonove problemy, ktere jsou resitelne jen obchazenim dotazovaci vrstvy (napr. primym SQL misto ORM-mapperu). A to je cesta do pekel.

O necem podobnem pise M.Fowler na http://www.martinfowler.com/bliki/AnemicDomainModel.html

[backinabag]

Trochu jsem upravil to jak chápu REST, už se to blíží finální verzi :)

Server má nějaký stav. REST API je množina pohledů na ten stav. Pohled lze poloformálně definovat jako pure function, která má jediný argument – stav serveru – a vrací nějaká data, obvykle JSON. Každý pohled má nějakou URL a mohou na něm být definovány metody jako GET, POST, PUT, DELETE atd. Metoda POST je použitelná pouze pro speciální typ pohledu - kolekce.

Jak by se resil slozitejsi problem jako presun penez z uctu A na ucet B? Napriklad pomoci pohledu /stavy_dvou_uctu?prvni=honza&druhy=pepa. Klient by nejdrive zavolal GET a ziskal by {"hozna": 10, "pepa": 10}. Potom by zavolal PUT s daty {"hozna": 5, "pepa": 15}.

Je mozne, ze okamzite po tom, co jsem zavolal GET nekdo ten pohled zmenil – to by bylo osetreno pomoci standardnich HTTP hlavicek ETag a If-Match.

[podlesh]

Přesun peněz mezi účty by IMCO měla být samostatná entita, protože bude určitě nutné ho později dohledat a vypsat (možná i stornovat). Navíc bude obsahovat víc údajů, typicky kdo ten přesun zadal, kdy a jak se autorizoval.... A to zanedbávám že v reálné bance nemusí být převod peněz operace provedená okamžitě a v zanedbatelném čase.

Takže mi z toho vychází tradiční POST který vrátí URI na nově vytvořený prevod. Případně PUT, pokud se dá URI vytvořit jen tak z ničeho.

[backinabag]

Souhlasím, to bylo jenom na ukázku úpravy několika řádků v databázi v transakci.

[xkucf03]

Obávám se, že REST tohle není schopný vyřešit. Ostatně „nejlepší REST API je SQL“ někdy se o tom chci rozepsat trochu víc do blogu.

Ono je sice hezké říct, že máme nějaké „zdroje“ a ty se nacházejí na nějakých hezkých URL, ale nestačí to ani na základní případy užití. Chybí standardní dotazovací jazyk – musíš něco našmudlat do GET parametrů, ale každý to bude dělat jinak, chybí standardizovaný zápis dotazů jako: vytáhni mi entity typu X u kterých atribut A1 je 5 a atribut A2 je stejný jako atribut A3. Stejně tak chybí agregační funkce nebo standardní možnost částečné aktualizace entity – např. odmaž (vynuluj) u určitých entit atribut A1 nebo nastav u těchto entit atribut A1 na max(A2, A3+5).

Další zajímavá technologie je LDAP:

• má standardní dotazovací jazyk (ne tak silný jako SQL, ale i tak poměrně dobrý)
• výsledky se dají ukládat do mezipaměti, databáze se dají replikovat
• databáze jsou optimalizované pro čtení
• standardní formát pro reprezentaci strukturovaných dat
• bohatý systém datových typů
• vícenásobná dědičnost
• binární úsporný protokol

[chrono]

O API bolo napísaných kopec zaujímavých článkov a medzi najčastejšie spomínané odporúčania patrí to, že API má poskytovať to, čo používatelia naozaj potrebujú (a nie univerzálne a/alebo zbytočne komplikované veci, ktoré nebude potrebovať/používať takmer nikto).

[xkucf03]

Tenhle přístup znamená použít RCP a implementovat v něm právě ty metody/procedury, které budou potřeba.

[backinabag]

Záleží na definici RESTu, pokud se bere tahle, tak s většinou transakcí by neměl být problém. Když by to nešlo, tak bych to řešil přidáním RPC funkce, na kombinaci RESTu a RPC v jednom API nevidím nic špatného :)

SQL jako API by nemusel být špatný nápad. Těžko říct, jak složitý by bylo řešit zabezpečení a validaci.

Replikace u LDAP - umí to i oboustrannou synchronizaci?

[David Jaša]

Jak by se resil slozitejsi problem jako presun penez z uctu A na ucet B? Napriklad pomoci pohledu /stavy_dvou_uctu?prvni=honza&druhy=pepa. Klient by nejdrive zavolal GET a ziskal by {"hozna": 10, "pepa": 10}. Potom by zavolal PUT s daty {"hozna": 5, "pepa": 15}.

Proč ne POST na /ucet/<pepovo_ID>/prevod {"prijemce": "honza"}? V tvém přístupu by stejně kód na serveru musel kontrolovat, jestli sedí součet, a pak teprve provést transakci, tak proč dávat klientům prostor pro chyby? Jinak PUT by mě seděl třeba na změnu trvalého bydliště, ale ne na pohyby na účtě, ty se dějí na základě nějaké operace, proto by se měla volat ta operace a v jejím rámci by mělo dojít k pohybu.

[backinabag]

Tohle bylo spíš na ukázku:

• atypického view, do kterého jde i zapisovat
• úpravy více řádků v transakci

V reálném světě bych transakce řešil asi PUTem nebo POSTem do /transactions nebo přes RPC.

Pokud myslíš POST na /ucet/[pepovo_ID]/prevod (ne tedy do kolekce prevody), tak to je RPC, ne REST. (Pokud to je RPC záměrně, tak bych na to použil neRESTovou URL typu /call/transfer_money.)

To /stavy_dvou_uctu právě že není operace – je to resource (= podmnožina stavu serveru = pohled na stav serveru). Je to v principu to samé jako změna bydliště.

[xkucf03]

Zrovna tohle je špatný příklad – příkaz k převodu peněz je sám o sobě záznamem (zdrojem) → vytváříš tedy tento záznam, ten pak projde nějakým procesem a teprve v důsledku toho se změní hodnoty v jiných záznamech (stavy účtů). REST tu celkem dobře jde použít.

Tímhle způsobem se dá rozsekat skoro všechno – POST/PUT kterým zadáš požadavek a pak si někde jinde přes GET vyzvedneš odpověď. Takhle se na REST dá napasovat prakticky cokoli, ale mnohdy to není moc elegantní a nedává to moc velký smysl (lépe se hodí procedury – lépe vystihují povahu řešené úlohy).