Endpoints that bind to Records
Only Data Consuming Endpoints have Records, thereby only these endpoints have Record fields.
These are examples of Read/Write Data Consuming Endpoints:
Service Endpoints are not bound to a record, thereby its actions are bound to a service and do not have fields:
Mapping Record Fields within Endpoint
Data Consuming Endpoints defines access to fields of the Records it is bound to be available by its actions:
- Default Fields — What fields provided default in generate result, even if no specific fields are requested.
- Extra Fields — What fields are not included in request and must be specifically requested to be included within result.
- Aggregate Fields — What fields when requested in result will provide an aggregate evaluation over multiple datasets.
- Not Included Fields — If so choose by the Endpoint, it can hide these fields so that they are not accessible to be included in result.
- Reference Fields — These field even though it can be included within its results, but if there is an Related Endpoint that this field identifies, it would be better to reference information via its associated Related Endpoint’s property_name.field_name.
Below shows mapping record fields by Endpoint defining availability to its Actions.
Records have a set of fields that provide access to its underlying data. For example, the following listing are the fields definingRecordsModelAdvertisers, which defines the criteria for accessing this record by the Endpoint /account/ it is bound to.
To be talked about later, it is especially important to note that the model data parameter of Action save.json must be compliant to the Record fields for its dataset to be successfully received and then created. Record fields’ constraints include if they are are required, property type, and value choice limitation.
Those fields marked as required are expected to values when creating a dataset within Record called by via Action save.json.