admin
Child pages
  • ListSchemas
Skip to end of metadata
Go to start of metadata

Description

The ListSchemas API allows the Account Owner to retrieve a list of all the Schemas that were previously created.

 

In apstrata, Schemas are used to define the kind of data you expect to store for a certain business entity, along with the validation and security rules, in a declarative way. You can think of a Schema as a template for business entities. For example, you might want to have an employee entity in your application. You can define a schema for that entity, specifying that first name, last name, age, and employment date represent the data to be collected by default for each employee. For each of these employee attributes, you can associate validation and security rules. Hence, a Schema provides a uniform way of dealing with employees. Note that employee attributes that are not defined in the schema can still be persisted as part of an employee Document; however, no specific validation or security rules can be applied to them. Such fields or attributes are called dynamic fields.

Apstrata does not enforce the use of Schemas. Alternatively, you can always persist data without specifying a Schema. In this case, no security or validation rules can be applied at the level of the fields. Note that "schema-less" Documents are actually Documents with a default Schema, which gets created for each account upon registration. The default Schema is not exposed, and hence cannot be customized. The default Schema is totally based on dynamic fields, implying that no field-level security or validation rules can be applied. This "schema-less" mode is meant for prototyping and experimenting purposes. We fully recommend that business applications be built in a "schema-full" mode.

Please refer to Document Schema Definitions or Saved Query Schema Definition to showcase a schema example as well as the schema syntax (XSD) that you should use to create your schemas.

For specific details on schema creation, please check the SaveSchema API.

Specific Request Parameters

(Refer to Common Request Parameters)

Specific Response Elements

(Refer to Common Response Elements)

The following specific "result" element is a child of the common root element "response" and a sibling of the common "metadata" element:

{
	"result": {
		"schemas": [{"name": "name of a schema"},{"name": "name of another schema"}]
	}
}

 

Specific Logical Errors

(Refer to Common Logical Error Codes)

Examples

Sample Request

Request URL: http://sandbox.apstrata.com/apsdb/rest/[authenticationkey]/ListSchemas?apsws.time=[timestamp]&apsws.authSig=[signature]


POST parameters: None

Sample XML Response

Success XML:

<response xmlns="http://www.apstrata.com/services/schemas/apstrata_database_response.xsd">
    <metadata>
        <requestId>xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx</requestId>
        <status>success</status>        
    </metadata> 
    <result> 
        <schemas> 
           <schema name="mySchema1" /> 
           <schema name="mySchema2" /> 
           <schema name="mySchema3" /> 
        </schemas> 
    </result>
</response>


Failure XML:

<response xmlns="http://www.apstrata.com/services/schemas/apstrata_database_response.xsd">
    <metadata>
        <requestId>xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx</requestId>
        <status>failure</status>
        <errorCode>[errorCode]</errorCode>
        <errorDetail>[failMsg]</errorDetail>
    </metadata>
</response>


Sample JSON Response

{"response": {
  "metadata": {
    "requestId": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
    "status": "success"
  } 
  "result": {
    "schemas": [
      {
        "name": "mySchema1"
      },
      {
        "name": "mySchema2"
      },
      {
        "name": "mySchema3"
      }
    ]
  }
}}
  • No labels