Omluva
.
- Dlouho jsem přemýšlel, jak postavit tuto přednášku. Technické detaily si můžete najít sami (a budeme je publikovat). Chci proto mluvit o motivacích, přínosech a výhodách tohoto řešení)
- Budu mluvit moc o WinStromu: chceme ukázat tok našich myšlenek, naše požadavky a ukázat jak jsme to udělali
- Vymyslím si případně jiné jméno
- O WinStromu se snažíme mezi vývojáři komunikovat: Proč PostgreSQL, Pod pokličkou, REST API
Proč API?
.
- Kdo jste řešili eshop, plánovací systém, museli jste řešit i sklady, fakturaci, platby, DPH, ...
- Objednávky a sklady: eshop, optimalizace, ...
- Platby: import z banky, úhrady, částečné úhrady, zápočty faktur, ...
- DPH: generování daňového přiznání, ...
- Synchronní: potřebujete mít možnost provést rychle nějakou operaci
- vytvořit fakturu
- poslat ji e-mailem nebo nechat stáhnout uživatelem
- zobrazit seznam neuhrazených faktur
- Asynchronní: potřebujete kvůli např. výkonnosti či spolehlivosti (a nebo máte více dat) držet duplicitně u sebe
- výměna dat
- eshop (katalog, množství na skladě, objednávky)
- např. i kvůli výkonnu
- Navrhovali jsme rozhraní tak, aby se líbilo mně (a Honzovi Novotnému a dalším lidem)
- Kdybych ho měl před lety
- datový model účetnictví je hrozně složitý (částečné úhrady, zápočty, zálohové doklady, ...)
- datový model musí být zjednoduššený, srozumitelný a jasný
- zdokumentovaný
- stabilní
- Pravidlo: čemu nerozumíš, to nepotřebuješ (číslo faktury, příjemce, částka, proto typ dokladu)
Požadavky na API
.
- umožnit síťový přístup k rozhraní (server, lokální instalace),
- jeho funkčnost napříč podporovanými operačními systémy (Windows, Linux a Mac OS X),
- možnost volání z různých programovacích jazyků.
- základem bude XML, které:
- Když to schrnu, tak toto API je primárně dokumentově orientované: faktura, objednávka
- umožní dávkový přenos dat (import a export všech dat - např. do stejné firmy)
- výměna dat mezi partnery (ceník)
- aktualizace záznamů
- čtení záznamů
- HTTP je takové univerzální API, jako příkazová řádka
Co používá konkurence
.
- COM/DCOM/Active X/OLE: jen Windows
- Pouštění z příkazové řádky: zajímvé řešení, ale není síťové, vyžaduje instalaci
- RMI: jen z Javy
- WebServices (SOAP): Zajímavé. Na můj vkus není jednoduché. SOA is Dead, REST is the future.
- REST API
Proč REST API
.
- Velmi jednoduché
- Mohu odkázat přímo na data
- Mohu ze všech jazyků
- Ladící nástroj je prohlížeč
- Rovnou jsme získali i webový přístup
Proč REST API: Založení nové faktury
Struktura URL
.
- POST nepoužíváme, kvůli CSRF. Používáme je jen pro uživatelský přístup
Výstupní formáty
.
- automatická detekce formátu
- XML a JSON: XMLStreamWriter a nadstavba kvůli polím
- Možnost exportu do kalendáře (a díky filtraci umíme třeba export )
- Volba je dle URL (.xml) nebo pomocí accept
- Prohlížeče posílají Accept: */* nebo Accept: application/xml a myslí XHTML
Identifikace objektů
.
- Identifikátor lze použít jako součást URL, jako filtr, tak i jako součást XML dokumentu
- URL jsou stabilní, lze tedy odkazovat
- Není nutné mít extra mapování mezi systémy
- Kvůli duplicitnímu obsahu dochází k přesměrování
Aktualizace a validace
.
- Popovídat o validaci a ExtJS
Zvyklosti v REST API
.
- Máme přímou podporu pro ExtJS
- ExtJS používá pro řazení něco, Ruby něco jiného
- my řešíme filtraci jinak než Ruby
, - Ruby má faktura a fakturas
- mode=ruby
Stabilní rozhraní
.
- Vyplňujte jen to, čemu rozumíte.
Bezpečnost
.
- Potřebujeme dát přístup pro Google Kalendář