OData

OData jest traktowany jako pełnoprawny protokół, a nie jako HTTP, które trzeba samodzielnie ozdabiać: Restorm zna jego opcje systemowe, jego operacje oraz jego format wsadowy.

Kliknięcie prawym przyciskiem w drzewie ▸ Dodaj ▸ Żądanie OData.

Konfiguracja

Pole	Rola
URL	Punkt wejściowy usługi, wraz z zestawem encji
Wersja OData	v2, v3, v4 lub v4.01
Rodzaj operacji	entity-set, function, action lub batch
Nagłówki / Parametry	Tak jak w żądaniu HTTP

Opcje zapytania

Każda opcja systemowa ma własne pole:

$filter · $select · $top · $skip · $count · $expand · $orderby · $search · $format (json, xml, atom) · $apply (agregacja, v4.01).

Pole $filter korzysta z autouzupełniania zasilanego zaimportowanymi metadanymi: podpowiadane są nazwy właściwości oraz operatory.

Funkcje i akcje

Dla function i action dostępna jest lista typowanych parametrów operacji — nazwa, kwalifikowany typ CSDL, dopuszczalność wartości null, wskaźnik powiązania — a dla akcji dodatkowo dedykowana treść JSON.

Żądania $batch

Tryb batch zawiera listę podżądań, każde z własną metodą, adresem URL, nagłówkami, treścią oraz ewentualnie z własną grupą atomowości (change set). Dwie opcje:

• Format: multipart (domyślnie) lub json;
• Zezwalaj na żądania GET w change set: domyślnie wyłączone; włączenie tej opcji powoduje ostrzeżenie, ponieważ specyfikacja OData tego nie przewiduje.

Import metadanych

Wystarczy zaimportować dokument $metadata albo plik .edmx: Restorm tworzy jeden folder na zestaw encji wraz z jego żądaniami CRUD, a ponadto foldery Actions i Functions. Żądania są wstępnie wypełnione typem encji, właściwościami, właściwościami nawigacyjnymi oraz opcjami zapytania. Zob. Import OData.

Tryb serwera

Restorm potrafi hostować symulowaną usługę OData v4: wystarczy dostarczyć dokument metadanych CSDL (serwowany bez zmian) oraz dane dla poszczególnych zestawów encji. Opcje systemowe są stosowane do serwowanych danych. Zob. Symulowanie usługi OData.