De querystring-parametrar som kan anges vid GET-anrop är följande:
  • filter - Filtrering
  • order - Sortering
  • limit och offset - Paging
  • include - Inkludera relaterade objekt


När filtrering och sortering görs på fält som ingår i en underliggande datatyp, ska det anges med följande syntax:
/api/fi2leasecontract/?filter={fält}.{fält}
När filtrering och sortering görs på fält som ingår i en underliggande datatyp, ska det anges på följande vis:
/api/fi2leasecontract/?filter=fi2lease_actor.fi2actor_partner_id
Filtrering och sortering kan inte göras direkt på det fält som innehåller underliggande datatyper. Exempelvis ska följande syntax ge felkod 2002:
/api/fi2leasecontract/?filter=fi2lease_actor

De fält som anges vid filtrering, sortering och vid inkludering av objekt ska skilja på stor och liten bokstav.
Detta innebär att anges följande filtrering:
/api/fi2leasecontract/?filter=fi2leasecontract_ID:'123'

Då ska felkod 2002 returneras på grund av felaktig indata eftersom _ID ska vara _id.
För att filtrera resultatet vid en läsning av en lista kan parametern filter användas.

Syntax:
GET /api/{fi2entitet}/?filter={filter condition}

{filter condition} = {Uttryck} ; {Uttryck} ; ...
{Uttryck} = {Fält} {Operand} {Värde}
{Värde} = 'värde'
Fält under aktuell fi2entitet anges direkt
{Fält} = {Fältnamn}

Filteruttryck kan även anges för relaterade entiteter. Då angivs entitetsnamnet med ett filter condition inom parantes.
{Uttryck} = {Relaterad entitet} ( {Uttryck} ; {Uttryck} ; ... )
Anges flera uttryck inom samma parantes, returneras objekt där det finns minst ett relaterat objekt som matchar samtliga uttryck i parantesen.
Relaterade entiteter måste inte vara inkluderade för att vara filtrerbara, och filteruttrycket påverkar inte vilka objekt som inkluderas.

Alla fält som stöds av API:et ska kunna användas som filter-fält. Även ska alla fält i relaterade entiteter som stöds av API:et kunna användas som filter-fält.
Giltiga fält finns listade under API Datamodell och respektive entitet

När filtrering görs på upprepningsbara fält i underliggande datatyper, dvs om ett fältnamn i filteruttrycket matchar flera fält per fi2objekt, ska de objekt returneras där det för varje filteruttyck finns något underliggande objekt som matchar.

Värden ska omges av '

Ex: GET /api/fi2leasecontract/?filter=fi2leasecontract_id:'123'

Följande operander är tillåtna
Operand Beteckning Syntax Beteende
Lika med : Fält:Värde Evaluerar till sant om Fältets innehåll är lika med Värde
Större än > Fält>Värde Evaluerar till sant om Fältets innehåll är större än Värde
Större än eller lika >: Fält>:Värde Evaluerar till sant om Fältets innehåll är större än eller lika med Värde
Mindre än < Fält<Värde Evaluerar till sant om Fältets innehåll är mindre än Värde
Mindre än eller lika <: Fält<:Värde Evaluerar till sant om Fältets innehåll är mindre än eller lika med Värde
Finns i :( ) Fält:(Värde1, Värde2, ...) Evaluerar till sant om Fältets innehåll är lika med Värde1 eller Värde2 ...
Och ; Uttryck1;Uttryck2 Evaluerar till sant om Uttryck1 evaluerar till sant och Uttryck2 evaluerar till sant
Följande wildcard är tillåtet i värde i kombination med operanden "Lika med"
Wildcard Beteckning Syntax
Ord * Kan anges i början och/eller slutet av värdet
Ex: GET /api/fi2leasecontract/?filter=fi2leasecontract_id:'*123*'


För att underlätta implementering av filtreringen rekommenderas att i förlängning ta fram en EBNF grammatik som entydigt specificerar filtreringen. Utifrån den kan kod och parsningsträd genereras som underlättar hanteringen av filtervillkoren


För att sortera en lista med objekt används parametern order.

Syntax:
GET /api/{fi2entitet}/?order={order condition}

{order condition} = {+}{Fält},{+}{Fält},...

Ett minus-tecken (-) framför fältet anger att sortering görs i ordning från högsta till lägsta.
Om inget anges, så sorteras i ordning från lägsta till högsta.

Ex: GET /api/fi2leasecontract/?order=-fi2leasecontract_id

När sortering görs på upprepningsbara fält från lägsta till högsta, ska ett objekt sorteras efter det värde som är minst. Vid sortering från högsta till lägsta sorteras objektet efter det värde som är högst.



Vid läsning av en viss objekttyp kan det finnas intresse att inkludera relaterade object i resultatet. Då används parametern include.

Syntax:
GET /api/{fi2entitet}/?include={relaterad fi2entitet},{relaterad fi2entitet},...

Ex: GET /api/fi2leasecontract/?include=fi2partner



För att tillämpa paging, dvs dela upp lista i portioner, används parametrarna limit och offset.

Syntax:
GET /api/{fi2entitet}/?limit={limitvalue}&offset={offsetvalue}

Limit anger hur många objekt som ska hämtas och offset anger var man ska börja.
Vid kombination med include är det endast huvudobjekten som räknas mot gränsen.

Exempel:
För att hämta 10 objekt åt gången i åtföljande anrop, görs följande:
- GET /api/fi2leasecontract/?limit=10&offset=0
- GET /api/fi2leasecontract/?limit=10&offset=10
- GET /api/fi2leasecontract/?limit=10&offset=20
- Etc ...
Tillslut returneras en tom lista med objekt.

Setting-Limit-Default
Anger vilken limit som ska användas när ingen limit anges. GET-anrop som inte har en angiven limit ska alltså fungera som om Setting-Limit-Default hade angivits som limit. Anges limit har det högre prioritet än Setting-Limit-Default. Ifall Setting-Limit-Default används måste den skickas i headern vid inloggning.

Setting-Limit-Max
Anger vad högsta tillåtna limit är. Används det ska API:et inte tillåta anrop där limit har ett högre värde än Setting-Limit-Max, då ska istället felkod 2009 returneras. Även Setting-Limit-Max ska skickas i headern vid inloggning när det används.

Observera att både Setting-Limit-Default och Setting-Limit-Max är frivilliga att implementera.

Ett exempel på information som skulle kunna ges i headern vid inloggning:
Setting-Limit-Default:20
Setting-Limit-Max:100