ODABA HTTP server

The ODABA HTTP server is a mean of communication with an ODABA database via HTTP internet protocol. When starting the server, a data source definition has to be passed to the server via configuration or ini-file. Usually, the server runs as daemon (Linux) or as Windows service. In order to debug server functions, one may also execute the server as console program.

OHTTPServer ini-file port (console program)

OHTTPDaemon ini-file port (Linux daemon)

OHTTPWinServer ini-file port (Windows daemon)

The configuration or ini-file defines the data source. The port number defines the communication port.

The OHTTP server acts as a kind of database driver and should not be accessible directly via the internet. It is suggested to communicate with the internet via a back-end server. This allows performing required authentication, storing predefined queries or update procedures, which could be referenced by the application via simple URLs with a proper set of parameters e.t.c.

Examples provided in the document refer to the data model of the ODABA Sample database (see appended ODL definition).

The OHTTP server supports GET, POST, PUT, PATCH, DELETE and OSI POST requests. Since ODABA databases provide several extended database features, the semantic of POST, PATCH and PUT had to be changed slightly. Differences are described in documentation chapters for these request types. Operations supported by the server have to be defined explicitly in the configuration or ini-file passed to the server call.

Syntax elements used in different commands are described in detail in chapter Symbol references . Most syntax elements are JSON compatible.

The number of the communication port must be appended to each HTTP request:

• server:port

This allows running servers for different databases by using different port numbers.

The configuration (xml) or ini-file defines the data source for database access independent on the kind of server called. The section or element name for the data source definition must be OHTTPServer . More details about data source definitions and ini-files are available in ODABA documentation ( Data Source Definition ).

In order to allow HTTP operations, the option ALLOW has to be defined in the OHTTPServer section.

[OHTTPServer]

...

ALLOW= op_list

op_list - is s list of operations (request types) to be supported. One may define ALL or a list of supported operation names separates by semicolon: GET , PUT , PATCH , POST , DELETE and OSI . Option and operation names are not case sensitive. Spaces between names are not allowed.

In order to request authentication, the configuration or ini-file must contain an Authentication option in the OHTTPServer section:

[OHTTPServer]

...

Authentication= type [; function ]

type - is the authentication type. Currently, the only authentication type is basic or none (case insensitive). Passing an invalid authentication type will cause an error while starting the server.

function - is the name of an OSI function for checking user name and password. The default function name is Authenticate:

Authenticate(string user, string password)

In order to call another function, the function name may be appended after type separated by semicolon. When referring to a static class function, function must be defined as scoped name (e.g. Person::Login ). The function must receive user name and password as parameter.

The function is is called for application specific user and password checks. The authentication function with the default or passed name has to be defined in the resource database or OSI library directory.