KOSapi

h1. Vyhledávání

Komplexní podpora dotazování tvoří jednu ze základních funkcionalit databází. Oproti tomu většina běžných RESTových služeb nenabízí moc silné prostředky pro dotazování a omezuje se pouze na tzv. _implicitní_, příp. fulltextové vyhledávání. Ovšem mají-li webové služby IS(informačního systému) sloužit aplikacím jako {{fn(přímý, To znamená, že aplikace si nebudou uchovávat lokální kopii celé ani části databáze IS (cache se tím nevylučuje), ale budou je přímo získávat z webové služby.)}} zdroj dat, tak je komplexnější podpora alespoň vyhledávání prakticky nezbytná.

h2. Implicitní vyhledávání

KOSapi poskytuje sadu zdrojů, které v podstatě umožňují přirozené sestavení dotazu jen pomocí URL. Mezi ně patří například ... TODO

Jejich limity jsou zjevné - pouze omezená sada předdefinovaných zdrojů a nemožnost vyhledávat podle rozličných parametrů, natožpak jejich kombinace.

h2. Dotazovací jazyky pro webové služby

Existují dva standardy (alespoň co jsem našel), které definují jazyk pro dotazování nad RESTovými webovými službami. Prvním je obsáhlý "Open Data Protocol":http://www.odata.org, který mimo jiné zahrnuje komplexní podporu pro dotazování. Využití OData pro KOSapi jsem z několika důvodů zavrhl a vzhledem k tomu, že podpora vyhledávání je přímo jeho součástí, tak mi její _samostatné_ využití nepřišlo přínosné.

Druhým je návrh IETF(Internet Engineering Task Force) standardu "Feed Item Query Language":http://tools.ietf.org/html/draft-nottingham-atompub-fiql-00, který definuje „URI-friendly“ syntaxi pro dotazování (správně spíš _vyhledávání_) nad Atom Feeds. Umožňuje vyhledávat záznamy Atom Entry podle jejich _metadat_. Jedná se pouze o návrh („draft“) z roku 2007, kterýžto nakonec nebyl standardizován, nicméně už jej implementuje např. framework "Apache CXF":http://cxf.apache.org. Syntaxe FIQL(Feed Item Query Language) je výhodná svým prvoplánovým určením pro zápis v URI(Uniform Resource Identifier), díky čemuž ji není potřeba zakódovávat. To ovšem můžeš být zároveň nevýhodou, neb kvůli tomu není příliš intuitivní. Jelikož jsem si stejně musel napsat vlastní parser, rozhodl jsem se tuto syntaxi využít a rozšířit ji ještě o alternativní zápis ala Java. Tím vznikl RESTful Resource Query Language (RSQL).

h2. RSQL

RSQL(RESTful Resource Query Language) umožňuje vyhledávat záznamy (Atom Entry) podle jejich strukturovaných elementů v Atom Content. Tím se také odlišuje od FIQL(Feed Item Query Language), který je naopak určený pouze pro vyhledávání záznamů podle jejich _metadat_ v Atom Entry. Všechny zdroje KOSapi jsou koncipované tak, že Atom elementy využívají pouze pro metadata a vlastní data z KOSu jsou obsažená v Atom Content ve strukturované podobě (závisí na _Content-Type_, výchozí je XML(Extensible Markup Language)). RSQL(RESTful Resource Query Language) dotazy se v KOSapi překládají na SQL(Structured Query Language) dotazy do KOSu.

Jak již bylo napsáno, RSQL(RESTful Resource Query Language) umožňuje dva způsoby zápisu - „URI-friendly“ syntaxi FIQL(Feed Item Query Language) a alternativní syntaxi inspirovanou Javou. FIQL(Feed Item Query Language) lze v URL použít přímo, kdežto alternativní je nutné zakódovat podle "RFC 1738":http://www.ietf.org/rfc/rfc1738.txt (pozn. webové prohlížeče a zřejmě i většina knihoven dělá automaticky).

h3. Struktura výrazu

Výraz se skládá z jednoho či více _porovnání_, které se spojují logickými (Booleovskými) operátory.

* _výraz_ = [ "(" ] ( _podmínka_ / _výraz_ ) [ _logický-operátor_ ( _podmínka_ / _výraz_ ) ] [ ")" ]

* _podmínka_ = _selektor_ _operátor-porovnání_ _argument_

* _logický-operátor_ = "@;@" / "@&@" / "@ and @" / "@,@" / "@|@" / "@ or @"

* _operátor-porovnání_ = ( "@==@" / "@=@" / "@!=@" / "@=lt=@" / "@<@" / "@=le=@" / "@<=@" / "@=gt=@" / "@>@" / "@=ge=@" / "@>=@" )

* _selektor_ = @[a-zA-Z_]([a-zA-Z_0-9\-])*@

* _argument_ = ( "@'@" @[^']+@ "@'@" / "@"@" @[^"]+@ "@"@" )

h3. Logické operátory

|_. Název	|_. FIQL		|_. Alternativní		|_. SQL-like		|

| AND		| @;@		| @&@				| "@ and @"		|

| OR		| @,@		| <code>|</code>	| "@ or @"		|

Operátor AND má standardně přednost, tj. všechny operátory OR se vyhodnocují až po něm. Toto chování samozřejmě lze změnit pomocí uzávorkování výrazů.

h3. Operátory porovnání

|_. Název			|_. FIQL		|_. Alternativní		|_. Platné datové typy							|

| rovná se			| @==@		| @=@				| textový řetězec, číslo, datum, výčtový typ, XLink	|

| nerovná se		        | @!=@		| @!=@				| textový řetězec, číslo, datum, výčtový typ, XLink	|

| menší než			| @=lt=@	| @<@				| číslo, datum									|

| menší nebo rovno	| @=le=@	| @<=@				| číslo, datum									|	

| větší než			| @=gt=@	| @>@				| číslo, datum									|

| větší nebo rovno	| @=ge=@	| @>=@				| číslo, datum									|

Porovnávání textových řetězců nezohledňuje velikost písmen (je _case insensitive_). Pokud je URL parametr [[URLParameters#multilang|multilang]] nastaven na @true@, tak zohledňuje texty v obou jazycích. V opačném případě vyhledává pouze ve zvoleném jazyce (podle Accept-Language, nebo  [[URLParameters#lang|lang]]).

Při porovnávání řetězců lze využít i _divoké karty_ a hledat pomocí nich i jen podle části řetězce. Způsob zápisu je stejný jako v SQL _LIKE_, pouze s tím rozdílem, že místo @%@ se zde používá @*@. Například podmínce @name='prog*'@ vyhoví všechny předměty, jejichž název začíná na „prog“ (opět bez ohledu na velikost písmen).

V případě elementů, které reprezentují výčtový typ, je nutné jako argument uvádět _výčtový název_ (enum), nikoli jeho lokalizovaný popis.

Argumentem pro XLink je identifikátor záznamu použitý v URI(Uniform Resource Identifier), což většinou bývá kód nebo ID.

h3. Parametry

RSQL(RESTful Resource Query Language) výraz se zapisuje do URL parametru [[URLParameters#query|query]] a je možné ho efektivně kombinovat s parametry [[URLParameters#startIndex|startIndex]], [[URLParameters#maxResults|maxResults]] a [[URLParameters#orderBy|orderBy]].

h3. Příklady

TODO

h3. Pár slov k implementaci

TODO