RFC 5789 najdete na této adrese.
Stávající metody
Když webový klient posílá serveru svůj požadavek, jednou z klíčových informací v něm obsažených je metoda. Říká, jaký typ operace klient vlastně po serveru požaduje. Drtivá většina komunikace probíhá metodou GET, která by se dala přeložit „pošli mi stránku X“.
Zajímavější je situace, pokud je třeba předat nějaké údaje ve směru od klienta na server. I zde se dá použít GET, ale pak jsou data omezena délkou lokátoru, který nesmí překročit 255 znaků. Je proto použitelná jen na krátké texty – hledaný řetězec či vyplněný malý formulář.
Pokud je předávaných dat více (například chcete vložit fotografii ke zpracování do online editoru nebo přidat stránku do blogu), má klient v zásadě dvě možnosti: metody POST a PUT. Obě přenášejí data libovolné délky v těle dotazu a kromě nich nesou i lokátor identifikující zdroj v rámci serveru. Liší se ovšem jejich význam.
Dotaz metodou POST v podstatě znamená „volám obslužný program určený lokátorem a předávám mu ke zpracování data ze svého těla“. Lokátor musí vést k existujícímu zdroji, jímž zpravidla bývá nějaký skript. Jeho činnost je zcela libovolná. Data může využít k dotazování v databázi, uložení do souboru, vytvoření grafu, cokoli si vzpomenete…
Naproti tomu PUT říká serveru „posílám v těle nový obsah pro zdroj určený lokátorem“. Ten zatím nemusí vůbec existovat. V takovém případě jej server vytvoří. Jestliže zdroj určený lokátorem již existuje, bude nahrazen. Data oficiálně nemají žádnou strukturu. Představují obsah, který by nyní měl server nabízet, kdykoli někdo požádá o daný lokátor.
PUT je ve srovnání s POST omezenější. Je jednoúčelový a může předat jen jeden datový objekt. Zato (alespoň teoreticky) nevyžaduje obslužný program – ukládání poskytnutých dat může v zásadě zajistit přímo webový server. Často je ale i PUT zpracováván samostatným programem určeným konfigurací serveru.
Souputníkem PUT je DELETE, jehož prostřednictvím lze určitý zdroj ze serveru odstranit. Tato dvojice je součástí HTTP od verze 1.1, tedy od roku 1997. V principu umožňuje vše potřebné – uložit datový soubor na serveru, přepsat jej novou verzí či odstranit. Ovšem pokud se má provést malá změna ve velkém souboru, bude PUT velmi neefektivní. Musí se přenést kompletní nová verze dat.
Novinka – PATCH
A právě toto dává prostor pro nově definovanou metodu PATCH, kterou definuje RFC 5789. Umožní poslat jen rozdílový dokument – popis změn, které je třeba provést s verzí, již server aktuálně nabízí. To může být doslova pár bajtů.
Změny dat ve vysoce distribuovaném prostředí jako je web vždy představují riziko. Typická situace: Klient načetl ze serveru aktuální data, připravil pro ně změny a odeslal je metodou PATCH. Mezitím ovšem jiný klient data upravil, takže změny v odeslaném požadavku mohou být neproveditelné nebo – v horším případě – napáchat víc škody než užitku.
Specifikace se tomu brání dvěma způsoby. Zásadní je požadavek, že změny nesené jedním požadavkem PATCH musí být atomické. Server je musí provést najednou, a to buď všechny, nebo žádnou. Během provádění úprav z jednoho dotazu nesmí ani poslat rozpracovaná a částečně změněná data komukoli jinému. Pokud by například tou dobou dorazil GET od jiného klienta, musí počkat na dokončení změn a dostane až kompletně upravenou verzi.
Druhou linií obrany je používání HTTP hlavičky If-Match. Tou lze podmínit, že daný dotaz má smysl, jen pokud aktuální obsah souboru souhlasí s verzí uvedenou v této hlavičce. Ne každý změnový požadavek bude takto citlivý. Jestliže například má jen přidat na konec logu nové záznamy, nijak mu nevadí, že těsně před ním něco připsal i jiný klient. Pokud se ale bavíme třeba o úpravě dat v rezervačním systému, měla by proběhnout jen nad původní verzí, jinak by mohlo být stejné sedadlo prodáno několikrát. V takovém případě je If-Match zcela na místě. Poznamenejme, že tato hlavička je opět již léta součástí definice HTTP/1.1, metoda PATCH jen doporučuje její použití v oprávněných případech.
Klíčovou otázkou samozřejmě je, jak popsat změny. Odpověď podle RFC 5789 zní „uvidíme“ – nechává tuto věc zcela otevřenou. Počítá s existencí různých změnových jazyků, protože různé typy dat budou vyžadovat odlišný přístup. Hlavička Content-Type v dotazu určí, který z nich byl v daném případě použit. Pro odpovědi serveru zavádí novou hlavičku Accept-Patch, jejímž obsahem budou typy změnových jazyků podporované daným serverem.
Otevřenost vůči různým způsobům popisu prováděných změn je samozřejmě sympatická a umožňuje budoucí rozvoj, bývá ale zvykem definovat v podobných případech alespoň jednoduchý základ. Očekával bych, že samotná specifikace HTTP PATCH nebo doprovodné RFC zavedou minimalistický změnový formát, který poskytne alespoň něco pro začátek. Nestalo se tak.
Existoval například návrh XCAP patch operations zaměřený na úpravy XML dokumentů. U nich je taková snaha rozhodně oprávněná – XML je jazyk upovídaný, datový soubor snadno nabobtná a poslat místo kompletní nové verze jen popis změn může být velmi přínosné. Zároveň zde existují nemalé zkušenosti s orientací v datech.
Jari Urpalainen navrhl velmi jednoduchý jazyk zahrnující jen tři příkazy ( <add>, <replace> a <remove>) kombinované se silně omezenou podmnožinou XPath pro identifikaci konkrétních uzlů v měněném XML dokumentu. Návrh je ovšem pět let starý a nikdy se nedočkal žádného vývoje.
HTTP PATCH tedy přichází jako prázdná skořápka, kterou do budoucna možná naplní něco dobrého. Jestli k tomu opravdu dojde a jestli bude zájem tuto cestu rozvíjet, je jiná otázka. Již delší dobu existují nástroje pro práci s daty uloženými na webovém serveru, jako je WebDAV. Ten je sice mnohem složitější a věnuje se zejména správě vlastností uložených dat, ovšem na druhé straně je výrazně starší a může se pochlubit řadou implementací.
Nová HTTP metoda nabízí zejména jednoduchost a jednoduchá řešení mají v Internetu skvělou tradici. Zalíbení by v ní mohly najít zejména aplikace postavené na principu REST, jejichž součástky pěkně doplňuje. Z tohoto směru by snad také mohly přijít návrhy na jazyky pro popis změn. Dokud se tak nestane, implementací se asi těžko dočkáme.
