Row element services
Use this URI to access and reference specific rows in ObjectServer tables.
The following methods are supported.
RowSerial
Every row in every table in the ObjectServer has an integer value that uniquely identifies that row in the table in which the row resides. When you use an HTTP GET request to fetch rows to the table collection services URI, the RowSerial value of each row is automatically returned as a column in the JSON row set document. The RowSerial value can be used to build a row element URI to that row, as the following example shows.
http://host:port/objectserver/restapi/database/table/rowserial/Where database is the name of the ObjectServer database, table is the name of the ObjectServer table, and rowserial is the unique row serial number of the row.
The RowSerial method supports the following HTTP methods: GET, PATCH, and DELETE.
Because RowSerial is an integer, it is efficient to for building URIs and evaluating ObjectServers. RowSerial URIs are valid only for the ObjectServer from which they were originally determined. Access to rows via RowSerial is the preferred method.
Key field
Every row in every table in the ObjectServer has a key field that uniquely identifies that row in the table in which it resides. It is therefore possible to reference a row by using the key field instead of the RowSerial value, as shown in the following example.
http://host:port/objectserver/restapi/database/table/kf/keyfield/Where database is the name of the ObjectServer database, table is the name of the ObjectServer table, and keyfield is the unique row serial number of the row.
The key field method supports the following HTTP methods: GET, PATCH, and DELETE.
Notes on key field construction
Wherever permissible, a key field URI is valid in any ObjectServer in environments in which the HTTP interface is enabled, so that you can build and use a common path to a row across multiple ObjectServers.
Key fields for rows that are valid across multiple ObjectServers differ, depending on the ObjectServer table in which they reside. For example, in the alerts.status table, the primary key is the Identifier column. Because the value of Identifier is not unique to a single event instance across multiple ObjectServers, it is not used to build the key field. Instead, the key field for rows in the alerts.status table is built from the values of the ServerSerial column and the ServerName column.
The following table shows how the key field is constructed for the alerts.status, alerts.journal, alerts.details tables, and for all other general tables in the ObjectServer.
| Table | Type | How the key field is constructed |
|---|---|---|
| alerts.status | Event | The ServerSerial field is combined with the
ServerName field and separated by a colon. The following example shows
how the fields are combined. |
| alerts.journal | Journal | The key field is defined by the KeyField column
of the journal table. Because journals are reserialized differently
in different ObjectServers, a journal key field is not valid across
multiple ObjectServers. The following example shows a sample KeyField. |
| alerts.details | Details | The key field is defined by the KeyField column
of the details table. The following example shows a sample KeyField. |
| All other general tables in the ObjectServer | General | The key field is the set of columns that make
up the primary key of the table. If the primary key of the table consists
of multiple keys, specify the key values in the same order as in the
table schema. Separate the key values with the sequence #KF#.The following example shows a sample key field in a table that has two primary columns, with the values ColValue01 and 654. The following example shows how this field is constructed after it is encoded for use in a URI The following example shows this key field in a URI. |