METHOD OF PROCESSING APIs

CLAIM OF BENEFIT TO PRIOR APPLICATION

0001This application claims benefit to U.S. Provisional Patent Application 62/051,924, filed Sep. 17, 2014, which is incorporated herein by reference.

REFERENCE TO COMPUTER PROGRAM LISTINGS

0002This application incorporates by reference a computer program listing appendix in an ASCII text file having a title “2014_—09_—17_SLOO_P0001P_Appendices.txt”, which includes an Appendix A portion, an Appendix B portion, and an Appendix C portion. The text file “2014_—09_—17_SLOO_P0001P_Appendices.txt” has a size of 56347 bytes and was created on Sep. 17, 2014.

BACKGROUND

0003With the proliferation of mobile devices, the need for servers that can process application programming interface (API) requests from the mobile devices has never been greater. There is also a need for robust frameworks that allow developers create programs for processing such API requests on clients and on the server. Ideally, this framework would make the processing of such requests on a client or on a server seamless.

SUMMARY

0004Some embodiments of the invention provide a novel server for processing application programming interface (API) requests. In some embodiments, the API server is written in JavaScript. For example, in some embodiments, the API-accessible objects of this server are each defined in terms of a JavaScript file and a JSON (JavaScript Object Notation) file. At runtime, a runtime processor instantiates each JavaScript object from its associated JavaScript and JSON files. Once instantiated, the JavaScript object can be used to process API requests that refer to the JavaScript object. Some embodiments use novel JSON file structures that allow these embodiments to define rich JavaScript models, as further described below.

0005To process API calls to JavaScript objects, the API server of some embodiments needs to exchange data with (e.g., to read from or to write to) a variety of different backend data storages (e.g., relational databases, REST accessible data storages, SOAP accessible data storages, memory, etc.) through a variety of different interfaces. To allow for this, the server of some embodiments includes a data storage abstractor and a data storage connector. The data storage abstractor provides a layer of data abstraction between the JavaScript (JS) objects and the underlying data in the backend data storages. For instance, in some embodiments, the abstractor translates the JavaScript object definitions to the object definitions of the underlying data storages. In other embodiments, the abstractor simply provides a set of functions that allows the JS objects to exchange data with the backend data storages. For instance, in some embodiments, the abstractor provides create, retrieve, update, and delete (CRUD) functions to connect the JavaScript objects to the backend data storages. In these or other embodiments, the abstractor can also connect to the backend data storages through REST APIs, SOAP web services, and other storage services.

0006In some embodiments, the data storage abstractor is backed by the data storage connector, which implements the data exchange logic using data storage drivers or other client APIs. In some embodiments, the JavaScript objects also connect to the backend data storages through a replication manager that connects the JavaScript objects to the data storage connectors and synchronizes the data between the JS object and the backend data storage. Instead of using the replication manager to synchronize the data between a JS object and a backend data storage, or in conjunction with this usage, some embodiments use the replication manager to synchronize the data between two API servers or between an API server and a client.

0007The JavaScript API server in some embodiments can handle a large number of concurrent sessions with a large number of devices (e.g., computers, mobile devices, etc.). For instance, in some embodiments, this API server has a non-blocking input/output (I/O) interface that can concurrently maintain a large number of concurrent sessions. The I/O interface of some embodiments is a single-threaded process that does not consume too much of the system resources, which, in turn allows the server to be able to handle a large number of concurrent sessions. The JavaScript API server in some embodiments can maintain a session with a connecting device (e.g., a connecting mobile device) for a long duration of time and without interruption. In some embodiments, this API server can maintain a session for a long duration because it uses a web socket manager to manage the connection session.

0008In some embodiments, the JavaScript API server exposes its APIs (i.e., exposes its accessible objects through APIs) to other devices (e.g., other servers, computers, mobile devices) through non-proprietary web services. For instance, the server of some embodiments exposes its APIs through REST (Representational State Transfer) web services. Other embodiments expose the APIs through other services.

0009The API server of some embodiments processes API requests from client devices (e.g., mobile devices) that have the capability to process some or all of their API requests locally. In these embodiments, the client devices may process an API locally by accessing the local data stores through an object (called a proxy object below) that resides on the client, or by directing the server to process this API request remotely. The proxy object in some embodiments is a JS object that is constructed from a class description that is specified by a JavaScript file and a JSON file on the client. For instance, in some embodiments, the proxy objects on the client device are JS objects when the proxy objects are part of an application that executes on top of a JS engine of a browser on the client device. In such cases, the JS and JSON files on the client device are identical or similar to the two corresponding files that are used to define the object on the API server in some embodiments.

0010In other embodiments, the proxy object on a client device can be a non-JS object (e.g., a Java object or an objective C object). For instance, in some embodiments, the proxy objects on the client device are non-JS objects when the proxy objects are part of an application that executes natively on top of the operating system (e.g., on top of iOS or Android operating system) of the client device. For applications that run natively on a device's operating system, some embodiments do not distribute models that are defined by reference to JS and JSON files. In some of these embodiments, the client device includes an adapter that has the capability to query the server dynamically for models and then instantiates them as native object equivalent (e.g., as objective C objects in iOS and as Java objects in Android) at runtime.

0011In some embodiments, the API calls on the client and server are identical and hence are referred to as isomorphic API calls. In some of these embodiments, the format of the API calls is exactly the same. In other embodiments, the format is somewhat different (e.g., when JavaScript objects are being executed on the server, while Java or Objective C objects are being executed on the clients). However, even in these embodiments, the APIs on the server and client can be isomorphic as the same set of parameters are passed along with the API and the same set of parameters are returned from the API on the client and the server. In other words, when applications run natively on the client device operating system, the proxy object that is instantiated in the native environment represents and is an isomorphic equivalent of what is specified on the server.

0012As mentioned above, some embodiments use novel JSON file structures that allow these embodiments to define rich JavaScript models, each of which can be instantiated at runtime to be an object that can process an API request (e.g., on the client or on the server). Also, as mentioned above, each model includes (1) a JSON file that describes the properties of the object, and (2) a JavaScript file that describes the behaviors of the object.

0013In some embodiments, the JSON file structure includes (1) a rich description of properties that relate to data tuples stored on data storages, (2) control logic for restricting access to the data tuples, and (3) relationship attributes that define the relationship between the JSON file's model and other models. The rich property attributes of the JSON file allows a data storage to be specifically identified in terms of its location, name, and attributes, and also allows one JSON file to pull values for one or more properties from two or more data storages.

0014The relationship attributes of a particular object's JSON file allows one or more links to other objects to be specified when the particular object is being instantiated. In some embodiments, the control logic of a JSON file includes validation rules and access control list (ACL) rules. The validation rules in some embodiments ensure that the data tuples that are gathered from one or more data storages meet a required constraint that is specified for them in the rules. For instance, a validation rule might require that “Car” object have an associated VIN attribute. When a retrieved Car data tuple does not have a VIN attribute, the data tuple is not accepted as a Car because it does not meet the specified constraint for a Car.

0015ACL rules in some embodiments ensure that the portion of a retrieved data tuple that is presented on a device satisfies certain access control criteria. For instance, an API to a bank account object might retrieve one set of values on both a computer and a mobile device. However, while the object's ACL rule might allow all of the values to be presented on the computer, the object's ACL rule might prevent some of the data values (e.g., bank account number) from being presented on the mobile device, because mobile devices might be as being inherently less secure than computers. In some embodiments, the ACLs and validation rules are implemented as hooks (i.e., function calls) that are called before or after calling of the API. In other embodiments, the ACLs and validation rules are processed by the runtime processor before or after processing the API request.

0016Some embodiments of the invention provide a framework for defining models by defining JS files and/or JSON files. As mentioned above, a model can be defined by an associated pair of JS file and JSON file in some embodiments. In some embodiments, the framework pre-defines one set of functions for each object that is instantiated from each model. For instance, in some embodiments, each JS object can perform the CRUD functions.

0017The framework of some embodiments allows additional functions to be written in the JS file in order to augment and override the set of functions of an object that is instantiated from the JS file. These additional functions can be written as hooks (e.g., function calls that are processed before or after a baseline function) that can be processed locally (e.g., on a client device) or remotely (e.g., on the server). The processing of these function calls is quite simple given the isomorphic nature of the API calls in some embodiments. The call can be made similarly on the client device or on the server. Also, on the client device, the call can be made without consideration of whether the call is going to be processed locally or remotely. In some embodiments, the framework can determine whether to process this call locally or remotely based on pre-defined conditions for processing the call or dynamically assessed conditions for processing the call.

0018The preceding Summary is intended to serve as a brief introduction to some embodiments of the invention. It is not meant to be an introduction or overview of all-inventive subject matter disclosed in this document. The Detailed Description that follows and the Drawings that are referred to in the Detailed Description will further describe the embodiments described in the Summary as well as other embodiments. Accordingly, to understand all the embodiments described by this document, a full review of the Summary, Detailed Description and the Drawings is needed. Moreover, the claimed subject matters are not to be limited by the illustrative details in the Summary, Detailed Description and the Drawings, but rather are to be defined by the appended claims, because the claimed subject matters can be embodied in other specific forms without departing from the spirit of the subject matters.

BRIEF DESCRIPTION OF DRAWINGS

0019The novel features of the invention are set forth in the appended claims. However, for purposes of explanation, several embodiments of the invention are set forth in the following figures.

0020<figref idref="DRAWINGS">FIG. 1</figref> illustrates a JavaScript API server of some embodiments of the invention.

0021<figref idref="DRAWINGS">FIG. 2</figref> presents a conceptual illustration of the API processing modules of a client device of some embodiments.

0022<figref idref="DRAWINGS">FIG. 3</figref> illustrates a novel model description of some embodiments of the invention.

0023<figref idref="DRAWINGS">FIG. 4</figref> presents a process that conceptually illustrates how a JavaScript model is defined in some embodiments of the invention.

0024<figref idref="DRAWINGS">FIG. 5</figref> illustrates a more-detailed view of a JavaScript API server of some embodiments of the invention.

0025<figref idref="DRAWINGS">FIG. 6</figref> conceptually illustrates executing proxy objects of some embodiments in a native OS environment of a client device.

0026<figref idref="DRAWINGS">FIG. 7</figref> conceptually illustrates executing the JS models of some embodiments within a web browser that executes on a client device.

0027<figref idref="DRAWINGS">FIG. 8</figref> conceptually illustrates an electronic system with which some embodiments of the invention are implemented.

DETAILED DESCRIPTION

0028In the following detailed description of the invention, numerous details, examples, and embodiments of the invention are set forth and described. However, it will be clear and apparent to one skilled in the art that the invention is not limited to the embodiments set forth and that the invention may be practiced without some of the specific details and examples discussed.

0029Some embodiments of the invention provide a novel server for processing application programming interface (API) requests. In some embodiments, the API server is written in JavaScript. For examples, in some embodiments, the API-accessible objects of this server are each defined in terms of a JavaScript (JS) file and a JSON file. At runtime, a runtime processor instantiates each JavaScript object from its associated JS and JSON files. In some embodiments, a JS file and a JSON file are associated with each other through their common names.

0030<figref idref="DRAWINGS">FIG. 1</figref> illustrates one such JavaScript API server <b>100</b> of some embodiments of the invention. This server can process API requests from a variety of devices, such as smartphones <b>190</b>, tablets <b>192</b>, client computers (e.g., laptops, desktops, etc.) <b>194</b>, server computers <b>196</b>, and other devices. As shown, this API server includes a runtime processor <b>105</b>, a data abstractor <b>110</b>, a data storage connector <b>115</b>, an API handler <b>120</b>, and an I/O handler <b>125</b>. Also, as shown, this API server stores the description of multiple JavaScript models <b>135</b>, with each model defined in terms of a JavaScript file <b>140</b> and a JSON file <b>145</b>.

0031The runtime processor <b>105</b> in some embodiments instantiates a JavaScript object <b>150</b> for each model based on the object's description that is contained in its associated JavaScript model (i.e., that is contained in the JS object's associated JS file and JSON file). The Appendix A portion of the incorporated ASCII text file computer program listing appendix provides the source code within a JS framework of some embodiments that can be used to instantiate a JS object from the description of the object in a JS file and a JSON file. Once instantiated, the JavaScript object can be used to process API requests from other devices (such as mobile devices, client computers, and other server computers). These other devices will be referred to below as client devices of the API server.

0032To process API calls, the JS objects of some embodiments needs to exchange data with (e.g., to read from or to write to) a variety of different backend data storages <b>155</b>-<b>165</b> that have a variety of different interfaces. The data storage abstractor <b>110</b> and the data storage connector <b>115</b> allow these JS objects to exchange data with the backend data storages. The data storage abstractor <b>110</b> provides a layer of data abstraction between the JavaScript objects and the underlying data in the backend data storages. For instance, in some embodiments, the abstractor <b>110</b> translates the JavaScript object definitions to the object definitions of the underlying data storages. In other embodiments, the abstractor <b>110</b> simply provides a set of functions that allows the JS objects to exchange data with the backend data storages. For instance, in some embodiments, the abstractor <b>110</b> provides create, retrieve, update, and delete (CRUD) functions to connect the JS objects to the backend data storages. In these or other embodiments, the abstractor <b>110</b> can also connect to backend data storages through REST APIs, SOAP web services, and other data storage services.

0033The data storage abstractor <b>110</b>, in some embodiments, is backed by the data storage connector <b>115</b>, which implements the data exchange logic using data storage drivers or other client APIs. The JS objects also connect to backend data storages in some embodiments through a replication manager (not shown) that connects the JavaScript object to the data storage connectors and synchronizes the data between the JS object and the backend data storage. Such a replication manager is also used in some embodiments to synchronize the data between two API servers or between an API server and a client. In some embodiments, the replication manager synchronizes the data between the API server and another device (e.g., a server computer or a client device, such as a mobile device or a client computer) by synchronizing a persisted version of the JS objects that are stored on the API server and the other device.

0034Through the I/O manager <b>125</b>, the API server in some embodiments can handle a large number of concurrent sessions with a large number of devices (e.g., computers, mobile devices, etc.). For instance, in some embodiments, this manager has a non-blocking input/output (I/O) interface that can concurrently maintain a large number of concurrent sessions. The I/O interface of some embodiments is a single-threaded process that does not consume too much of the system resources, which in turn, allows the server to be able to handle a large number of concurrent sessions. This I/O manager <b>125</b> in some embodiments can also maintain a session with a connecting device (e.g., a connecting mobile device) for a long duration of time and without interruption. In some embodiments, the I/O manager <b>125</b> can maintain a session for a long duration because it uses a web socket manager to manage the connection session.

0035The API handler <b>120</b> exposes the API server's JS objects <b>150</b> to the other devices (e.g., other servers <b>196</b>, computers <b>194</b>, and mobile devices <b>190</b> and <b>192</b>). In some embodiments, the handler <b>120</b> uses non-proprietary web services to expose the APIs. For instance, the handler <b>120</b> of some embodiments exposes the JS object APIs through REST web services. Other embodiments expose the APIs through other services.

0036The API server of some embodiments processes API requests from client devices (e.g., mobile devices) that have the capability to process some or all of their API requests locally. <figref idref="DRAWINGS">FIG. 2</figref> presents a conceptual illustration of the API processing modules of one such client device. As shown, this client device <b>200</b> has a runtime processor <b>205</b> that instantiates several proxy objects <b>250</b> that are proxies on the client device for several JS objects that operate on the API server <b>100</b>.

0037Once instantiated, a proxy object <b>250</b> on the client can be used to process an API request from local data storages <b>255</b> that reside on the client device <b>200</b>, or by calling a corresponding JS object <b>280</b> that resides on the API server <b>100</b> so that this object <b>280</b> can process this request (e.g., by using backend data storages <b>155</b>-<b>165</b>). As described in the concurrently filed U.S. patent application Ser. No. ______, entitled “Dynamic Determination of Local and Remote API Calls,” with Attorney Docket No. SLOO.P0002, which is incorporated herein by reference, the determination of whether the API request should be processed locally on the client or remotely on the server is made dynamically on the client in some embodiments. This dynamic decision is based on conditions that are dynamically assessed on the client in some embodiments.

0038As shown, the proxy objects <b>250</b> access the local data storages <b>255</b> through a data abstractor <b>210</b> and a data connector <b>215</b>, which provide the same operations on the client device <b>200</b> as the data abstractor <b>110</b> and the data connector <b>115</b> provide on the server <b>100</b>. In some embodiments, the data abstractor <b>210</b> and the data connector <b>215</b> are not used in some of the client-side environments as the objects <b>250</b> can pull data directly from the client's local storages without going through the data abstraction and connection layers. Also, the proxy object <b>250</b> accesses its corresponding JS object <b>280</b> on the API server through one or more modules that form a server interface <b>275</b>. Several examples of these modules will be further described below.

0039In the discussion below, an object <b>250</b> on the client is referred to as a proxy object, as it can act on the client as a proxy of the object <b>280</b> on the server. As further described below, the proxy object on a client device can be a different type of object (e.g., a JS object, a Java object, or an objective C object) in some embodiments. For instance, in some embodiments, some mobile applications execute on top of a JS engine of a browser on a client device, while other mobile applications execute natively on top of the operating system of the client device. In some of these embodiments, the applications that execute on top of the browser's JS engine instantiate JS proxy objects, while the applications that run natively instantiate other types of proxy objects (e.g., Java objects or objective C objects).

0040In some embodiments where the proxy object is a JS object (e.g., when the proxy objects are part of an application that executes on top of a JS engine of a browser on the client device), the proxy object is constructed from a class description that is specified by a JavaScript file and a JSON file on the client. In some of these embodiments, the JS and JSON files on the client device are identical or similar to the two corresponding files that are used to define the object on the API server in some embodiments.

0041When the proxy object on a client device is not a JS object (e.g., it is a Java object or an objective C object that is defined to run natively on the client device's OS), some embodiments do not distribute models that are defined by reference to JS and JSON files. In some of these embodiments, the client device includes an adapter that has the capability to query the server dynamically for an object description, and then, based on the received object description, instantiate a native object (e.g., as objective C objects in iOS and as Java objects in Android) at runtime.

0042In some embodiments, the API calls on the client and server are identical and hence are referred to as isomorphic API calls. In some of these embodiments, the format of the API calls is exactly the same. In other embodiments, the format is somewhat different (e.g., when JavaScript objects are being executed on the server, while Java or Objective C objects are being executed on the clients). However, even in these embodiments, the APIs on the server and client can be isomorphic as the same set of parameters are passed along with the API and the same set of parameters are returned from the API on the client and the server. In other words, when applications run natively on the client device operating system, the proxy object that is instantiated in the native environment represents and is an isomorphic equivalent of what is specified on the server.

0043Some embodiments of the invention provide a framework for defining models by defining JS files and/or JSON files. As mentioned above, a model can be defined by an associated pair of JS file and JSON file in some embodiments. In some embodiments, the framework pre-defines one set of functions for each object that is instantiated from each model. For instance, in some embodiments, each JS object can perform the CRUD functions.

0044The framework of some embodiments allows additional functions to be written in the JS file in order to augment and override the set of functions of an object that is instantiated from the JS file. These additional functions can be written as hooks (e.g., function calls that are processed before or after a baseline function) that can be processed locally (e.g., on a client device) or remotely (e.g., on the server). The processing of these function calls is quite simple given the isomorphic nature of the API calls in some embodiments. The call can be made identically on a client device irrespective of whether it is going to be processed locally or remotely. The framework can determine whether to process this call locally or remotely based on pre-defined conditions for processing the call or dynamically assessed conditions for processing the call.

0045<figref idref="DRAWINGS">FIG. 3</figref> illustrates a novel model description of some embodiments of the invention. This model description uses a novel JSON file structure that allows these embodiments to define rich JavaScript models. As mentioned above, each model can be instantiated at runtime to be an object that can process API requests on a client device or on a server. As shown, the model <b>300</b> in these embodiments includes (1) a high level handle <b>305</b>, (2) a JavaScript file <b>310</b> that describes the behaviors of the object, and (3) a JSON file <b>315</b> that describes the attributes (e.g., the properties, relations, control logic, etc.) of the object.

0046As shown, besides a name key <b>320</b>, the JSON file <b>315</b> of some embodiments includes (1) a rich description of properties <b>325</b> and <b>330</b> that relate to data tuples stored on data storages, (2) properties <b>335</b> that have fix values and do not relate to any data tuples stored on data storages, (3) control logics <b>340</b> and <b>345</b> for restricting access to the data tuples, and (4) relationship attributes <b>350</b> that define the relationship between the JSON file's model and other models. In some embodiments, the rich property attributes <b>325</b> and <b>330</b> of the JSON file allow a data storage to be specifically identified in terms of its location, name, and attributes, and also allows one JSON file to pull values for one or more properties from two or more data storages.

0047In some embodiments, the control logic <b>340</b> and <b>345</b> of a JSON file include validation rules and access control list (ACL) rules. The validation rules <b>340</b> in some embodiments ensure that the data tuples that are gathered from one or more data storages meet a required constraint that is specified for them in the rules. For instance, a validation rule might require that “Car” object have an associated VIN attribute. When a retrieved Car data tuple does not have a VIN attribute, the data tuple is not accepted as a Car because it does not meet the specified constraint for a Car.

0048ACL rules <b>345</b> in some embodiments ensure that the portion of a retrieved data tuple that is presented on a device satisfies certain access control criteria. For instance, an API to a bank account object might retrieve one set of values on both a computer and a mobile device. However, while the object's ACL rule might allow all of the values to be presented on the computer, the object's ACL rule might prevent some of the data values (e.g., bank account number) from being presented on the mobile device, because mobile devices might be as being inherently less secure than computers. In some embodiments, the ACLs and validation rules are implemented as hooks (i.e., function calls) that are called before or after processing the API.

0049The relations attribute <b>350</b> of a particular object's JSON file allows one or more links to other objects to be specified when the particular object is being instantiated.

0050Several examples of JSON files will now be described to further elaborate on the JSON file format of some embodiments. In some embodiments, a model is named as model-name.json, where model-name is the name of the model. For example customer.json for a customer model. The customer model's JSON file may specify the following attributes,

0000<tables id="TABLE-US-00001" num="00001"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="77pt" align="left" /><colspec colname="1" colwidth="140pt" align="left" /><thead><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>{</entry></row><row><entry /><entry> “name”: “Customer”,</entry></row><row><entry /><entry> “base”: “User”,</entry></row><row><entry /><entry> “idInjection”: false,</entry></row><row><entry /><entry> “strict”: true,</entry></row><row><entry /><entry> “options”: { ... },</entry></row><row><entry /><entry> “properties”: { ... },</entry></row><row><entry /><entry> “validations”: [...],</entry></row><row><entry /><entry> “relations”: {...},</entry></row><row><entry /><entry> “acls”: [...],</entry></row><row><entry /><entry> “scopes”: {...},</entry></row><row><entry /><entry> “indexes” : { ...},</entry></row><row><entry /><entry> “methods”: [...]</entry></row><row><entry /><entry>}</entry></row><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables><br /> where the above mentioned keys in this file, are defined as follows.

0000<tables id="TABLE-US-00002" num="00002"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="1" colwidth="42pt" align="left" /><colspec colname="2" colwidth="28pt" align="left" /><colspec colname="3" colwidth="147pt" align="left" /><thead><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row><row><entry>Attribute</entry><entry>Type</entry><entry>Description</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>name</entry><entry>String</entry><entry>Name of the model.</entry></row><row><entry /><entry /><entry>Required</entry></row><row><entry>plural</entry><entry>String</entry><entry>Plural form of the model name.</entry></row><row><entry /><entry /><entry>Optional: Defaults to plural of name property</entry></row><row><entry /><entry /><entry>using standard English conventions.</entry></row><row><entry>base</entry><entry>String</entry><entry>Name of another model that this model extends.</entry></row><row><entry /><entry /><entry>The model will “inherit” properties</entry></row><row><entry /><entry /><entry>and methods of the base model.</entry></row><row><entry /><entry /><entry>Required</entry></row><row><entry>idInjection</entry><entry>Boolean</entry><entry>Whether to automatically add an id property</entry></row><row><entry /><entry /><entry>to the model:</entry></row><row><entry /><entry /><entry>true: id property is added to the model</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="84pt" align="left" /><colspec colname="1" colwidth="133pt" align="left" /><tbody valign="top"><row><entry /><entry>automatically. This is the default.</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="1" colwidth="42pt" align="left" /><colspec colname="2" colwidth="28pt" align="left" /><colspec colname="3" colwidth="147pt" align="left" /><tbody valign="top"><row><entry /><entry /><entry>false: id property is not added to the model</entry></row><row><entry /><entry /><entry>Not required</entry></row><row><entry>strict</entry><entry>Boolean</entry><entry>Specifies whether the model accepts only</entry></row><row><entry /><entry /><entry>predefined properties or not.</entry></row><row><entry /><entry /><entry>One of:</entry></row><row><entry /><entry /><entry>true: Only properties defined in the model</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="84pt" align="left" /><colspec colname="1" colwidth="133pt" align="left" /><tbody valign="top"><row><entry /><entry>are accepted. Use this mode if developer</entry></row><row><entry /><entry>wants to make sure only predefined</entry></row><row><entry /><entry>properties are accepted.</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="70pt" align="left" /><colspec colname="1" colwidth="147pt" align="left" /><tbody valign="top"><row><entry /><entry>false: The model will be an open model.</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="84pt" align="left" /><colspec colname="1" colwidth="133pt" align="left" /><tbody valign="top"><row><entry /><entry>All properties are accepted, including the</entry></row><row><entry /><entry>ones that not predefined with the model.</entry></row><row><entry /><entry>This mode is useful if the mobile</entry></row><row><entry /><entry>application just wants to store free form</entry></row><row><entry /><entry>JSON data to a schema-less database such</entry></row><row><entry /><entry>as MongoDB,</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="70pt" align="left" /><colspec colname="1" colwidth="147pt" align="left" /><tbody valign="top"><row><entry /><entry>Undefined: Default to false unless the data</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="84pt" align="left" /><colspec colname="1" colwidth="133pt" align="left" /><tbody valign="top"><row><entry /><entry>source is backed by a relational database</entry></row><row><entry /><entry>such as Oracle or MySQL.</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="1" colwidth="42pt" align="left" /><colspec colname="2" colwidth="28pt" align="left" /><colspec colname="3" colwidth="147pt" align="left" /><tbody valign="top"><row><entry>options</entry><entry>Object</entry><entry>JSON object that specifies model options.</entry></row><row><entry>properties</entry><entry>Object</entry><entry>JSON object that specifies the properties</entry></row><row><entry /><entry /><entry>in the model.</entry></row><row><entry>validation</entry><entry>Object</entry><entry>JSON object that specifies validation</entry></row><row><entry /><entry /><entry>constrains in the model</entry></row><row><entry>relations</entry><entry>Object</entry><entry>Object containing relation names and</entry></row><row><entry /><entry /><entry>relation definitions.</entry></row><row><entry>Acls</entry><entry>Array</entry><entry>Set of ACL specifications that describes</entry></row><row><entry /><entry /><entry>access control for the model.</entry></row><row><entry>scopes</entry><entry>Object</entry><entry>Object that allows developer to specify</entry></row><row><entry /><entry /><entry>commonly-used queries that the developer</entry></row><row><entry /><entry /><entry>can reference as method calls on a model.</entry></row><row><entry>indexes</entry><entry>Object</entry><entry>Object for declaring method</entry></row><row><entry>methods</entry><entry /><entry>Methods of object</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0051In this set of attributes, the options key specifies data source-specific options. When a model is attached to a data source of a certain type (e.g., Oracle or MySQL), a developer can specify the name of the database schema and the table as properties under the key with the name of the connector type such as below:

0000<tables id="TABLE-US-00003" num="00003"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="63pt" align="left" /><colspec colname="1" colwidth="154pt" align="left" /><thead><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>...</entry></row><row><entry /><entry>“options”: {</entry></row><row><entry /><entry> “mysql”: {</entry></row><row><entry /><entry> “table”: “location”</entry></row><row><entry /><entry> },</entry></row><row><entry /><entry> “mongodb”: {</entry></row><row><entry /><entry> “collection”: “location”</entry></row><row><entry /><entry> },</entry></row><row><entry /><entry> “oracle”: {</entry></row><row><entry /><entry> “schema”: “BLACKPOOL”,</entry></row><row><entry /><entry> “table”: “LOCATION”</entry></row><row><entry /><entry> }</entry></row><row><entry /><entry>},</entry></row><row><entry /><entry>...</entry></row><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0052Properties key defines one or more properties. One example of a basic property definition is as follows:

0000<tables id="TABLE-US-00004" num="00004"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="77pt" align="left" /><colspec colname="1" colwidth="140pt" align="left" /><thead><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>“properties”: {</entry></row><row><entry /><entry> “firstName”: {</entry></row><row><entry /><entry> “type”: “String”,</entry></row><row><entry /><entry> “required”: “true”</entry></row><row><entry /><entry> },</entry></row><row><entry /><entry> “id”: {</entry></row><row><entry /><entry> “type”: “Number”,</entry></row><row><entry /><entry> “id”: true,</entry></row><row><entry /><entry> “doc”: “User ID”</entry></row><row><entry /><entry>},</entry></row><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables><br /> Each property that is listed under the properties key is an object that has keys described in the following table.

0000<tables id="TABLE-US-00005" num="00005"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="4"><colspec colname="1" colwidth="28pt" align="left" /><colspec colname="2" colwidth="35pt" align="left" /><colspec colname="3" colwidth="28pt" align="left" /><colspec colname="4" colwidth="126pt" align="left" /><thead><row><entry namest="1" nameend="4" align="center" rowsep="1" /></row><row><entry>Key</entry><entry>Required?</entry><entry>Type</entry><entry>Description</entry></row><row><entry namest="1" nameend="4" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>doc</entry><entry>No</entry><entry>String</entry><entry>Documentation for the property,</entry></row><row><entry>id</entry><entry>No</entry><entry>Boolean</entry><entry>Whether the property is a unique</entry></row><row><entry /><entry /><entry /><entry>identifier. Default is false.</entry></row><row><entry>required</entry><entry>No</entry><entry>Boolean</entry><entry>Whether a value for the property is</entry></row><row><entry /><entry /><entry /><entry>required.</entry></row><row><entry /><entry /><entry /><entry>Default is false.</entry></row><row><entry>type</entry><entry>Yes</entry><entry>String</entry><entry>Property type, In some embodiments,</entry></row><row><entry /><entry /><entry /><entry>can be null, Boolean, number, string,</entry></row><row><entry /><entry /><entry /><entry>object, array, date, buffer, and GeoPoint.</entry></row><row><entry>*</entry><entry>No</entry><entry>Various</entry></row><row><entry namest="1" nameend="4" align="center" rowsep="1" /></row></tbody></tgroup></table></tables><br /> A model representing data to be persisted in a database usually has one or more ID properties (as identified by the “id” key) that uniquely identify the model instance. For example, the user model might have user IDs. By default, if no ID properties are defined and the idInjection property is true or is not set, since true is the default), the model builder of some embodiments automatically adds an id property to the model as follows: id: {type: Number, generated: true, id: true}. The “generated” property indicates the ID will be automatically generated by the database, if true, the connector decides what type to use for the auto-generated key. For relational databases (e.g., Oracle or MySQL), it defaults to number. If the ID is generated on the client side, it is set to false in some embodiments.

0053To explicitly specify a property as ID, the id property of the option should be set to true in some embodiments. The ID property value must be one of: <ul id="ul0001" list-style="none"><li id="ul0001-0001" num="0000"><ul id="ul0002" list-style="none"><li id="ul0002-0001" num="0054">true: the property is an ID.</li><li id="ul0002-0002" num="0055">false (or any value that converts to false): the property is not an ID (default).</li><li id="ul0002-0003" num="0056">Positive number, such as 1 or 2: the property is the index of a composite ID.</li></ul></li></ul>

0057In database terms, key column(s) are ID properties. Such properties are defined with the “id” attribute set to true or a number as the position for a composite key. For example,

0000<tables id="TABLE-US-00006" num="00006"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="77pt" align="left" /><colspec colname="1" colwidth="140pt" align="left" /><thead><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>{</entry></row><row><entry /><entry> “myId”: {</entry></row><row><entry /><entry> “type”: “string”,</entry></row><row><entry /><entry> “id”: true</entry></row><row><entry /><entry> }</entry></row><row><entry /><entry>}</entry></row><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables><br /> When a model doesn't have explicitly-defined ID properties, the model builder of some embodiments automatically injects a property named “id” unless the idInjection option is set to false. If an ID property has “generated” set to true, the data storage connector decides what type to use for the auto-generated key. For example for SQL Server, it defaults to number. The data abstractor CRUD methods expect the model to have an “id” property if the model is backed by a database. A model without any “id” properties can only be used without attaching to a database.

0058Some embodiments allow the definition of a composite ID that has more than one property. For example, an inventory object can be defined as:

0000<tables id="TABLE-US-00007" num="00007"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="56pt" align="left" /><colspec colname="1" colwidth="161pt" align="left" /><thead><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>var InventoryDefinition = {</entry></row><row><entry /><entry> productId: {type: String, id: 1},</entry></row><row><entry /><entry> locationId: {type: String, id: 2},</entry></row><row><entry /><entry> qty: Number</entry></row><row><entry /><entry>}</entry></row><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables><br /> In this example, the composite ID is (productId, locationId) for an inventory model.

0059When using an RDB data source, some embodiments allow a developer to specify the following properties that describe the columns in the database.

0000<tables id="TABLE-US-00008" num="00008"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="4"><colspec colname="1" colwidth="14pt" align="left" /><colspec colname="2" colwidth="49pt" align="left" /><colspec colname="3" colwidth="35pt" align="left" /><colspec colname="4" colwidth="119pt" align="left" /><thead><row><entry namest="1" nameend="4" align="center" rowsep="1" /></row><row><entry /><entry>Property</entry><entry>Type</entry><entry>Description</entry></row><row><entry namest="1" nameend="4" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>columnName</entry><entry>String</entry><entry>Column name</entry></row><row><entry /><entry>dataType</entry><entry>String</entry><entry>Data type as defined in the database</entry></row><row><entry /><entry>dataLength</entry><entry>Number</entry><entry>Data length</entry></row><row><entry /><entry>dataPrecision</entry><entry>Number</entry><entry>Numeric data precision</entry></row><row><entry /><entry>dataScale</entry><entry>Number</entry><entry>Numeric data scale</entry></row><row><entry /><entry>nullable</entry><entry>Boolean</entry><entry>If true, data can be null</entry></row><row><entry namest="1" nameend="4" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0060For example, a property can be mapped to a column in an Oracle database table, by stating the following in the JSON file:

0000<tables id="TABLE-US-00009" num="00009"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="56pt" align="left" /><colspec colname="1" colwidth="161pt" align="left" /><thead><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>...</entry></row><row><entry /><entry>“name”: {</entry></row><row><entry /><entry> “type”: “String”,</entry></row><row><entry /><entry> “required”: false,</entry></row><row><entry /><entry> “length”: 40,</entry></row><row><entry /><entry> “oracle”: {</entry></row><row><entry /><entry>  “columnName”: “NAME”,</entry></row><row><entry /><entry>  “dataType”: “VARCHAR2”,</entry></row><row><entry /><entry>  “dataLength”: 40,</entry></row><row><entry /><entry>  “nullable”: “Y”</entry></row><row><entry /><entry> }</entry></row><row><entry /><entry> }</entry></row><row><entry /><entry>...</entry></row><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0061This is a rich description of a backend data storage and a particular data tuple field (i.e., columnName, dataType, dataLength, etc.) in this storage. Providing such a rich description in a JSON file of a model is quite novel, as other prior approaches do not provide such rich attribute descriptions in JSON files.

0062In some embodiments, format conversions are declared in properties, per the keys in the following table:

0000<tables id="TABLE-US-00010" num="00010"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="1" colwidth="49pt" align="left" /><colspec colname="2" colwidth="42pt" align="left" /><colspec colname="3" colwidth="126pt" align="left" /><thead><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row><row><entry>Key</entry><entry>Type</entry><entry>Description</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>trim</entry><entry>Boolean</entry><entry>Whether to trim the string</entry></row><row><entry>lowercase</entry><entry>Boolean</entry><entry>Whether to convert a string to lowercase</entry></row><row><entry>uppercase</entry><entry>Boolean</entry><entry>Whether to convert a string to uppercase</entry></row><row><entry>format</entry><entry>Regular</entry><entry>Format for a date property.</entry></row><row><entry /><entry>expression</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0063As mentioned above, the validation key specifies constraints on data with validations properties. The table below provides an example of keys that can be used to define validation constraints in the JSON file in some embodiments.

0000<tables id="TABLE-US-00011" num="00011"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="1" colwidth="35pt" align="left" /><colspec colname="2" colwidth="35pt" align="left" /><colspec colname="3" colwidth="147pt" align="left" /><thead><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row><row><entry>Key</entry><entry>Type</entry><entry>Description</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>default</entry><entry>Any</entry><entry>Default value of the property.</entry></row><row><entry>required</entry><entry>Boolean</entry><entry>Whether the property is required,</entry></row><row><entry>pattern</entry><entry>String</entry><entry>Regular expression pattern that a string should</entry></row><row><entry /><entry /><entry>match</entry></row><row><entry>max</entry><entry>Number</entry><entry>Maximum length for string types.</entry></row><row><entry>min</entry><entry>Number</entry><entry>Minimum length for string types.</entry></row><row><entry>length</entry><entry>Number</entry><entry>Maximum size of a specific type, for example</entry></row><row><entry /><entry /><entry>for CHAR types.</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0064One example of setting a validation constraint with such keys is provided below.

0000<tables id="TABLE-US-00012" num="00012"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="63pt" align="left" /><colspec colname="1" colwidth="154pt" align="left" /><thead><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>“username”: {</entry></row><row><entry /><entry> “type”: “string”,</entry></row><row><entry /><entry> “doc”: “User account name,</entry></row><row><entry /><entry> “min”: 6,</entry></row><row><entry /><entry> “max”: 24</entry></row><row><entry /><entry>}</entry></row><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0065This validation constraint states that the username has to be string, its documentation has to contain “User account name”, and it has to be between 6-24 characters long. The validation class of the framework of some embodiments will be further described below.

0066As mentioned above, the relations key defines relationships between models through a JSON object. Each key in this object is the name of a related model, and the value is a JSON object as described in the table below. For example, the JSON file snippet below specifies that a JSON model belongs to an account model, and has a “hasMany” relationship to transaction and accessToken models.

0000<tables id="TABLE-US-00013" num="00013"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="56pt" align="left" /><colspec colname="1" colwidth="161pt" align="left" /><thead><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>  “relations”: {</entry></row><row><entry /><entry>   “accessTokens”: {</entry></row><row><entry /><entry>    “model”: “accessToken”,</entry></row><row><entry /><entry>    “type”: “hasMany”,</entry></row><row><entry /><entry>    “foreignKey”: “userId”</entry></row><row><entry /><entry>   },</entry></row><row><entry /><entry>   “account”: {</entry></row><row><entry /><entry>    “model”: “account”,</entry></row><row><entry /><entry>    “type”: “belongsTo”</entry></row><row><entry /><entry>   },</entry></row><row><entry /><entry>   “transactions”: {</entry></row><row><entry /><entry>    “model”: “transaction”,</entry></row><row><entry /><entry>    “type”: “hasMany”</entry></row><row><entry /><entry>   }</entry></row><row><entry /><entry>  },</entry></row><row><entry /><entry>...</entry></row><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0067The table below provides an example of keys that can be used to define relations in the JSON file in some embodiments.

0000<tables id="TABLE-US-00014" num="00014"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="1" colwidth="49pt" align="left" /><colspec colname="2" colwidth="28pt" align="left" /><colspec colname="3" colwidth="140pt" align="left" /><thead><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row><row><entry>Key</entry><entry>Type</entry><entry>Description</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>model</entry><entry>String</entry><entry>Name of the related model. Required.</entry></row><row><entry>type</entry><entry>String</entry><entry>Relation type. Required.</entry></row><row><entry /><entry /><entry>One of:</entry></row><row><entry /><entry /><entry>hasMany</entry></row><row><entry /><entry /><entry>belongsTo</entry></row><row><entry /><entry /><entry>hasAndBelongsToMany</entry></row><row><entry /><entry /><entry>For hasMany, developer can also specify a</entry></row><row><entry /><entry /><entry>hasManyThrough relation by adding a</entry></row><row><entry /><entry /><entry>“through” key: {through: ‘modelName’}</entry></row><row><entry>foreignKey</entry><entry>String</entry><entry>Optional foreign key used to find related model</entry></row><row><entry /><entry /><entry>instances.</entry></row><row><entry>through</entry><entry>String</entry><entry>Name of model creating hasManyThrough</entry></row><row><entry /><entry /><entry>relation. See example below.</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0068Example of hasManyThrough:

0000<tables id="TABLE-US-00015" num="00015"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="63pt" align="left" /><colspec colname="1" colwidth="154pt" align="left" /><thead><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>“patient”: {</entry></row><row><entry /><entry>  “model”: “physician”,</entry></row><row><entry /><entry>  “type”: “hasMany”,</entry></row><row><entry /><entry>  “through” : “appointment”</entry></row><row><entry /><entry>}</entry></row><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0069In this example, a patient model can have many relationships with appointments through one Or more physician models.

0070The value of an ACL key is an array of objects that describes the access controls for the model. Each object has the keys described in the table below.

0000<tables id="TABLE-US-00016" num="00016"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="56pt" align="left" /><colspec colname="1" colwidth="161pt" align="left" /><thead><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>“acls”: [</entry></row><row><entry /><entry>  {</entry></row><row><entry /><entry>   “permission”: “ALLOW”,</entry></row><row><entry /><entry>   “principalType”: “ROLE”,</entry></row><row><entry /><entry>   “principalId”: “$everyone”,</entry></row><row><entry /><entry>   “property”: “myMethod”</entry></row><row><entry /><entry>  },</entry></row><row><entry /><entry>  ...</entry></row><row><entry /><entry>]</entry></row><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0071The table below provides a list of keys by which an ACL key can be defined in some embodiments.

0000<tables id="TABLE-US-00017" num="00017"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="1" colwidth="56pt" align="left" /><colspec colname="2" colwidth="28pt" align="left" /><colspec colname="3" colwidth="133pt" align="left" /><thead><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row><row><entry>Key</entry><entry>Type</entry><entry>Description</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>accessType</entry><entry>String</entry><entry>The type of access to apply. One of:</entry></row><row><entry /><entry /><entry>READ</entry></row><row><entry /><entry /><entry>WRITE</entry></row><row><entry /><entry /><entry>EXECUTE</entry></row><row><entry /><entry /><entry>ALL (default)</entry></row><row><entry>permission</entry><entry>String</entry><entry>Type of permission granted. Required.</entry></row><row><entry /><entry /><entry>One of:</entry></row><row><entry /><entry /><entry>ALARM - Generate an alarm, in a system</entry></row><row><entry /><entry /><entry> dependent way, the access specified in</entry></row><row><entry /><entry /><entry> the permissions component of the ACL</entry></row><row><entry /><entry /><entry> entry.</entry></row><row><entry /><entry /><entry>ALLOW - Explicitly grants access to the</entry></row><row><entry /><entry /><entry>resource.</entry></row><row><entry /><entry /><entry>AUDIT - Log, in a system dependent way,</entry></row><row><entry /><entry /><entry> the access specified in the permissions</entry></row><row><entry /><entry /><entry> component of the ACL entry.</entry></row><row><entry /><entry /><entry>DENY - Explicitly denies access to the</entry></row><row><entry /><entry /><entry> resource.</entry></row><row><entry>principalId</entry><entry>String</entry><entry>Principal identifier. Required.</entry></row><row><entry /><entry /><entry>The value must be one of:</entry></row><row><entry /><entry /><entry>A user ID (String|number|any)</entry></row><row><entry /><entry /><entry>One of the following predefined dynamic</entry></row><row><entry /><entry /><entry>roles:</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="98pt" align="left" /><colspec colname="2" colwidth="119pt" align="left" /><tbody valign="top"><row><entry /><entry>$everyone - Everyone</entry></row><row><entry /><entry>$owner - Owner of the object</entry></row><row><entry /><entry>$related - Any user with a relationship</entry></row><row><entry /><entry>to the object</entry></row><row><entry /><entry>$authenticated - Authenticated user</entry></row><row><entry /><entry>$unauthenticated - Unauthenticated user</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="1" colwidth="56pt" align="left" /><colspec colname="2" colwidth="28pt" align="left" /><colspec colname="3" colwidth="133pt" align="left" /><tbody valign="top"><row><entry /><entry /><entry>A static role name</entry></row><row><entry>principalType</entry><entry>String</entry><entry>Type of the principal. Required.</entry></row><row><entry /><entry /><entry>One of:</entry></row><row><entry /><entry /><entry>Application</entry></row><row><entry /><entry /><entry>User</entry></row><row><entry /><entry /><entry>Role</entry></row><row><entry>property</entry><entry /><entry>Specifies a property/method/relation on a</entry></row><row><entry /><entry /><entry>given model. It further constrains where the</entry></row><row><entry /><entry /><entry>ACL applies.</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0072A scopes key enables a developer to specify commonly-used queries that the developer can reference as method calls on a model. The scopes key defines one or more scopes (named queries) for models. A scope key maps a name to a predefined filter object to be used by the model's find( ) method, for example:

0000<tables id="TABLE-US-00018" num="00018"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="42pt" align="left" /><colspec colname="1" colwidth="175pt" align="left" /><thead><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>“scopes”: {</entry></row><row><entry /><entry>  “vips”: {“where”: {“vip”: true}},</entry></row><row><entry /><entry>  “top5”: {“limit”: 5, “order”: “age”}</entry></row><row><entry /><entry>}</entry></row><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0073The snippet above defines two named queries for the model: <ul id="ul0003" list-style="none"><li id="ul0003-0001" num="0000"><ul id="ul0004" list-style="none"><li id="ul0004-0001" num="0074">vips: Find all model instances with vip flag set to true</li><li id="ul0004-0002" num="0075">top5: Find top five model instances ordered by age</li></ul></li></ul>

0076Within the scopes object, the keys are the names, and each value defines a filter object. In some embodiments, a developer can also define a scope programmatically using a model's scope( ) method, for example:

0000<tables id="TABLE-US-00019" num="00019"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="42pt" align="left" /><colspec colname="1" colwidth="175pt" align="left" /><thead><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>User.scope(‘vips’, {where: {vip: true});</entry></row><row><entry /><entry>User.scope(‘top5’: {limit: 5, order: ‘age’});</entry></row><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0077A developer can call the methods defined by the scopes in some embodiments. For example:

0000<tables id="TABLE-US-00020" num="00020"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="63pt" align="left" /><colspec colname="1" colwidth="154pt" align="left" /><thead><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>User.vips(function(err, vips) {</entry></row><row><entry /><entry>...</entry></row><row><entry /><entry>});</entry></row><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0078Methods key in the JSON file allows a developer to declare remote methods in the JSON file. Also, indexes can be declared for a model with the “indexes” option. One example of declaring indexes is as follows:

0000<tables id="TABLE-US-00021" num="00021"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="56pt" align="left" /><colspec colname="1" colwidth="161pt" align="left" /><thead><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>“indexes”: {</entry></row><row><entry /><entry> “name_age_index”: {</entry></row><row><entry /><entry>  “keys”: {“name”: 1, “age”: −1}</entry></row><row><entry /><entry> },</entry></row><row><entry /><entry> “age_index”: {“age”: −1}</entry></row><row><entry /><entry>}</entry></row><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0079The snippet above creates two indexes for the declaring model: (1) a composite index named ‘name_age_index’ with two keys: ‘name’ in ascending order and ‘age’ in descending order and (2) a simple index named ‘age_index’ with one key: ‘age’ in descending order. The full syntax for an index within the ‘indexes’ is:

0000<tables id="TABLE-US-00022" num="00022"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="77pt" align="left" /><colspec colname="1" colwidth="140pt" align="left" /><thead><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>“<indexName>”: {</entry></row><row><entry /><entry> “keys”: {</entry></row><row><entry /><entry>  “<key1>”: 1,</entry></row><row><entry /><entry>  “<key2>”: −1</entry></row><row><entry /><entry> },</entry></row><row><entry /><entry> “options”: {</entry></row><row><entry /><entry>  “unique”: true</entry></row><row><entry /><entry> }</entry></row><row><entry /><entry>}</entry></row><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0080In this syntax, ‘1’ specifies ‘ascending’ while ‘−1’ specifies ‘descending’. If no ‘options’ are needed, developer can use a shortened form:

0000<tables id="TABLE-US-00023" num="00023"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="77pt" align="left" /><colspec colname="1" colwidth="140pt" align="left" /><thead><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>“<indexName>”: {</entry></row><row><entry /><entry> “<key1>”: 1,</entry></row><row><entry /><entry> “<key2>”: −1</entry></row><row><entry /><entry>}</entry></row><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0081Indexes can be marked at model property level too, for example:

0000<tables id="TABLE-US-00024" num="00024"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="35pt" align="left" /><colspec colname="1" colwidth="182pt" align="left" /><thead><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>{</entry></row><row><entry /><entry> “name”: { “type”: “String”, “index”: true },</entry></row><row><entry /><entry> “email”: { “type”: “String”, “index”: {“unique”:</entry></row><row><entry /><entry>true} },</entry></row><row><entry /><entry> “age”: “Number”</entry></row><row><entry /><entry>}</entry></row><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0082Two indexes will be created, one for the ‘name’ key and another one for the ‘email’ key. The ‘email’ index is unique.

0083As mentioned above, one model can be defined by extending another model. The model that extends from another model will “inherit” properties and methods of the other “base” model. The following snippet provides an example of a model being extended from another.

0000<tables id="TABLE-US-00025" num="00025"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="35pt" align="left" /><colspec colname="1" colwidth="182pt" align="left" /><thead><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>var properties = {</entry></row><row><entry /><entry> firstName: {type: String, required: true}</entry></row><row><entry /><entry> };</entry></row><row><entry /><entry>var options = {</entry></row><row><entry /><entry> relations: {</entry></row><row><entry /><entry>  accessTokens: {</entry></row><row><entry /><entry>   model: accessToken,</entry></row><row><entry /><entry>   type: hasMany,</entry></row><row><entry /><entry>   foreignKey: userId</entry></row><row><entry /><entry>  },</entry></row><row><entry /><entry>  account: {</entry></row><row><entry /><entry>   model: account,</entry></row><row><entry /><entry>   type: belongsTo</entry></row><row><entry /><entry>  },</entry></row><row><entry /><entry>  transactions: {</entry></row><row><entry /><entry>   model: transaction,</entry></row><row><entry /><entry>   type: hasMany</entry></row><row><entry /><entry>  }</entry></row><row><entry /><entry> },</entry></row><row><entry /><entry> acls: [</entry></row><row><entry /><entry>  {</entry></row><row><entry /><entry>   permission: ALLOW,</entry></row><row><entry /><entry>   principalType: ROLE,</entry></row><row><entry /><entry>   principalId: $everyone,</entry></row><row><entry /><entry>   property: myMethod</entry></row><row><entry /><entry>  }</entry></row><row><entry /><entry> ]</entry></row><row><entry /><entry>};</entry></row><row><entry /><entry>var user = loopback.Model.extend(‘user’, properties,</entry></row><row><entry /><entry>options);</entry></row><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0084The validation class Validatable, of the framework of some embodiments will now be described. This class provides methods that add validation capabilities to models. Each of this validations run when an obj.isValid( ) method is called. Each configurator can accept n parameters (n−1 field names and one config). “Config is {Object}” depends on specific validation, but all of them have a message member property. It can be just string, when only one situation is possible, e.g., Post.validatesPresenceOf(‘title’, {message: ‘can not be blank’}). In more complicated cases it can be {Hash} of messages (for each case): User.validatesLengthOf(‘password’, {min: 6, max: 20, message: {min: ‘too short’, max: ‘too long’}}).

0085The validation class methods in some embodiments include: <ul id="ul0005" list-style="none"><li id="ul0005-0001" num="0000"><ul id="ul0006" list-style="none"><li id="ul0006-0001" num="0086">Validatable.validatesPresenceOf</li><li id="ul0006-0002" num="0087">Validatable.validatesAbsenceOf</li><li id="ul0006-0003" num="0088">Validatable.validatesLengthOf</li><li id="ul0006-0004" num="0089">Validatable.validatesNumericalityOf</li><li id="ul0006-0005" num="0090">Validatable.validatesInclusionOf</li><li id="ul0006-0006" num="0091">Validatable.validatesExclusionOf</li><li id="ul0006-0007" num="0092">Validatable.validatesFormatOf</li><li id="ul0006-0008" num="0093">Validatable.validate</li><li id="ul0006-0009" num="0094">Validatable.validateAsync</li><li id="ul0006-0010" num="0095">Validatable.validatesUniquenessOf</li><li id="ul0006-0011" num="0096">validatable.isValid</li><li id="ul0006-0012" num="0097">ValidationError</li></ul></li></ul>

0098The Validatable.validatesPresenceOf method validates the presence of one or more specified properties. This method requires a model to include a property to be considered valid. The method fails when validated field is blank. For example, <ul id="ul0007" list-style="none"><li id="ul0007-0001" num="0000"><ul id="ul0008" list-style="none"><li id="ul0008-0001" num="0099">Post.validatesPresenceOf(‘title’) validates presence of title.</li><li id="ul0008-0002" num="0100">Post.validatesPresenceOf(‘title’, {message: ‘Cannot be blank’}) provides an example with a custom message</li><li id="ul0008-0003" num="0101">User.validatesPresenceOf(‘first’, ‘last’, ‘age’) validates that model has first, last, and age properties:</li></ul></li></ul>

0102The Validatable.validatesPresenceOf method of some embodiments has arguments and error messages as illustrated in the following tables:

0000<tables id="TABLE-US-00026" num="00026"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="center" /><tbody valign="top"><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>Arguments</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="1" colwidth="56pt" align="left" /><colspec colname="2" colwidth="28pt" align="left" /><colspec colname="3" colwidth="133pt" align="left" /><tbody valign="top"><row><entry>Name</entry><entry>Type</entry><entry>Description</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row><row><entry>propertyName</entry><entry>String</entry><entry>One or more property names.</entry></row><row><entry>errMsg</entry><entry>Object</entry><entry>Optional custom error message. Default is</entry></row><row><entry /><entry /><entry>“can't be blank”</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0000<tables id="TABLE-US-00027" num="00027"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="center" /><tbody valign="top"><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>errMsg</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="4"><colspec colname="1" colwidth="14pt" align="left" /><colspec colname="2" colwidth="35pt" align="left" /><colspec colname="3" colwidth="35pt" align="left" /><colspec colname="4" colwidth="133pt" align="left" /><tbody valign="top"><row><entry /><entry>Name</entry><entry>Type</entry><entry>Description</entry></row><row><entry namest="1" nameend="4" align="center" rowsep="1" /></row><row><entry /><entry>message</entry><entry>String</entry><entry>Error message to use instead of default.</entry></row><row><entry namest="1" nameend="4" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0103Validatable.validatesAbsenceOf method validates absence of one or more specified properties. This method specifies that a model should not include a property to be considered valid. The Validatable.validatesAbsenceOf method fails when validated field is not blank. For example, Post.validatesAbsenceOf(‘reserved’, {unless: ‘special’}), validates absence of reserved.

0104The Validatable.validatesAbsenceOf method of some embodiments has arguments and error messages as illustrated in the following tables:

0000<tables id="TABLE-US-00028" num="00028"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="center" /><tbody valign="top"><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>Arguments</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="1" colwidth="56pt" align="left" /><colspec colname="2" colwidth="28pt" align="left" /><colspec colname="3" colwidth="133pt" align="left" /><tbody valign="top"><row><entry>Name</entry><entry>Type</entry><entry>Description</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row><row><entry>propertyName</entry><entry>String</entry><entry>One or more property names.</entry></row><row><entry>errMsg</entry><entry>Object</entry><entry>Optional custom error message. Default is</entry></row><row><entry /><entry /><entry>“can't be set”</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0000<tables id="TABLE-US-00029" num="00029"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="center" /><tbody valign="top"><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>errMsg</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="4"><colspec colname="1" colwidth="14pt" align="left" /><colspec colname="2" colwidth="35pt" align="left" /><colspec colname="3" colwidth="35pt" align="left" /><colspec colname="4" colwidth="133pt" align="left" /><tbody valign="top"><row><entry /><entry>Name</entry><entry>Type</entry><entry>Description</entry></row><row><entry namest="1" nameend="4" align="center" rowsep="1" /></row><row><entry /><entry>message</entry><entry>String</entry><entry>Error message to use instead of default.</entry></row><row><entry namest="1" nameend="4" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0105Validatable.validatesLengthOf method validates the length of a property. This method requires a property length to be within a specified range. In some embodiments, the Validatable.validatesLengthOf method receives the minimum range of a property (min), the maximum range of the property (max), or the precise length of the property (is). This method returns the following default error messages: <ul id="ul0009" list-style="none"><li id="ul0009-0001" num="0000"><ul id="ul0010" list-style="none"><li id="ul0010-0001" num="0106">If the length is less than minimum, the method returns min: too short,</li><li id="ul0010-0002" num="0107">If the length is more than maximum, the method returns max: too long, and</li><li id="ul0010-0003" num="0108">If the length is not equal to the received range, the method returns length is wrong</li></ul></li></ul>

0109Below are a few examples of how a developer can use the Validatable.validatesLengthOf method for a class (model) named “User.” In the following example the method returns one of the above default error messages if an error occur: <ul id="ul0011" list-style="none"><li id="ul0011-0001" num="0000"><ul id="ul0012" list-style="none"><li id="ul0012-0001" num="0110">User.validatesLengthOf(‘password’, {min: 7});</li><li id="ul0012-0002" num="0111">User.validatesLengthOf(‘email’, {max: 100});</li><li id="ul0012-0003" num="0112">User.validatesLengthOf(‘state’, {is: 2});</li><li id="ul0012-0004" num="0113">User.validatesLengthOf(‘nick’, {min: 3, max: 15});</li></ul></li></ul>

0114A couple of more examples, for which the length validation method returns custom error messages, are as follows: <ul id="ul0013" list-style="none"><li id="ul0013-0001" num="0000"><ul id="ul0014" list-style="none"><li id="ul0014-0001" num="0115">User.validatesLengthOf(‘password’, {min: 7, message: {min: ‘too weak’}});</li><li id="ul0014-0002" num="0116">User.validatesLengthOf(‘state’, {is: 2, message: {is: ‘is not valid state name’}});</li></ul></li></ul>

0117The Validatable.validatesLengthOf method of some embodiments has arguments and options as illustrated in the following tables:

0000<tables id="TABLE-US-00030" num="00030"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="center" /><tbody valign="top"><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>Arguments</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="4"><colspec colname="1" colwidth="14pt" align="left" /><colspec colname="2" colwidth="63pt" align="left" /><colspec colname="3" colwidth="42pt" align="left" /><colspec colname="4" colwidth="98pt" align="left" /><tbody valign="top"><row><entry /><entry>Name</entry><entry>Type</entry><entry>Description</entry></row><row><entry namest="1" nameend="4" align="center" rowsep="1" /></row><row><entry /><entry>propertyName</entry><entry>String</entry><entry>Property name to validate.</entry></row><row><entry /><entry>Options</entry><entry>Object</entry></row><row><entry namest="1" nameend="4" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0000<tables id="TABLE-US-00031" num="00031"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="center" /><tbody valign="top"><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>Options</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="4"><colspec colname="1" colwidth="14pt" align="left" /><colspec colname="2" colwidth="35pt" align="left" /><colspec colname="3" colwidth="35pt" align="left" /><colspec colname="4" colwidth="133pt" align="left" /><tbody valign="top"><row><entry /><entry>Name</entry><entry>Type</entry><entry>Description</entry></row><row><entry namest="1" nameend="4" align="center" rowsep="1" /></row><row><entry /><entry>is</entry><entry>Number</entry><entry>Value that property must equal to validate.</entry></row><row><entry /><entry>min</entry><entry>Number</entry><entry>Value that property must be less than to be</entry></row><row><entry /><entry /><entry /><entry>valid.</entry></row><row><entry /><entry>max</entry><entry>Number</entry><entry>Value that property must be less than to be</entry></row><row><entry /><entry /><entry /><entry>valid.</entry></row><row><entry /><entry>message</entry><entry>Object</entry><entry>Optional Object with string properties for</entry></row><row><entry /><entry /><entry /><entry>custom error message for each validation:</entry></row><row><entry /><entry /><entry /><entry>is, min, or max</entry></row><row><entry namest="1" nameend="4" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0118Validatable.validatesNumericalityOf method validates numericality of a property (i.e., whether the property is numerical or not). The method requires a value for property to be either an integer or number. The examples for this method are as follows: <ul id="ul0015" list-style="none"><li id="ul0015-0001" num="0000"><ul id="ul0016" list-style="none"><li id="ul0016-0001" num="0119">User.validatesNumericalityOf(‘age’, {message: {number: ‘ . . . ’}});</li><li id="ul0016-0002" num="0120">User.validatesNumericalityOf(‘age’, {int: true, message: {int: ‘ . . . ’}});</li></ul></li></ul>

0121The Validatable.validatesNumericalityOf method of some embodiments includes the following arguments and options:

0000<tables id="TABLE-US-00032" num="00032"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="center" /><tbody valign="top"><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>Arguments</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="4"><colspec colname="1" colwidth="14pt" align="left" /><colspec colname="2" colwidth="63pt" align="left" /><colspec colname="3" colwidth="42pt" align="left" /><colspec colname="4" colwidth="98pt" align="left" /><tbody valign="top"><row><entry /><entry>Name</entry><entry>Type</entry><entry>Description</entry></row><row><entry namest="1" nameend="4" align="center" rowsep="1" /></row><row><entry /><entry>propertyName</entry><entry>String</entry><entry>Property name to validate.</entry></row><row><entry /><entry>Options</entry><entry>Object</entry></row><row><entry namest="1" nameend="4" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0000<tables id="TABLE-US-00033" num="00033"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="center" /><tbody valign="top"><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>Options</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="1" colwidth="35pt" align="left" /><colspec colname="2" colwidth="28pt" align="left" /><colspec colname="3" colwidth="154pt" align="left" /><tbody valign="top"><row><entry>Name</entry><entry>Type</entry><entry>Description</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row><row><entry>int</entry><entry>Boolean</entry><entry>If true, then property must be an integer to be valid.</entry></row><row><entry>message</entry><entry>Object</entry><entry>Optional object with string properties for ‘int’</entry></row><row><entry /><entry /><entry>for integer validation. Default error messages: -</entry></row><row><entry /><entry /><entry>number: is not a number</entry></row><row><entry /><entry /><entry>int: is not an integer</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0122Validatable.validatesInclusionOf method validates the inclusion of a property in a set of values. The method requires a value for property to be in a specified array. For example: <ul id="ul0017" list-style="none"><li id="ul0017-0001" num="0000"><ul id="ul0018" list-style="none"><li id="ul0018-0001" num="0123">User.validatesInclusionOf(‘gender’, {in: [‘male’, ‘female’]}), validates the gender to be either male or female.</li><li id="ul0018-0002" num="0124">User.validatesInclusionOf(‘role’, {in: [‘admin’, ‘moderator’, ‘user’], message: ‘is not allowed’}), validates that the user be an admin, moderator, or user, or else returns the error message “is not allowed.”</li></ul></li></ul>

0125The Validatable.validatesInclusionOf method of some embodiments includes the following arguments and options:

0000<tables id="TABLE-US-00034" num="00034"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="center" /><tbody valign="top"><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>Arguments</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="4"><colspec colname="1" colwidth="14pt" align="left" /><colspec colname="2" colwidth="63pt" align="left" /><colspec colname="3" colwidth="42pt" align="left" /><colspec colname="4" colwidth="98pt" align="left" /><tbody valign="top"><row><entry /><entry>Name</entry><entry>Type</entry><entry>Description</entry></row><row><entry namest="1" nameend="4" align="center" rowsep="1" /></row><row><entry /><entry>propertyName</entry><entry>String</entry><entry>Property name to validate.</entry></row><row><entry /><entry>Options</entry><entry>Object</entry></row><row><entry namest="1" nameend="4" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0000<tables id="TABLE-US-00035" num="00035"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="center" /><tbody valign="top"><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>Options</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="1" colwidth="35pt" align="left" /><colspec colname="2" colwidth="28pt" align="left" /><colspec colname="3" colwidth="154pt" align="left" /><tbody valign="top"><row><entry>Name</entry><entry>Type</entry><entry>Description</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row><row><entry>in</entry><entry>Array</entry><entry>Array Property must match one of the values in the</entry></row><row><entry /><entry /><entry>array to be valid.</entry></row><row><entry>message</entry><entry>String</entry><entry>Optional error message if property is not valid.</entry></row><row><entry /><entry /><entry>Default error message: “is not included in the list”.</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0126Validatable.validatesExclusionOf method validates the exclusion of a property. The method requires a property value not to be in a specified array. For example, Company.validatesExclusionOf(‘domain’, {in: [‘www’, ‘admin’]}), validates that domain should not be an admin domain.

0127The Validatable.validatesExclusionOf method of some embodiments includes the following arguments and options:

0000<tables id="TABLE-US-00036" num="00036"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="center" /><tbody valign="top"><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>Arguments</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="4"><colspec colname="offset" colwidth="14pt" align="left" /><colspec colname="1" colwidth="63pt" align="left" /><colspec colname="2" colwidth="42pt" align="left" /><colspec colname="3" colwidth="98pt" align="left" /><tbody valign="top"><row><entry /><entry>Name</entry><entry>Type</entry><entry>Description</entry></row><row><entry /><entry namest="offset" nameend="3" align="center" rowsep="1" /></row><row><entry /><entry>propertyName</entry><entry>String</entry><entry>Property name to validate.</entry></row><row><entry /><entry>Options</entry><entry>Object</entry></row><row><entry /><entry namest="offset" nameend="3" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0000<tables id="TABLE-US-00037" num="00037"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="center" /><tbody valign="top"><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>Options</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="1" colwidth="35pt" align="left" /><colspec colname="2" colwidth="35pt" align="left" /><colspec colname="3" colwidth="147pt" align="left" /><tbody valign="top"><row><entry>Name</entry><entry>Type</entry><entry>Description</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row><row><entry>in</entry><entry>Array</entry><entry>Array Property must match one of the values in</entry></row><row><entry /><entry /><entry>the array to be valid.</entry></row><row><entry>message</entry><entry>String</entry><entry>Optional error message if property is not valid.</entry></row><row><entry /><entry /><entry>Default error message: “is reserved”.</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0128Validatable.validatesFormatOf method validates the format of a property. The method requires a model to include a property that matches the given format. An example for this method is: User.validatesFormat(‘name’, {with: /\w+/}).

0129The Validatable.validatesFormatOf method of some embodiments includes the following arguments and options:

0000<tables id="TABLE-US-00038" num="00038"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="center" /><tbody valign="top"><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>Arguments</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="4"><colspec colname="offset" colwidth="14pt" align="left" /><colspec colname="1" colwidth="63pt" align="left" /><colspec colname="2" colwidth="42pt" align="left" /><colspec colname="3" colwidth="98pt" align="left" /><tbody valign="top"><row><entry /><entry>Name</entry><entry>Type</entry><entry>Description</entry></row><row><entry /><entry namest="offset" nameend="3" align="center" rowsep="1" /></row><row><entry /><entry>propertyName</entry><entry>String</entry><entry>Property name to validate.</entry></row><row><entry /><entry>Options</entry><entry>Object</entry></row><row><entry /><entry namest="offset" nameend="3" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0000<tables id="TABLE-US-00039" num="00039"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="center" /><tbody valign="top"><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>Options</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="1" colwidth="35pt" align="left" /><colspec colname="2" colwidth="35pt" align="left" /><colspec colname="3" colwidth="147pt" align="left" /><tbody valign="top"><row><entry>Name</entry><entry>Type</entry><entry>Description</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row><row><entry>with</entry><entry>RegExp</entry><entry>Regular expression to validate format.</entry></row><row><entry>message</entry><entry>String</entry><entry>Optional error message if property is not valid.</entry></row><row><entry /><entry /><entry>Default error message: “ is invalid”.</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0130Validatable.validate method validates properties using a custom validator. The default error message that this method returns in some embodiments is “is invalid.” Below is an example of using this validation method:

0000<tables id="TABLE-US-00040" num="00040"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="14pt" align="left" /><colspec colname="1" colwidth="203pt" align="left" /><thead><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>User.validate(‘name’, customValidator, {message: ‘Bad name’});</entry></row><row><entry /><entry>function customValidator(err) {</entry></row><row><entry /><entry> if (this.name === ‘bad’) err( );</entry></row><row><entry /><entry>});</entry></row><row><entry /><entry>var user = new User({name: ‘Peter’});</entry></row><row><entry /><entry>user.isValid( ); // true</entry></row><row><entry /><entry>user.name = ‘bad’;</entry></row><row><entry /><entry>user.isValid( ); // false</entry></row><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0131Validatable.validateAsync method validates properties using a custom async validator. The default error message that this method returns in some embodiments is “is invalid.” Below is an example of using this validation method:

0000<tables id="TABLE-US-00041" num="00041"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="left" /><thead><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>User.validateAsync(‘name’, customValidator, {message: ‘Bad name’});</entry></row><row><entry> function customValidator(err, done) {</entry></row><row><entry>  process.nextTick(function ( ) {</entry></row><row><entry>   if (this.name === ‘bad’) err( );</entry></row><row><entry>   done( );</entry></row><row><entry>  });</entry></row><row><entry> });</entry></row><row><entry> var user = new User({name: ‘Peter’});</entry></row><row><entry> user.isValid( ); // false (because async validation setup)</entry></row><row><entry> user.isValid(function (isValid) {</entry></row><row><entry>  isValid; // true</entry></row><row><entry> })</entry></row><row><entry> user.name = ‘bad’;</entry></row><row><entry> user.isValid( ); // false</entry></row><row><entry> user.isValid(function (isValid) {</entry></row><row><entry>  isValid; // false</entry></row><row><entry>})</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0132Validatable.validatesUniquenessOf method validates uniqueness. In other words, this method ensures that the value of the property is unique in a collection of models. Below is an example of using this validation method:

0133//The login must be unique across all User instances.

0134User.validatesUniquenessOf(‘login’);

0135//Assuming SiteUser.belongsTo(Site)

0136//The login must be unique within each Site.

0137SiteUser.validateUniquenessOf(‘login’, {scopedTo: [‘siteId’]});

0138The Validatable.validatesUniquenessOf method of some embodiments includes the following arguments and options:

0000<tables id="TABLE-US-00042" num="00042"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="center" /><tbody valign="top"><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>Arguments</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="4"><colspec colname="offset" colwidth="14pt" align="left" /><colspec colname="1" colwidth="63pt" align="left" /><colspec colname="2" colwidth="42pt" align="left" /><colspec colname="3" colwidth="98pt" align="left" /><tbody valign="top"><row><entry /><entry>Name</entry><entry>Type</entry><entry>Description</entry></row><row><entry /><entry namest="offset" nameend="3" align="center" rowsep="1" /></row><row><entry /><entry>propertyName</entry><entry>String</entry><entry>Property name to validate.</entry></row><row><entry /><entry>Options</entry><entry>Object</entry></row><row><entry /><entry namest="offset" nameend="3" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0000<tables id="TABLE-US-00043" num="00043"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="center" /><tbody valign="top"><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>Options</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="1" colwidth="42pt" align="left" /><colspec colname="2" colwidth="49pt" align="left" /><colspec colname="3" colwidth="126pt" align="left" /><tbody valign="top"><row><entry>Name</entry><entry>Type</entry><entry>Description</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row><row><entry>with</entry><entry>RegExp</entry><entry>Regular expression to validate format.</entry></row><row><entry>scopedTo</entry><entry>Array.<String></entry><entry>List of properties defining the scope.</entry></row><row><entry>message</entry><entry>String</entry><entry>Optional error message if property is</entry></row><row><entry /><entry /><entry>not valid.</entry></row><row><entry /><entry /><entry>Default error message: “is not unique”.</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0139Validatable.isValid(callback) method performs validation and triggers validation hooks in some embodiments. In some embodiments, before validation, the obj.errors collection is cleaned. Each validation then can add new errors to obj.errors collection. If collection is not blank, validation has failed. In some embodiments, this method can be called as synchronous only when no asynchronous validation is configured. Below is an example of using this validation method:

0000<tables id="TABLE-US-00044" num="00044"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="left" /><thead><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>ExpressJS controller: render user if valid, show flash otherwise</entry></row><row><entry>user.isValid(function (valid) {</entry></row><row><entry> if (valid) res.render({user: user});</entry></row><row><entry> else res.flash(‘error’, ‘User is not valid’), console.log(user.errors),</entry></row><row><entry> res.redirect(‘/users’);</entry></row><row><entry>});</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0140Another example:

0000<tables id="TABLE-US-00045" num="00045"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="21pt" align="left" /><colspec colname="1" colwidth="196pt" align="left" /><thead><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>user.isValid(function (valid) {</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="35pt" align="left" /><colspec colname="1" colwidth="182pt" align="left" /><tbody valign="top"><row><entry /><entry>if (!valid) {</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="63pt" align="left" /><colspec colname="1" colwidth="154pt" align="left" /><tbody valign="top"><row><entry /><entry>console.log(user.errors);</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="49pt" align="left" /><colspec colname="1" colwidth="168pt" align="left" /><tbody valign="top"><row><entry /><entry>// => hash of errors</entry></row><row><entry /><entry>// => {</entry></row><row><entry /><entry>// => username: [errmessage, errmessage, ...],</entry></row><row><entry /><entry>// => email: ...</entry></row><row><entry /><entry>// => }</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="35pt" align="left" /><colspec colname="1" colwidth="182pt" align="left" /><tbody valign="top"><row><entry /><entry>}</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="21pt" align="left" /><colspec colname="1" colwidth="196pt" align="left" /><tbody valign="top"><row><entry /><entry>});</entry></row><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0141The validatable.isValid(callback) method of some embodiments includes the following arguments and returns:

0000<tables id="TABLE-US-00046" num="00046"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="center" /><tbody valign="top"><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>Arguments</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="4"><colspec colname="offset" colwidth="21pt" align="left" /><colspec colname="1" colwidth="56pt" align="left" /><colspec colname="2" colwidth="56pt" align="left" /><colspec colname="3" colwidth="84pt" align="left" /><tbody valign="top"><row><entry /><entry>Name</entry><entry>Type</entry><entry>Description</entry></row><row><entry /><entry namest="offset" nameend="3" align="center" rowsep="1" /></row><row><entry /><entry>callback</entry><entry>Function</entry><entry>called with (valid)</entry></row><row><entry /><entry namest="offset" nameend="3" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0000<tables id="TABLE-US-00047" num="00047"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="center" /><tbody valign="top"><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>Returns</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="1" colwidth="28pt" align="left" /><colspec colname="2" colwidth="35pt" align="left" /><colspec colname="3" colwidth="154pt" align="left" /><tbody valign="top"><row><entry>Name</entry><entry>Type</entry><entry>Description</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row><row><entry>result</entry><entry>Boolean</entry><entry>True if no asynchronouse validation is configured</entry></row><row><entry /><entry /><entry>and all properties pass validation.</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0142ValidationError( ) method is raised when the application attempts to save an invalid model instance. Below is an example of using this validation method:

0000<tables id="TABLE-US-00048" num="00048"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="21pt" align="left" /><colspec colname="1" colwidth="196pt" align="left" /><thead><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>{</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="35pt" align="left" /><colspec colname="1" colwidth="182pt" align="left" /><tbody valign="top"><row><entry /><entry>“name”: “ValidationError”,</entry></row><row><entry /><entry>“status”: 422,</entry></row><row><entry /><entry>“message”: “The Model instance is not valid. \</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="21pt" align="left" /><colspec colname="1" colwidth="196pt" align="left" /><tbody valign="top"><row><entry /><entry> See {grave over ( )}details{grave over ( )} property of the error object for more info.”,</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="35pt" align="left" /><colspec colname="1" colwidth="182pt" align="left" /><tbody valign="top"><row><entry /><entry>“statusCode”: 422,</entry></row><row><entry /><entry>“details”: {</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="63pt" align="left" /><colspec colname="1" colwidth="154pt" align="left" /><tbody valign="top"><row><entry /><entry>“context”: “user”,</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="49pt" align="left" /><colspec colname="1" colwidth="168pt" align="left" /><tbody valign="top"><row><entry /><entry>“codes”: {</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="77pt" align="left" /><colspec colname="1" colwidth="140pt" align="left" /><tbody valign="top"><row><entry /><entry>“password”: [</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="105pt" align="left" /><colspec colname="1" colwidth="112pt" align="left" /><tbody valign="top"><row><entry /><entry>“presence”</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="77pt" align="left" /><colspec colname="1" colwidth="140pt" align="left" /><tbody valign="top"><row><entry /><entry>],</entry></row><row><entry /><entry>“email”: [</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="105pt" align="left" /><colspec colname="1" colwidth="112pt" align="left" /><tbody valign="top"><row><entry /><entry>“uniqueness”</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="77pt" align="left" /><colspec colname="1" colwidth="140pt" align="left" /><tbody valign="top"><row><entry /><entry>]</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="49pt" align="left" /><colspec colname="1" colwidth="168pt" align="left" /><tbody valign="top"><row><entry /><entry>},</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="63pt" align="left" /><colspec colname="1" colwidth="154pt" align="left" /><tbody valign="top"><row><entry /><entry>“messages”: {</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="77pt" align="left" /><colspec colname="1" colwidth="140pt" align="left" /><tbody valign="top"><row><entry /><entry>“password”: [</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="91pt" align="left" /><colspec colname="1" colwidth="126pt" align="left" /><tbody valign="top"><row><entry /><entry>“can’t be blank”</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="63pt" align="left" /><colspec colname="1" colwidth="154pt" align="left" /><tbody valign="top"><row><entry /><entry>],</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="77pt" align="left" /><colspec colname="1" colwidth="140pt" align="left" /><tbody valign="top"><row><entry /><entry>“email”: [</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="105pt" align="left" /><colspec colname="1" colwidth="112pt" align="left" /><tbody valign="top"><row><entry /><entry>“Email already exists”</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="77pt" align="left" /><colspec colname="1" colwidth="140pt" align="left" /><tbody valign="top"><row><entry /><entry>]</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="63pt" align="left" /><colspec colname="1" colwidth="154pt" align="left" /><tbody valign="top"><row><entry /><entry>}</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="35pt" align="left" /><colspec colname="1" colwidth="182pt" align="left" /><tbody valign="top"><row><entry /><entry>},</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="21pt" align="left" /><colspec colname="1" colwidth="196pt" align="left" /><tbody valign="top"><row><entry /><entry>}</entry></row><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0143A developer might run into situations the developer needs to raise a validation error and not rely on the system to raise the ValidationError( ). An example of such a situation is in a “before” hook or a custom model method. Below is an example of rasing this method manually:

0000<tables id="TABLE-US-00049" num="00049"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="14pt" align="left" /><colspec colname="1" colwidth="203pt" align="left" /><thead><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>MyModel.prototype.preflight = function(changes, callback) {</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="28pt" align="left" /><colspec colname="1" colwidth="189pt" align="left" /><tbody valign="top"><row><entry /><entry>// Update properties, do not save to db</entry></row><row><entry /><entry>for (var key in changes) {</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="42pt" align="left" /><colspec colname="1" colwidth="175pt" align="left" /><tbody valign="top"><row><entry /><entry>model[key] = changes[key];</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="28pt" align="left" /><colspec colname="1" colwidth="189pt" align="left" /><tbody valign="top"><row><entry /><entry>}</entry></row><row><entry /><entry>if (model.isValid( )) {</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="42pt" align="left" /><colspec colname="1" colwidth="175pt" align="left" /><tbody valign="top"><row><entry /><entry>return callback(null, { success: true });</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="28pt" align="left" /><colspec colname="1" colwidth="189pt" align="left" /><tbody valign="top"><row><entry /><entry>}</entry></row><row><entry /><entry>// This line shows how to create a ValidationError</entry></row><row><entry /><entry>err = new ValidationError(model);</entry></row><row><entry /><entry>callback(err);</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="14pt" align="left" /><colspec colname="1" colwidth="203pt" align="left" /><tbody valign="top"><row><entry /><entry>}</entry></row><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0144<figref idref="DRAWINGS">FIG. 4</figref> presents a process <b>400</b> that conceptually illustrates how a JavaScript model is defined in some embodiments of the invention. One of ordinary skill will realize that the operations illustrated in this figure can be performed in any variety of orders that differ from the order illustrated in this figure. The operational order is simply one order for performing these operations.

0145As shown, the process <b>400</b> initially receives (at <b>405</b>) a declaration of the model. In some embodiments, the model is declared when a developer first names the model. Next, at <b>410</b>, the process constructs the model by defining a JSON file and a JS file for the model. In some embodiments, the process only defines a JSON file (at <b>410</b>) when the model is initially constructed. After the core model is constructed, the model in some embodiments can be designated as “common” or “abstract,” and then further sub-classed to client versus server, in order to achieve isomorphic capabilities from the beginning

0146After <b>410</b>, the process determines (at <b>415</b>) whether the user has requested the addition of a property to the JS model. If so, the process transitions to <b>420</b> to receive the property definition, and then transitions back to <b>410</b> to update the model's JSON file and/or JS file based on the received property definition. Several examples of adding properties to a model will be provided below. When the process determines (at <b>415</b>) that the user has not requested that a property be added to the JS model, the process transitions to <b>425</b>.

0147At <b>425</b>, the process determines whether the user has requested the addition of a validation rule(s) to the JS model. If so, the process transitions to <b>430</b> to receive the validation rule(s) definition, and then transitions back to <b>410</b> to update the model's JSON file and/or JS file based on the received validation definition. Several examples of adding validation rules to a model were provided above, and will be further described below. When the process determines (at <b>425</b>) that the user has not requested the addition of a validation rule to the JS model, the process transitions to <b>435</b>.

0148At <b>435</b>, the process determines whether the user has requested the addition of the ACL rule(s) to the JS model. If so, the process transitions to <b>440</b> to receive the ACL rule(s) definition, and then transitions back to <b>410</b> to update the model's JSON file and/or JS file based on the received ACL definition. Several examples of adding ACL rules to a model were provided above, and will be further described below. When the process determines (at <b>435</b>) that the user has not requested the addition of an ACL rule to the JS model, the process transitions to <b>445</b>.

0149At <b>445</b>, the process determines whether the user has requested the addition of a relations key to the JS model. If so, the process transitions to <b>450</b> to receive the relations key, and then transitions back to <b>410</b> to update the model's JSON file and/or JS file based on the received relations key. Several examples of adding relations rules to a model were provided above, and will be further described below. When the process determines (at <b>445</b>) that the user has not requested the addition of a relations rule to the JS model, the process transitions to <b>455</b>.

0150At <b>455</b>, the process determines whether the user has requested that the model be attached to a data source abstractor. As mentioned above, the data source abstractor in some embodiments enables a model to access and modify data in backend storages, such as a relational database. The data source abstractor encapsulates business logic to exchange data between models and various backend systems such as relational databases, REST APIs, SOAP web services, storage services, etc. Data source abstractors, in some embodiments, provide CRUD functions for backend data storages. As mentioned above, the data source abstractors connect the models to the data storages by using data storage connectors that are extensible and customizable. In some of these embodiments, the application code does not use a connector directly. Instead, the data source abstractor class provides an API to configure the underlying connector.

0151When the process determines (at <b>455</b>) that the user wishes to attach the model to a data source abstractor, the process transitions to <b>460</b> to receive the data source abstractor information, and then transitions back to <b>410</b> to update the model's JSON file and/or JS file based on the received data. Several examples of attaching a model to a data source abstractor will be described below. When the process determines (at <b>455</b>) that the user has not requested the attachment of the model to a data source abstractor, the process transitions to <b>465</b>.

0152At <b>465</b>, the process determines whether the user has requested the addition or modification of any other JS model attribute. Examples of such attributes include options, scopes, and indexes keys, which were described above. When the process determines (at <b>465</b>) that the user has requested the addition or modification of a JS model attribute, it transitions to <b>470</b> to receive the attribute description, and then transitions back to <b>410</b> to update the model's JSON file and/or JS file based on the received attribute description. Otherwise, the process transitions to <b>475</b> to determine whether the user has finished defining the model.

0153When the user has not finished defining the model, the process returns to <b>415</b> to process additional user input. Otherwise, the process designates (at <b>480</b>) the constructed JS model as a remotely-accessible model that can be accessed on the server by one or more other devices (e.g., client devices or severs), e.g., through a set of API requests. The process then ends. It should be noted that not all models that are created through a process like the process <b>400</b>, are designated for remote access in some embodiments. Such models can be created so that they can just be accessed locally on the server or locally on a client.

0154As mentioned above, a developer can order of the operations illustrated in <figref idref="DRAWINGS">FIG. 4</figref> in any number of arbitrary sequences, after performing operations <b>405</b> and <b>410</b> initially. Also, none of the operations following <b>410</b> are mandatory. As further described below, these operations can be done through a model generator of a framework, or they can be performed programmatically through the framework's API dynamically and on demand. The Appendix B portion of the incorporated ASCII text file computer program listing appendix provides the source code of a portion of the framework of some embodiments for defining JSON-based models.

0155<figref idref="DRAWINGS">FIG. 5</figref> illustrates a more-detailed view of a JavaScript API server <b>500</b> of some embodiments of the invention. This server can process API requests from a variety of devices, such as smartphones, tablets, client computers (e.g., laptops, desktops, etc.), server computers, and other devices. This server is similar to the server <b>100</b> of <figref idref="DRAWINGS">FIG. 1</figref>. Like the server <b>100</b>, the server <b>500</b> includes a runtime processor <b>105</b>, a data abstractor <b>110</b>, a data storage connector <b>115</b>, an API handler <b>120</b>, and an I/O manager <b>125</b>. Also, like server <b>100</b>, the API server <b>500</b> stores the description of multiple JavaScript models <b>135</b>, with each model defined in terms of a JavaScript file and a JSON file. In <figref idref="DRAWINGS">FIG. 5</figref>, the API handler <b>120</b> is shown to include a REST adapter <b>505</b> and a remote API handler <b>510</b>, while the I/O manager <b>125</b> is shown to include a socket handler <b>550</b> and an I/O handler <b>555</b>. Similarly, the runtime processor <b>105</b> is shown to include object instantiator <b>515</b>. Lastly, the API server <b>500</b> is shown to include a rule processing engine <b>520</b>, ACL/Validation rule data storage <b>525</b>, object linker <b>530</b>, and a replication manager <b>535</b>.

0156The runtime processor <b>105</b> in some embodiments instantiates a JavaScript object <b>150</b> for each model based on the object's description that is contained in its associated JavaScript model (i.e., its associated JaveScript file and JSON file). Once instantiated, the JavaScript object can be used to process API requests from client devices of the API server. To process API requests, the JS object might have to exchange data with one or more backend data storages <b>570</b>. As before, JS objects exchange data with backend data storages through the data source abstractor <b>110</b> and connector <b>115</b>, which, as mentioned above, allow the JS objects to exchange data with a variety of data storages, such as relational databases from different vendors, REST accessible data storages, SOAP accessible data storages, server memory, etc. JS objects also connect to the replication manager <b>535</b>, which connects with replication managers on other servers and client devices. Through these replication managers the data that is stored in the JS objects or stored in storages for these objects can be synchronized between different servers and devices.

0157While instantiating the objects, the runtime processor <b>105</b> also processes the validation, ACL, and relationship attributes that are defined in the JSON files associated with the objects. This processing is different in different embodiments. In some embodiments, this processing simply entails storing the ACL, validation, and relations attributes in data storages (e.g., data storage <b>525</b>), so that the rule processing engine <b>520</b> and object linker <b>530</b> can use these attributes to perform their operations. Each time that an object with validation and/or ACL rules receives an API request, the rule processing engine <b>520</b> of some embodiments performs the validation and ACL rule check for the object before or after the object processes data in response to this request. Each time an object that has relations key is instantiated, the object linker <b>530</b> creates a link between the object and other objects related to it based on relations key values.

0158In other embodiments, to process the validation, ACL and/or relationship attributes during a particular object's instantiation, the runtime processor instantiates a validator, ACL-rule processor, and/or an object linker for the particular object. The object linker then defines the relationships between the particular object and other objects based on the particular object's relations key values. Each time that the particular object receives an API request, the object uses its validator and/or ACL rule processor to process the validation rule(s) and/or ACL rule(s) for the particular object before or after the object processes data in response to this request. In this manner, the validator and ACL rule processor are modules that are hooked into the particular object.

0159The I/O handler <b>555</b> in some embodiments allows the API server to handle a large number of concurrent sessions with a large number of devices (e.g., computers, mobile devices, etc.). For instance, in some embodiments, this handler <b>555</b> uses a non-blocking input/output (I/O) process that can concurrently maintain a large number of concurrent sessions. The I/O process of some embodiments is a single-threaded process that does not consume too much of the system resources, which, in turn allows it to be able to handle a large number of concurrent sessions. In some embodiments, the socket handler <b>550</b> can also maintain a session with a connecting device (e.g., a connecting mobile device) for a long duration of time. For example, in some embodiments, the I/O manager <b>125</b> can maintain a session for a long duration because it uses a web socket manager to manage the connection session.

0160The API handler <b>120</b> exposes the API server's JS objects <b>150</b> to the other devices (e.g., other servers, computers, mobile devices, etc.). As shown, the handler <b>120</b> uses REST adapter to expose the APIs to the JS objects. The REST adapter handles the task of processing API requests that are received through REST web services, converting received requests to a format for the API handler <b>510</b> to process, and converting the API responses that it receives from the API handler <b>510</b> to REST web service format for transmission back to the client devices. Other embodiments expose the APIs through other services, and hence use other API protocol processors. Accordingly, in these embodiments, the REST processor is replaced with a protocol processor. This protocol processor in some embodiments can switch protocols dynamically between REST and other formats like websockets, SOAP, webrtc, etc.

0161As mentioned above, client devices in some embodiments instantiate objects and use these objects to process API requests locally or to direct these API requests to JS objects on an API server. In some embodiments, the client devices store the models and instantiate the objects from these models. The objects on the client devices are referred to as proxy objects, as they act on the client as proxies of the objects on the server. In some embodiments, the proxy objects are JS objects, while in other embodiments, the proxy objects are other types of objects (e.g., a Java object or an objective C object). For instance, in some embodiments, a mobile application executes within a browser on a client device, while another mobile application executes natively on top of the operating system (OS) of the client device. In some of these embodiments, the applications that execute within the browser, execute on top of the browser's JS engine. Hence, in these embodiments, the proxy objects can be JS objects. On the other hand, the application that runs natively on the device's OS, instantiates other types of proxy objects (e.g., Java objects or objective C objects) in some embodiments.

0162The asynchronous nature of the JavaScript poses unique challenges for traceability and debugging when programming APIs. In some embodiments the API server introduces a new construct called a zone. A zone is a special function that allows parallel execution of statements within function. The parallel execution allows for scope to be controlled and spawned independently. The function will not return a result until all statements have completed in its operation. The statement execution can be traced across the asynchronous callback boundaries within JavaScript so that each asynchronous function can be traced back to its calling parent. In addition, each functional call can carry context in the form of global data. The global data for each statement can be aggregated to the parent zone function and returned as part of the result set.

0163The API server uses a zone as a means to service API requests and responses across the entire lifecycle of the API invocation. This means that the zone can carry contextual information passed by the caller and have it propagated throughout all functional boundaries invoked within the API. The same zone can carry contextual information from a responding source back to the API requester as well accordingly.

0164<figref idref="DRAWINGS">FIGS. 6 and 7</figref> present block diagrams that describe how the models of some embodiments can operate respectively within the browser environment and within the native OS environment of a client device. <figref idref="DRAWINGS">FIG. 6</figref> conceptually illustrates executing proxy objects of some embodiments in a native OS environment of a client device <b>600</b>. This environment is similar to the client environment of <figref idref="DRAWINGS">FIG. 2</figref>. Like the client <b>200</b>, the client <b>600</b> includes a runtime processor <b>205</b>, a data abstractor <b>210</b>, a data storage connector <b>215</b>, a server interface <b>275</b>. In <figref idref="DRAWINGS">FIG. 6</figref>, the server interface <b>275</b> is shown to include a REST adapter <b>605</b> and a socket handler <b>610</b>. Similarly, the runtime processor <b>205</b> is shown to include object instantiator <b>615</b> as well as proxy objects <b>250</b> that are created by the instantiator. Lastly, the client device <b>600</b> is shown to include a rule processing engine <b>620</b>, ACL/Validation rule data storage <b>625</b>, object linker <b>630</b>, a replication manager <b>635</b>, and a remote API handler <b>640</b>.

0165The runtime processor <b>205</b> instantiates several proxy objects <b>250</b> that correspond to JS objects running on the API server. In some embodiments, the proxy objects are objects that can be processed in the native OS environment. Examples of such proxy objects include objective C object (e.g., for Apple iOS environment) and Java objects (e.g., for Android environment). To instantiate these proxy objects, the client device includes an adapter that can query the API server dynamically at runtime for an object description, and then, based on the received object description, instantiate a native object (e.g., as objective C objects in iOS and as Java objects in Android). In some embodiments, this adapter is part of the REST adapter <b>605</b>, which acts as a bridge between client and the server. The Appendix C portion of the incorporated ASCII text file computer program listing appendix provides the source code for an adapter of some embodiments that can be used in a native client environment to pull an object's description from a server.

0166In some embodiments, the client device dynamically queries the API server (through the above-described adapter) for an object description when it receives an API request that it does not know how to handle. The API server in these embodiments then notes the type of client device that is making the query (i.e., notes the operating system of the client device) and then provides the object description to the client device. Once the native object is instantiated on the client, the native client can then process the API request locally, or it can direct the API request to be processed remotely by the server. In some embodiments, the API server can provide the response to the API request with the provided object description or before providing this object description.

0167As mentioned above, once instantiated, a proxy object <b>250</b> on the client can be used to process an API request from local data storages <b>255</b> that reside on the client device <b>200</b>, or by calling a corresponding JS object that resides on the API server <b>100</b> so that this object <b>280</b> can process this request (e.g., by using backend data storages). As shown, the proxy objects <b>250</b> access the local data storages <b>255</b> through the data abstractor <b>210</b> and the data connector <b>215</b>, which were described above. In some embodiments, the data abstractor <b>210</b> and the data connector <b>215</b> are not used in the native client-side environment as the proxy objects can pull data directly from the client's local data storages without going through the data abstraction and connection layers.

0168The proxy object <b>250</b> accesses its corresponding JS object <b>280</b> on the API server through the remote API handler <b>640</b>, the REST adapter <b>605</b>, and socket handler <b>610</b>. The API handler <b>640</b> is part of the client-side framework that allows the proxy objects to send out API requests to the API server and to receive responses to the API requests from the API server. In some embodiments, this handler dynamically determines whether the object's API request should be processed remotely or locally. This dynamic determination is based on conditions that the handler <b>640</b> assesses dynamically in some embodiments. The dynamic decision making of the handler <b>640</b> is further described in the concurrently filed U.S. patent application Ser. No. ______, entitled “Dynamic Determination of Local and Remote API Calls,” with Attorney Docket No. SLOO.P0002.

0169The REST adapter <b>605</b> establishes REST web services between the client <b>600</b> and server <b>500</b>, in order to allow these two devices to exchange API requests and responses by using the REST defined protocols. In other words, the REST adapter reformats the API requests of the proxy objects <b>250</b> to a REST-compliant format for transmission to the API server, and reformats the server's API responses from the REST-compliant format to a JS format that the JS objects can process. As mentioned above, other embodiments use other API protocol processors. The socket handler <b>610</b> maintains the communication socket(s) between the client device <b>600</b> and the API server <b>500</b>. In some embodiments, the socket handler <b>610</b> establishes web sockets with the socket handler <b>550</b> of the API server <b>500</b>.

0170While instantiating an object, the runtime processor <b>205</b> also processes the validation, ACL, and relationship attributes that are defined in the object's JSON files via the hooks that are inserted in the JS file. This processing is different in different embodiments. In some embodiments, this processing simply entails storing the ACL, validation, and relations attributes in data storages (e.g., data storage <b>625</b>), so that rule processing engine <b>620</b> and object linker <b>630</b> can use these attributes to perform their operations. Each time that an object with validation and/or ACL rules receives an API request, the rule processing engine <b>620</b> in some embodiments performs the validation and ACL rule checks for the object before or after the object processes data in response to this request. Each time an object that has relations key is instantiated, the object linker <b>630</b> creates a link between the object and other objects related to it based on relations key values.

0171To process the validation, ACL and/or relationship attributes during a particular object's instantiation, the runtime processor of some embodiments instantiates a validator, ACL-rule processor, and/or an object linker for the particular object. The object linker <b>630</b> then defines the relationships between the particular object and other objects based on the particular object's relations key values. Each time that the particular object receives an API request, the object uses its validator and/or ACL rule processor <b>620</b> to process the validation rule(s) and/or ACL rule(s) for the particular object before or after the object processes data in response to this request. In this manner, the validator and ACL rule processor are modules that are hooked into the particular object. In some embodiments, the validator, rule processor and object linker are modules within the runtime processor. In still other embodiments, the validator and rule processor are simply functions performed by the runtime processor, while the object linker is a separate module with the runtime processor.

0172As shown in <figref idref="DRAWINGS">FIG. 6</figref>, the JS objects also connect to the replication manager <b>635</b>, which connects with replication manager on the API server. Through these replication managers, the data that is stored in the JS objects or stored in storages for these objects can be synchronized between different servers and devices.

0173<figref idref="DRAWINGS">FIG. 7</figref> conceptually illustrates executing the JS models of some embodiments within a web browser <b>790</b> that executes on a client device <b>700</b>. This environment is similar to the client environment of <figref idref="DRAWINGS">FIG. 6</figref>, except for a few differences. For instance, all the modules illustrated operate within the browser <b>790</b>. Also, as web browsers typically have a JS engine (e.g., the V8 JS engine), the object instantiator <b>715</b> instantiates JS proxy objects, as opposed to the non-JS proxy objects that are instantiated in some embodiments in the native client environments.

0174As shown in <figref idref="DRAWINGS">FIG. 7</figref>, the client <b>700</b> stores the description of multiple JavaScript models <b>735</b>, with each model defined in terms of a JavaScript file and a JSON file. In some embodiments, the client-side JS and JSON files are identical or similar to the JS and JSON files that are used to define the object on the API server. The object instantiator <b>715</b> instantiates each JS, proxy object based on the object description contained in an associated pair of JS file and JSON file. In some embodiments, a JS file and a JSON file are associated through their common name.

0175In <figref idref="DRAWINGS">FIG. 7</figref>, the proxy objects <b>250</b> are shown to directly access the local storage of the browser without having to using the data abstractor <b>210</b> or the data connector <b>215</b>, which were illustrated in <figref idref="DRAWINGS">FIG. 6</figref> for the native client environment. However, as mentioned above, the native client environment also does not utilize the data abstractor <b>210</b> and the data connector <b>215</b> in some embodiments.

0176The framework of some embodiments provides a Zone library that provides a way to represent the dynamic extent of asynchronous calls in JS framework of some embodiments. The zone library dynamically modifies framework's asynchronous APIs at runtime. Similar to how a scope of a function defines where it may be used, the extent of a call represents the lifetime that it is active. The Zone library of some embodiments also provides execution context that can persist across the lifecycle of one or more asynchronous calls. This concept is similar to the concept of thread-local data in Java. In some embodiments, the Zones library provides a way to group and track resources and errors across asynchronous operations. In addition zones (1) enable more effective debugging by providing better stack traces for asynchronous functions, (2) make it easier to write and understand asynchronous functions for the applications, (3) make it easier to handle errors raised asynchronously and avoid resulting resource leaks, and (4) enable the developers to associate user data with asynchronous control flow

0177In some embodiments, in order to use the zones that are provided in the Zone library, the developer should add the “require(‘zone’).enable( )” as the very first line of the developer's program. By doing so, the zone library exports a global variable, zone. The zone global variable always refers to the currently active zone. In some embodiments, the methods that can always be found on the ‘zone’ object are actually static methods of the Zone class, so they don't do anything with the currently active zone. After loading the zone library, the developer's program has entered the ‘root’ zone.

0178Different embodiments provide different ways to create a zone. The canonical way to create a one-off zone is as follows:

0000<tables id="TABLE-US-00050" num="00050"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="14pt" align="left" /><colspec colname="1" colwidth="203pt" align="left" /><thead><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>// Load the library</entry></row><row><entry /><entry>require(‘zone’).enable( );</entry></row><row><entry /><entry>// MyZone is the name of this zone which shows up in stack traces.</entry></row><row><entry /><entry>zone.create(function MyZone( ) {</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="28pt" align="left" /><colspec colname="1" colwidth="189pt" align="left" /><tbody valign="top"><row><entry /><entry>// At this point the ‘zone’ global points at the zone instance</entry></row><row><entry /><entry>(“MyZone”)</entry></row><row><entry /><entry>// that we just created.</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="14pt" align="left" /><colspec colname="1" colwidth="203pt" align="left" /><tbody valign="top"><row><entry /><entry>});</entry></row><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables><br /> The above zone constructor function is called synchronously.

0000<tables id="TABLE-US-00051" num="00051"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="left" /><thead><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>A simple way to create a function that is always wrapped within a zone is</entry></row><row><entry>as follows:</entry></row><row><entry>function renderTemplate(fileName, cb) {</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="14pt" align="left" /><colspec colname="1" colwidth="203pt" align="left" /><tbody valign="top"><row><entry /><entry>zone.create(function( ) {</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="28pt" align="left" /><colspec colname="1" colwidth="189pt" align="left" /><tbody valign="top"><row><entry /><entry>// Actual work here</entry></row><row><entry /><entry>...</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="14pt" align="left" /><colspec colname="1" colwidth="203pt" align="left" /><tbody valign="top"><row><entry /><entry>}).setCallback(cb);</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="left" /><tbody valign="top"><row><entry>}</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables><br /> To make the above function a little less verbose, some embodiments provide the ‘zone.define( )’ API. With this API, the developer can wrap a function such that when the function is called a zone is created. For example:

0000<tables id="TABLE-US-00052" num="00052"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="21pt" align="left" /><colspec colname="1" colwidth="196pt" align="left" /><thead><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>var renderTemplate = zone.define(function(fileName, cb) {</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="35pt" align="left" /><colspec colname="1" colwidth="182pt" align="left" /><tbody valign="top"><row><entry /><entry>zone.setCallback(cb);</entry></row><row><entry /><entry>// Actual work here</entry></row><row><entry /><entry>...</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="21pt" align="left" /><colspec colname="1" colwidth="196pt" align="left" /><tbody valign="top"><row><entry /><entry>});</entry></row><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables><br /> This zone template now can be used as follows:

0000<tables id="TABLE-US-00053" num="00053"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="42pt" align="left" /><colspec colname="1" colwidth="175pt" align="left" /><thead><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>renderTemplate(‘bar’, function(err, result) {</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="56pt" align="left" /><colspec colname="1" colwidth="161pt" align="left" /><tbody valign="top"><row><entry /><entry>if (err)</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="70pt" align="left" /><colspec colname="1" colwidth="147pt" align="left" /><tbody valign="top"><row><entry /><entry>throw err;</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="56pt" align="left" /><colspec colname="1" colwidth="161pt" align="left" /><tbody valign="top"><row><entry /><entry>// Do something with the result</entry></row><row><entry /><entry>...</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="42pt" align="left" /><colspec colname="1" colwidth="175pt" align="left" /><tbody valign="top"><row><entry /><entry>});</entry></row><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0179Zones of some embodiments are like asynchronous functions. From the outside perspective, they can return a single value or “throw” a single error. Some embodiments provide a couple of ways for the outside zone to obtain the result of a zone. When a zone reports its outcome, in some embodiments, no more callbacks will run inside the zone. Additionally all non-garbage-collectable resources are cleaned up when a zone reports its outcome. Zones of some embodiments, also automatically exit when no explicit value is returned. One way to obtain the outcome of a zone, in some embodiments, is:

0000<tables id="TABLE-US-00054" num="00054"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="left" /><thead><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>require(‘zone’).enable( );</entry></row><row><entry>var net = require(‘net’);</entry></row><row><entry>zone.create(function MyZone( ) {</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="14pt" align="left" /><colspec colname="1" colwidth="203pt" align="left" /><tbody valign="top"><row><entry /><entry>// This runs in the context of MyZone</entry></row><row><entry /><entry>net.createConnection(...);</entry></row><row><entry /><entry>fs.stat(...)</entry></row><row><entry /><entry>if (Math.random( ) &lt; 0.5)</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="28pt" align="left" /><colspec colname="1" colwidth="189pt" align="left" /><tbody valign="top"><row><entry /><entry>throw new Error(‘Chaos monkey!’);</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="14pt" align="left" /><colspec colname="1" colwidth="203pt" align="left" /><tbody valign="top"><row><entry /><entry>else if (Math.random( ) &lt; 0.5)</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="28pt" align="left" /><colspec colname="1" colwidth="189pt" align="left" /><tbody valign="top"><row><entry /><entry>zone.return(‘Chaos monkey in disguise!’);</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="14pt" align="left" /><colspec colname="1" colwidth="203pt" align="left" /><tbody valign="top"><row><entry /><entry>else</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="28pt" align="left" /><colspec colname="1" colwidth="189pt" align="left" /><tbody valign="top"><row><entry /><entry>; // Wait for the zone to auto-exit.</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="left" /><tbody valign="top"><row><entry>}).setCallback(function(err, result) {</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="14pt" align="left" /><colspec colname="1" colwidth="203pt" align="left" /><tbody valign="top"><row><entry /><entry>// Here we’re back in the root zone.</entry></row><row><entry /><entry>// Asynchronicity is guaranteed, even if the zone returns or throws</entry></row><row><entry /><entry> immediately.</entry></row><row><entry /><entry>// By the time we get here we are sure:</entry></row><row><entry /><entry>// * the connection has been closed one way or another</entry></row><row><entry /><entry>// * fs.stat has completed</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="left" /><tbody valign="top"><row><entry>});</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0180The developer can also use the then and catch methods, as if it were a promise:

0000<tables id="TABLE-US-00055" num="00055"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="56pt" align="left" /><colspec colname="1" colwidth="161pt" align="left" /><thead><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>zone.create(function MyZone( ) {</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="70pt" align="left" /><colspec colname="1" colwidth="147pt" align="left" /><tbody valign="top"><row><entry /><entry>// Do whatever</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="56pt" align="left" /><colspec colname="1" colwidth="161pt" align="left" /><tbody valign="top"><row><entry /><entry>}).then(function(result) {</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="70pt" align="left" /><colspec colname="1" colwidth="147pt" align="left" /><tbody valign="top"><row><entry /><entry>// Runs when succesful</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="56pt" align="left" /><colspec colname="1" colwidth="161pt" align="left" /><tbody valign="top"><row><entry /><entry>}).catch(function(err) {</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="70pt" align="left" /><colspec colname="1" colwidth="147pt" align="left" /><tbody valign="top"><row><entry /><entry>// Handle error</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="56pt" align="left" /><colspec colname="1" colwidth="161pt" align="left" /><tbody valign="top"><row><entry /><entry>});</entry></row><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0181Within a zone, a developer may use resources that are “owned” by ancestor zones. Therefor in some embodiment the following is proper:

0000<tables id="TABLE-US-00056" num="00056"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="28pt" align="left" /><colspec colname="1" colwidth="189pt" align="left" /><thead><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>var server = http.createServer( ).listen(1234);</entry></row><row><entry /><entry>server.listen(1234);</entry></row><row><entry /><entry>zone.create(function ServerZone( ) {</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="42pt" align="left" /><colspec colname="1" colwidth="175pt" align="left" /><tbody valign="top"><row><entry /><entry>// Yes, allowed.</entry></row><row><entry /><entry>server.on(‘connection’, function(req, res) { ... });</entry></row><row><entry /><entry>// Totally okay</entry></row><row><entry /><entry>process.stdout.write(‘hello!’);</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="28pt" align="left" /><colspec colname="1" colwidth="189pt" align="left" /><tbody valign="top"><row><entry /><entry>});</entry></row><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0182However, using resources owned by child zones is not allowed:

0183var server;

0000<tables id="TABLE-US-00057" num="00057"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="35pt" align="left" /><colspec colname="1" colwidth="182pt" align="left" /><thead><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>zone.create(function SomeZone( ) {</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="49pt" align="left" /><colspec colname="1" colwidth="168pt" align="left" /><tbody valign="top"><row><entry /><entry>server = http.createServer( ).listen(1234);</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="35pt" align="left" /><colspec colname="1" colwidth="182pt" align="left" /><tbody valign="top"><row><entry /><entry>});</entry></row><row><entry /><entry>// NOT OKAY!</entry></row><row><entry /><entry>server.on(‘connection’, function( ) { ... });</entry></row><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0184Some embodiments allow for a zone to temporarily enter an ancestor zone. Some such embodiments, however, do not allow for the zone to enter child zones, siblings, etc. The rationale behind this is that when a zone is alive its parent must also be alive. Other zones may exit unless they are aware that code will run inside them. An example is illustrated below:

0000<tables id="TABLE-US-00058" num="00058"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="14pt" align="left" /><colspec colname="1" colwidth="203pt" align="left" /><thead><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>zone.create(function OuterZone( ) {</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="28pt" align="left" /><colspec colname="1" colwidth="189pt" align="left" /><tbody valign="top"><row><entry /><entry>var childZone = zone.create(function ChildZone( ) {</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="42pt" align="left" /><colspec colname="1" colwidth="175pt" align="left" /><tbody valign="top"><row><entry /><entry>...</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="28pt" align="left" /><colspec colname="1" colwidth="189pt" align="left" /><tbody valign="top"><row><entry /><entry>});</entry></row><row><entry /><entry>// Fine.</entry></row><row><entry /><entry>zone.parent.run(function( ) {</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="42pt" align="left" /><colspec colname="1" colwidth="175pt" align="left" /><tbody valign="top"><row><entry /><entry>console.log(‘Hello from the root zone!’);</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="28pt" align="left" /><colspec colname="1" colwidth="189pt" align="left" /><tbody valign="top"><row><entry /><entry>});</entry></row><row><entry /><entry>// NOT ALLOWED</entry></row><row><entry /><entry>childZone.run(function( ) {</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="42pt" align="left" /><colspec colname="1" colwidth="175pt" align="left" /><tbody valign="top"><row><entry /><entry>console.log(‘Weird. This isn’t supposed to work!’);</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="28pt" align="left" /><colspec colname="1" colwidth="189pt" align="left" /><tbody valign="top"><row><entry /><entry>});</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="14pt" align="left" /><colspec colname="1" colwidth="203pt" align="left" /><tbody valign="top"><row><entry /><entry>});</entry></row><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0185Some embodiments provide the following ways to explicitly exit a zone: <ul id="ul0019" list-style="none"><li id="ul0019-0001" num="0000"><ul id="ul0020" list-style="none"><li id="ul0020-0001" num="0186">zone.return(value) sets the return value of the zone and starts cleanup.</li><li id="ul0020-0002" num="0187">zone.throw(error) sets the zone to failed state and starts cleanup. zone.throw, itself, does not throw, so statements after it will run.</li><li id="ul0020-0003" num="0188">throw error uses normal exception handling. If the exception is not caught before it reaches the binding layer, the active zone is set to failed state and starts cleanup.</li><li id="ul0020-0004" num="0189">zone.complete(err, value) is a zone-bound function that may be passed to subordinates to let them exit the zone. <br /> The following example, </li></ul></li></ul>

0000<tables id="TABLE-US-00059" num="00059"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="35pt" align="left" /><colspec colname="1" colwidth="182pt" align="left" /><thead><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>zone.create(function StatZone( ) {</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="49pt" align="left" /><colspec colname="1" colwidth="168pt" align="left" /><tbody valign="top"><row><entry /><entry>fs.stat(‘/some/file’, function(err, result) {</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="63pt" align="left" /><colspec colname="1" colwidth="154pt" align="left" /><tbody valign="top"><row><entry /><entry>if (err)</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="77pt" align="left" /><colspec colname="1" colwidth="140pt" align="left" /><tbody valign="top"><row><entry /><entry>throw err;</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="63pt" align="left" /><colspec colname="1" colwidth="154pt" align="left" /><tbody valign="top"><row><entry /><entry>else</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="77pt" align="left" /><colspec colname="1" colwidth="140pt" align="left" /><tbody valign="top"><row><entry /><entry>zone.return(result);</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="49pt" align="left" /><colspec colname="1" colwidth="168pt" align="left" /><tbody valign="top"><row><entry /><entry>});</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="35pt" align="left" /><colspec colname="1" colwidth="182pt" align="left" /><tbody valign="top"><row><entry /><entry>});</entry></row><row><entry /><entry>is equivalent to:</entry></row><row><entry /><entry>zone.create(function StatZone( ) {</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="49pt" align="left" /><colspec colname="1" colwidth="168pt" align="left" /><tbody valign="top"><row><entry /><entry>fs.stat(‘/some/file’, zone.complete);</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="35pt" align="left" /><colspec colname="1" colwidth="182pt" align="left" /><tbody valign="top"><row><entry /><entry>});</entry></row><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0190In some embodiments, in order to run code in a child zone, a developer can use zone.bindCallback and zone.bindAsyncCallback functions to create a callback object which can be invoked from a parent zone. A developer can also, within a zone, use resources that are “owned” by ancestor zones of that zone. Therefore, the following example is proper:

0000<tables id="TABLE-US-00060" num="00060"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="28pt" align="left" /><colspec colname="1" colwidth="189pt" align="left" /><thead><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>var server = http.createServer( ).listen(1234);</entry></row><row><entry /><entry>server.listen(1234);</entry></row><row><entry /><entry>zone.create(function ServerZone( ) {</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="42pt" align="left" /><colspec colname="1" colwidth="175pt" align="left" /><tbody valign="top"><row><entry /><entry>// Yes, allowed.</entry></row><row><entry /><entry>server.on(‘connection’, function(req, res) { ... });</entry></row><row><entry /><entry>// Totally okay</entry></row><row><entry /><entry>process.stdout.write(‘hello!’);</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="28pt" align="left" /><colspec colname="1" colwidth="189pt" align="left" /><tbody valign="top"><row><entry /><entry>});</entry></row><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0191However, using resources owned by child zones is not allowed, therefore the following example is not proper:

0000<tables id="TABLE-US-00061" num="00061"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="35pt" align="left" /><colspec colname="1" colwidth="182pt" align="left" /><thead><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>var server;</entry></row><row><entry /><entry>zone.create(function SomeZone( ) {</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="49pt" align="left" /><colspec colname="1" colwidth="168pt" align="left" /><tbody valign="top"><row><entry /><entry>server = http.createServer( ).listen(1234);</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="35pt" align="left" /><colspec colname="1" colwidth="182pt" align="left" /><tbody valign="top"><row><entry /><entry>});</entry></row><row><entry /><entry>// NOT OKAY!</entry></row><row><entry /><entry>server.on(‘connection’, function( ) { ... });</entry></row><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0192The framework of some embodiments provide a very useful property “prozone.data” which is a property that associates arbitrary data with a zone. This property can be thought as the ‘scope’ of a zone. Properties that are not explicitly defined within the scope of a zone are inherited from the parent zone. In some embodiments, zone.data equals the global object in the root zone. In these embodiments, zone.data starts off as an empty object with the parent zone's data property as it's prototype in any other zone.

0193The example provided below shows a very simple case where zones can (1) store user provided data with different lifetimes, (2) capture unexpected Exceptions in asynchronous callbacks, and (3) provide a long stack-trace of exceptions:

0000<tables id="TABLE-US-00062" num="00062"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="left" /><thead><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>js require(‘zone’).enable( ); express = require(‘express’); var Zone =</entry></row><row><entry>zone.Zone;</entry></row><row><entry>var app = express( ); var router = express.Router( );</entry></row><row><entry>Zone.longStackSupport = true;</entry></row><row><entry>//Initialize the Request id in the root zone. //This value will be available to</entry></row><row><entry>all child zones.</entry></row><row><entry>zone.data.requestId = 0;</entry></row><row><entry>app.use(function(req, res, next) { //Increment the request ID for every new</entry></row><row><entry>request</entry></row><row><entry>++zone.data.requestId;</entry></row><row><entry>//Create a new Zone for this request zone.create( function RequestZone( )</entry></row><row><entry>{ //Store the request URL in the Request zone //This value will be only to</entry></row><row><entry>this zone and its children</entry></row><row><entry>zone.data.requestURL = req.url;</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="56pt" align="left" /><colspec colname="1" colwidth="161pt" align="left" /><tbody valign="top"><row><entry /><entry>//Continue to run other express middleware within this</entry></row><row><entry /><entry>child zone</entry></row><row><entry /><entry>next( );</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="42pt" align="left" /><colspec colname="1" colwidth="175pt" align="left" /><tbody valign="top"><row><entry /><entry>})</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="14pt" align="left" /><colspec colname="1" colwidth="203pt" align="left" /><tbody valign="top"><row><entry /><entry>.then(</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="28pt" align="left" /><colspec colname="1" colwidth="189pt" align="left" /><tbody valign="top"><row><entry /><entry>//The call was succesful</entry></row><row><entry /><entry>function successCallback(err) {</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="42pt" align="left" /><colspec colname="1" colwidth="175pt" align="left" /><tbody valign="top"><row><entry /><entry>res.write(‘Transaction succesful\n’);</entry></row><row><entry /><entry>res.end( );</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="28pt" align="left" /><colspec colname="1" colwidth="189pt" align="left" /><tbody valign="top"><row><entry /><entry>},</entry></row><row><entry /><entry>//An error was thrown while processing this request</entry></row><row><entry /><entry>function errorCallback(err) {</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="42pt" align="left" /><colspec colname="1" colwidth="175pt" align="left" /><tbody valign="top"><row><entry /><entry>res.write(‘Transaction failed\n’);</entry></row><row><entry /><entry>res.write(‘x’ + err.zoneStack + ‘\n’);</entry></row><row><entry /><entry>res.end( );</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="28pt" align="left" /><colspec colname="1" colwidth="189pt" align="left" /><tbody valign="top"><row><entry /><entry>});</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="left" /><tbody valign="top"><row><entry>});</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="14pt" align="left" /><colspec colname="1" colwidth="203pt" align="left" /><tbody valign="top"><row><entry /><entry>router.get(‘/’, function(req, res) { if (Math.random( ) > 0.5) {</entry></row><row><entry /><entry>//Simulate some async I/O call that throws an exception</entry></row><row><entry /><entry>process.nextTick(function( ) { throw new Error(“monkey wrench”);</entry></row><row><entry /><entry>}); }</entry></row><row><entry /><entry>res.write(‘Running request #’ + zone.data.requestId + ‘ within</entry></row><row><entry /><entry>zone: ’ + zone.name + ‘</entry></row><row><entry /><entry>(URL:’ + zone.data.requestURL + ‘)\n’); });</entry></row><row><entry /><entry>app.use(‘/’, router); app.listen(3001);</entry></row><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0194Some embodiments of the invention provide a JS framework (e.g., like a node.js framework or a node.js like framework) that provides robust and simple tools for specifying class descriptions of objects for processing API requests. In some embodiments, this framework can be used as a server-side framework to define an API server and/or as a framework to define client side applications (e.g., mobile applications). In some embodiments, the framework employs a JavaScript Definition Language (JSDL) that allows a developer to specify JS data models. As mentioned above, a JS data model of some embodiments can be defined in terms of a JS file that specifies the model's behavior and a JSON file that specifies the model's properties. JSDL of some embodiments provides a set of extensions to standard JSON file format that allows a developer to specify a rich set of properties for a JS object that needs to process an API request.

0195In some embodiments, JSDL allows a developer (e.g., a mobile application developer) to develop an entire set of objects with corresponding APIs by writing the objects entirely in JSON form. Specifically, the framework of some embodiments allows a developer to define a model in a variety of ways, including (1) using a model generator of the framework, (2) a JSON instance introspection capability of the framework, and (3) a database discovery API of the framework.

0196A simple method of creating a model in some embodiments is through a command line API command that invokes the model generator. When the model generator is invoked, a simple model can be defined by specifying a property definition in a JSON model. Such a property definition can include a set of one or more property key-value pairs, in the form of “propertyName: type element.” In this type of definition, the property name is the key and the type of property is the value. An example of a property definition in JSON of some embodiments is as follows:

0000<tables id="TABLE-US-00063" num="00063"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="63pt" align="left" /><colspec colname="1" colwidth="154pt" align="left" /><thead><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>{</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="77pt" align="left" /><colspec colname="1" colwidth="140pt" align="left" /><tbody valign="top"><row><entry /><entry>“id”: “number”,</entry></row><row><entry /><entry>“firstName”: “string”,</entry></row><row><entry /><entry>“lastName”: “string”</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="63pt" align="left" /><colspec colname="1" colwidth="154pt" align="left" /><tbody valign="top"><row><entry /><entry>}</entry></row><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables><br /> In this example, the JSON model has three different properties: (1) the property name (i.e., key) “id” which has a property type (i.e., value) of a number, (2) the key “firstName” that has a property value of a string, and (3) the key “lastName” that also has a property value of a string. In other words, each key of some embodiments in the JSON object defines a property in the model and has an associated type. In some embodiments, JSDL provides a number of built-in types, such as string, number, Boolean, array, and object.

0197Another method of describing the above-described model in some embodiments is by specifying the following JS code:

0000<tables id="TABLE-US-00064" num="00064"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="70pt" align="left" /><colspec colname="1" colwidth="147pt" align="left" /><thead><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>var UserDefinition = {</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="84pt" align="left" /><colspec colname="1" colwidth="133pt" align="left" /><tbody valign="top"><row><entry /><entry>id: Number,</entry></row><row><entry /><entry>firstName: String,</entry></row><row><entry /><entry>lastName: String</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="70pt" align="left" /><colspec colname="1" colwidth="147pt" align="left" /><tbody valign="top"><row><entry /><entry>}</entry></row><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0198In some embodiments, a new model can also be created by extending a current model. For instance, a developer can extend a model named User to create a new model called Customer. As illustrated in the example below, the model Customer will inherit properties and methods of the model User.

0000<tables id="TABLE-US-00065" num="00065"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="49pt" align="left" /><colspec colname="1" colwidth="168pt" align="left" /><thead><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>var Customer = User.extend(‘customer’,</entry></row><row><entry /><entry>{</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="63pt" align="left" /><colspec colname="1" colwidth="154pt" align="left" /><tbody valign="top"><row><entry /><entry>accountId: String,</entry></row><row><entry /><entry>vip: Boolean</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="49pt" align="left" /><colspec colname="1" colwidth="168pt" align="left" /><tbody valign="top"><row><entry /><entry>});</entry></row><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables><br /> In this example the model Customer has inherited all the properties of the model User and additionally has two more keys that are “accountId” and “vip” with two values string and Boolean respectively.

0199Some embodiments allow a developer to define a model by mixing its definition with the definition of one or more other models, as illustrated in the following example:

0000<tables id="TABLE-US-00066" num="00066"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="left" /><thead><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>var TimeStamp = modelBuilder.define(‘TimeStamp’, {created: Date,</entry></row><row><entry>modified:</entry></row><row><entry>Date});</entry></row><row><entry>var Group = modelBuilder.define(‘Group’, {groups: [String]});</entry></row><row><entry>User.mixin(Group, TimeStamp);</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables><br /> In this example, the User model is a mix of the Group and TimeStamp models.

0200To create a model, the model generator of some embodiments allows a developer to add properties, control logic rules, relationships, and data sources to the model, and to expose the model to APIs from remote locations (e.g., from client devices and other servers). These operations will be briefly described below. These operations will also be further elaborated below after discussing model creation through database schema discovery and through instance introspection.

0201The following example illustrates a framework's command line controls for defining a model and adding properties to the model. In this and other examples below, the framework is called loopback. Also, in this example, the model being created is called book. This model represents a book database. To create this model, the developer can enter the following command: $ slc loopback:model book. The developer is then prompted to choose the data source to which the model will connect. By default, the model generator of some embodiments will only list the in-memory data source (named “db” in this example), as follows: <ul id="ul0021" list-style="none"><li id="ul0021-0001" num="0000"><ul id="ul0022" list-style="none"><li id="ul0022-0001" num="0202">[?] Select the data-source to attach book to: (Use arrow keys) db <br /> As further described below, other data source options will be displayed at this stage when the developer creates additional data sources. </li></ul></li></ul>

0203If the developer presses RETURN after being presented with the in-memory data source db, the model will be connected to this data source. Next, the generator will ask: <ul id="ul0023" list-style="none"><li id="ul0023-0001" num="0000"><ul id="ul0024" list-style="none"><li id="ul0024-0001" num="0204">[?] Expose book via the REST API? (Y/n), <br /> and the developer will have to enter Y or N to indicate respectively that the created model should or should not be exposed to remote access through REST web services. </li></ul></li></ul>

0205Next, the developer can add properties to a model through the command $ slc loopback:property. The invocation of this command will then prompt developer (1) to select from models in the application, to which it will add new property, (2) to enter the name of the property to add, (3) to select the data type of the property, and (4) to specify whether the property is required. The command-line interface during this sequence of operations is as follows in some embodiments:

0000<tables id="TABLE-US-00067" num="00067"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="56pt" align="left" /><colspec colname="1" colwidth="161pt" align="left" /><thead><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>$ slc loopback:property</entry></row><row><entry /><entry>[?] Select the model: inventory</entry></row><row><entry /><entry>[?] Enter the property name: price</entry></row><row><entry /><entry>[?] Property type: (Use arrow keys)</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="70pt" align="left" /><colspec colname="1" colwidth="147pt" align="left" /><tbody valign="top"><row><entry /><entry>string</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="84pt" align="left" /><colspec colname="1" colwidth="133pt" align="left" /><tbody valign="top"><row><entry /><entry>number</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="70pt" align="left" /><colspec colname="1" colwidth="147pt" align="left" /><tbody valign="top"><row><entry /><entry>boolean</entry></row><row><entry /><entry>object</entry></row><row><entry /><entry>array</entry></row><row><entry /><entry>date</entry></row><row><entry /><entry>buffer</entry></row><row><entry /><entry>geopoint</entry></row><row><entry /><entry>(other)</entry></row><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0206After each property is added to the book model, pressing RETURN will accept the default type (which is string in some embodiments) for each property. If another type should be specified, the developer has to chose the desired type. Once the developer is done entering the model properties, the model generator presents a list of properties and their types, and prompts the developer to specify request the construction of this model, as follows:

0000<tables id="TABLE-US-00068" num="00068"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="49pt" align="left" /><colspec colname="1" colwidth="168pt" align="left" /><thead><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>Done defining model book (books).</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="63pt" align="left" /><colspec colname="1" colwidth="154pt" align="left" /><tbody valign="top"><row><entry /><entry>- title (string)</entry></row><row><entry /><entry>- author (string)</entry></row><row><entry /><entry>- description (string)</entry></row><row><entry /><entry>- totalPages (number)</entry></row><row><entry /><entry>- genre (string)</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="49pt" align="left" /><colspec colname="1" colwidth="168pt" align="left" /><tbody valign="top"><row><entry /><entry>Create this model? (yes):</entry></row><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0207One example of a developer using the model generator to create a new model in an existing application is as follows. This process starts through a command line input:

0000<tables id="TABLE-US-00069" num="00069"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="49pt" align="left" /><colspec colname="1" colwidth="168pt" align="left" /><thead><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>$ cd <loopback-app-dir></entry></row><row><entry /><entry>$ slc loopback:model [model-name]</entry></row><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables><br /> In this example, model-name is the name of the model the developer wishes to create (optional on command line). The model generator will then prompt the developer for model name, if supplied a name on the command-line, the developer is required to just press Enter to use it. By default, only the memory connector data source exists.

0208The developer, however, can add additional data sources by using the framework's data source generator. This data source generator can be invoked by a command $ slc loopback:datasource [name]. In response, the data source generator will prompt the developer (1) to enter the name of the new data source (when the developer supplied a name on the command-line, the developer can just press Enter to use it), and (2) to select the connector to use for the data source. One example of this invocation is as follows:

0000<tables id="TABLE-US-00070" num="00070"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="28pt" align="left" /><colspec colname="1" colwidth="189pt" align="left" /><thead><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>$ slc loopback:datasource</entry></row><row><entry /><entry>[?] Enter the data-source name: corp2</entry></row><row><entry /><entry>[?] Select the connector for corp2: (Use arrow keys)</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="42pt" align="left" /><colspec colname="1" colwidth="175pt" align="left" /><tbody valign="top"><row><entry /><entry>other</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="56pt" align="left" /><colspec colname="1" colwidth="161pt" align="left" /><tbody valign="top"><row><entry /><entry>In-memory db</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="42pt" align="left" /><colspec colname="1" colwidth="175pt" align="left" /><tbody valign="top"><row><entry /><entry>MySQL</entry></row><row><entry /><entry>PostgreSQL</entry></row><row><entry /><entry>Oracle</entry></row><row><entry /><entry>Microsoft SQL</entry></row><row><entry /><entry>MongoDB</entry></row><row><entry /><entry>SOAP webservices</entry></row><row><entry /><entry>REST services</entry></row><row><entry /><entry>Neo4j</entry></row><row><entry /><entry>Kafka</entry></row><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0209If the created model is exposed over REST, then all the standard create, read, update, and delete (CRUD) operations are available via REST endpoints. The developer, in some embodiments, can also add developer's own custom remote methods that can be called via REST operations.

0210As mentioned above, some embodiments provide various ways for creating a model. In some embodiments, these various ways depend on the kind of data source on which the model is based. For instance, in addition to the above-described model generator, the framework of some embodiments allows a developer to build (1) a dynamic model for free-form data by using instance introspection of JSON data (e.g., from NoSQL databases or REST APIs), and (2) a static, schema-driven model by using a database discovery API (e.g., for discovering the schema of an RDB).

0211An example of creating a dynamic model by using instance introspection when the data does not have a schema is as follows:

0000<tables id="TABLE-US-00071" num="00071"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="left" /><thead><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>var ds = require(‘../data-sources/db.js’)(‘memory’);</entry></row><row><entry>// Instance JSON document</entry></row><row><entry>var user = {</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="14pt" align="left" /><colspec colname="1" colwidth="203pt" align="left" /><tbody valign="top"><row><entry /><entry>name: ‘Joe’,</entry></row><row><entry /><entry>age: 30,</entry></row><row><entry /><entry>birthday: new Date( ),</entry></row><row><entry /><entry>vip: true,</entry></row><row><entry /><entry>address: {</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="28pt" align="left" /><colspec colname="1" colwidth="189pt" align="left" /><tbody valign="top"><row><entry /><entry>street: ‘1 Main St’,</entry></row><row><entry /><entry>city: ‘San Jose’,</entry></row><row><entry /><entry>state: ‘CA’,</entry></row><row><entry /><entry>zipcode: ‘95131’,</entry></row><row><entry /><entry>country: ‘US’</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="14pt" align="left" /><colspec colname="1" colwidth="203pt" align="left" /><tbody valign="top"><row><entry /><entry>},</entry></row><row><entry /><entry>friends: [‘John’, ‘Mary’],</entry></row><row><entry /><entry>emails: [</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="28pt" align="left" /><colspec colname="1" colwidth="189pt" align="left" /><tbody valign="top"><row><entry /><entry>{label: ‘work’, id: ‘x@sample.com’},</entry></row><row><entry /><entry>{label: ‘home’, id: ‘x@home.com’}</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="14pt" align="left" /><colspec colname="1" colwidth="203pt" align="left" /><tbody valign="top"><row><entry /><entry>],</entry></row><row><entry /><entry>tags: [ ]</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="left" /><tbody valign="top"><row><entry>};</entry></row><row><entry>// Create a model from the user instance</entry></row><row><entry>var User = ds.buildModelFromInstance(‘User’, user, {idInjection: true});</entry></row><row><entry>// Use the model for CRUD</entry></row><row><entry>var obj = new User(user);</entry></row><row><entry>console.log(obj.toObject( ));</entry></row><row><entry>User.create(user, function (err, u1) {</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="14pt" align="left" /><colspec colname="1" colwidth="203pt" align="left" /><tbody valign="top"><row><entry /><entry>console.log(‘Created: ’, u1.toObject( ));</entry></row><row><entry /><entry>User.findById(u1.id, function (err, u2) {</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="28pt" align="left" /><colspec colname="1" colwidth="189pt" align="left" /><tbody valign="top"><row><entry /><entry>console.log(‘Found: ’, ul.toObject( ));</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="14pt" align="left" /><colspec colname="1" colwidth="203pt" align="left" /><tbody valign="top"><row><entry /><entry>});</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="left" /><tbody valign="top"><row><entry>});</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0212Unlike dynamic models, a developer can define static models for models with schema definitions (e.g., RDB). The developer can create static models using framework's discovery API by consuming existing data from a relational database. The developer then can keep the static model synchronized with the database using framework's schema/model synchronization API.

0213The following example illustrates how a developer can create a model that is associated with an Oracle RDB.

0000<tables id="TABLE-US-00072" num="00072"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="left" /><thead><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>var loopback = require(‘loopback’);</entry></row><row><entry>var ds = loopback.createDataSource(‘oracle’, {</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="14pt" align="left" /><colspec colname="1" colwidth="203pt" align="left" /><tbody valign="top"><row><entry /><entry>“host”: “demo.strongloop.com”,</entry></row><row><entry /><entry>“port”: 1521,</entry></row><row><entry /><entry>“database”: “XE”,</entry></row><row><entry /><entry>“username”: “demo”,</entry></row><row><entry /><entry>“password”: “L00pBack”</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="left" /><tbody valign="top"><row><entry>});</entry></row><row><entry>// Discover and build models from INVENTORY table</entry></row><row><entry>ds.discoverAndBuildModels(‘INVENTORY’, {visited: { }, associations:</entry></row><row><entry>true},</entry></row><row><entry>function (err, models) {</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="14pt" align="left" /><colspec colname="1" colwidth="203pt" align="left" /><tbody valign="top"><row><entry /><entry>// Now we have a list of models keyed by the model name</entry></row><row><entry /><entry>// Find the first record from the inventory</entry></row><row><entry /><entry>models.Inventory.findOne({ }, function (err, inv) {</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="28pt" align="left" /><colspec colname="1" colwidth="189pt" align="left" /><tbody valign="top"><row><entry /><entry>if(err) {</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="42pt" align="left" /><colspec colname="1" colwidth="175pt" align="left" /><tbody valign="top"><row><entry /><entry>console.error(err);</entry></row><row><entry /><entry>return;</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="28pt" align="left" /><colspec colname="1" colwidth="189pt" align="left" /><tbody valign="top"><row><entry /><entry>}</entry></row><row><entry /><entry>console.log(“\nInventory: “, inv);</entry></row><row><entry /><entry>// Navigate to the product model</entry></row><row><entry /><entry>inv.product(function (err, prod) {</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="42pt" align="left" /><colspec colname="1" colwidth="175pt" align="left" /><tbody valign="top"><row><entry /><entry>console.log(“\nProduct: ”, prod);</entry></row><row><entry /><entry>console.log(“\n ------------- ”);</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="28pt" align="left" /><colspec colname="1" colwidth="189pt" align="left" /><tbody valign="top"><row><entry /><entry>});</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="14pt" align="left" /><colspec colname="1" colwidth="203pt" align="left" /><tbody valign="top"><row><entry /><entry>});</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="left" /><tbody valign="top"><row><entry>});</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables><br /> This example shows that for an Oracle database, a developer can first, write a code that sets up the Oracle data source. The developer can then call to a discoverAndBuildModels( ) function (in the framework's discovery API set) to create models from the database tables. Calling it with the “associations: true” option makes the discovery follow primary/foreign key relations. The codeless creation of APIs by using the RDB schema discovery methodology of some embodiments of the invention is further described in the concurrently filed U.S. patent application Ser. No. ______, entitled “Codeless Generation of APIs,” with Attorney Docket No. SLOO.P0003, which is incorporated herein by reference.

0214The data source connectors of some embodiments provide discovery capability so that the developer can use DataSource to discover model definitions from existing database schema. The following exemplary APIs enable UI or code to discover database schema definitions that can be used to build models in some embodiments.

0000<tables id="TABLE-US-00073" num="00073"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="left" /><thead><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>// List database tables and/or views</entry></row><row><entry>ds.discoverModelDefinitions({views: true, limit: 20}, cb);</entry></row><row><entry>// List database columns for a given table/view</entry></row><row><entry>ds.discoverModelProperties(‘PRODUCT’, cb);</entry></row><row><entry>ds.discoverModelProperties(‘INVENTORY_VIEW’, {owner:</entry></row><row><entry>‘STRONGLOOP’}, cb);</entry></row><row><entry>// List primary keys for a given table</entry></row><row><entry>ds.discoverPrimaryKeys(‘INVENTORY’, cb);</entry></row><row><entry>// List foreign keys for a given table</entry></row><row><entry>ds.discoverForeignKeys(‘INVENTORY’, cb);</entry></row><row><entry>// List foreign keys that reference the primary key of the given table</entry></row><row><entry>ds.discoverExportedForeignKeys (‘PRODUCT’, cb);</entry></row><row><entry>// Create a model definition by discovering the given table</entry></row><row><entry>ds.discoverSchema(table, {owner: ‘STRONGLOOP’}, cb);</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0215In addition to discoverAndBuildModels which discovers and builds models from the specified owner/modelName, the other functions for discovering other properties or elements of a data source include: (1) discoverModelDefinitions( ) to discover model definitions (table or collection names), based on tables or collections in a data source; (2) discoverModelProperties( ) to discover metadata on columns (properties) of a DB table; (3) discoverPrimaryKeys( ) to discover primary key definitions in a database; (4) discoverForeignKeys( ) to discover foreign key definitions from a database; (5) discoverExportedForeignKeys( ) to discover foreign key definitions that are exported from a database; and (6) discoverSchema( ) to discover JSDL models from a database.

0216As mentioned before, a developer can make a model extend or “inherit from” an existing model that is either one of the built-in models (such as User), or a custom model that the developer has defined in his/her application. For instance, to extend a model with JSON, a developer can first use the model generator to create a new model in the application. In some embodiments, this will create a JSON file in the /common/models directory (e.g., for a customer model, customer.json). The developer can edit this file and set the “base” property in the JSON file to the name of the model the developer wishes to extend, which is either one of the built-in models, or one of the custom models that the developer defined in the application. For example, here is an excerpt from the customer.json file that extends the built-in User model to define a new Customer model: customer.json

0000<tables id="TABLE-US-00074" num="00074"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="63pt" align="left" /><colspec colname="1" colwidth="154pt" align="left" /><thead><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>{</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="77pt" align="left" /><colspec colname="1" colwidth="140pt" align="left" /><tbody valign="top"><row><entry /><entry>“name”: “Customer”,</entry></row><row><entry /><entry>“base”: “User”,</entry></row><row><entry /><entry>“idInjection”: false,</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="63pt" align="left" /><colspec colname="1" colwidth="154pt" align="left" /><tbody valign="top"><row><entry /><entry>...</entry></row><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0217A developer can also create custom models that extend from a single base custom model. For example, to define a model called MyModel that extends from a custom model that the developer has previously defined and called MyBaseModel, the developer can first create MyModel using slc loopback:model. The developer can then edit the JSON file common/models/MyModel.json as follows:

0000<tables id="TABLE-US-00075" num="00075"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="63pt" align="left" /><colspec colname="1" colwidth="154pt" align="left" /><thead><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>{</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="77pt" align="left" /><colspec colname="1" colwidth="140pt" align="left" /><tbody valign="top"><row><entry /><entry>“name”: “MyModel”,</entry></row><row><entry /><entry>“base”: “MyBaseModel”,</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="63pt" align="left" /><colspec colname="1" colwidth="154pt" align="left" /><tbody valign="top"><row><entry /><entry>}</entry></row><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables><br /> The developer can also add new properties to the JSON file after the developer has extended the model, for example:

0000<tables id="TABLE-US-00076" num="00076"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="63pt" align="left" /><colspec colname="1" colwidth="154pt" align="left" /><thead><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>{</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="77pt" align="left" /><colspec colname="1" colwidth="140pt" align="left" /><tbody valign="top"><row><entry /><entry>“name”: “Customer”,</entry></row><row><entry /><entry>“base”:” “User”,</entry></row><row><entry /><entry>“properties”: {</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="91pt" align="left" /><colspec colname="1" colwidth="126pt" align="left" /><tbody valign="top"><row><entry /><entry>“favoriteMovie”: {</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="105pt" align="left" /><colspec colname="1" colwidth="112pt" align="left" /><tbody valign="top"><row><entry /><entry>“type”: “string”</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="91pt" align="left" /><colspec colname="1" colwidth="126pt" align="left" /><tbody valign="top"><row><entry /><entry>}</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="77pt" align="left" /><colspec colname="1" colwidth="140pt" align="left" /><tbody valign="top"><row><entry /><entry>}</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="63pt" align="left" /><colspec colname="1" colwidth="154pt" align="left" /><tbody valign="top"><row><entry /><entry>}</entry></row><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0218To extend a model programmatically, the developer, in some embodiments, can create a JS file with exactly the same base name as the model JSON file. As described before, JS and JSON files that are commonly named are associated together to define a model in some embodiments. For example, if the customer model is defined in customer.json, then the developer can create customer.js. Both of these files must be in the /common/models directory. After creating the JSON file, the developer can extend a model programmatically with the extend( ) method. The method's signature is: newModel=modeName.extend(‘modelName’, properties [, settings]), where: <ul id="ul0025" list-style="none"><li id="ul0025-0001" num="0000"><ul id="ul0026" list-style="none"><li id="ul0026-0001" num="0219">newModel is the name of the new model the developer is defining.</li><li id="ul0026-0002" num="0220">modelName is the name of the model the developer is extending.</li><li id="ul0026-0003" num="0221">properties is a JSON object defining the properties to add to the model.</li><li id="ul0026-0004" num="0222">settings is an optional JSON object defining other options such as relations, ACLs, and so on.</li></ul></li></ul>

0223To attach a model to a data source, some embodiments of the invention use data source abstractors and connectors. As mentioned above, a data source abstractor enables a model to access and modify data in backend systems. The abstractor encapsulates business logic to exchange data between models and various backend systems (such as relational databases, REST APIs, SOAP web services, storage services, etc.). Data source abstractors generally provide create, retrieve, update, and delete (CRUD) functions in some embodiments.

0224In some embodiments, models access data sources not only through the abstractors but also through data source connectors, which are extensible and customizable. In general, application code does not use a connector directly. Rather, the data source abstractor provides an API to configure the underlying connector. By default, slc (i.e., the command line API) creates and uses the memory connector, which is suitable for development. To use a different data source, the developer can use slc loopaback:datasource to create the new data source and add it to the application's datasources.json. The developer then can edit datasources.json to add the appropriate credentials for the data source. Next, the developer can create a model to connect to the data source or modify an existing model definition to use the connector.

0225For example, to add a new data source, in some embodiments, the developer can use the data source generator: $ slc loopback:datasource. The system will prompt the developer for the name of the new data source and the connector to use; for example, MySQL, Oracle, REST, and so on. The tool will then add an entry such as the following to datasources.json:

0000<tables id="TABLE-US-00077" num="00077"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="56pt" align="left" /><colspec colname="2" colwidth="161pt" align="left" /><thead><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>...</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="70pt" align="left" /><colspec colname="2" colwidth="147pt" align="left" /><tbody valign="top"><row><entry /><entry>“corp1”: {</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="84pt" align="left" /><colspec colname="2" colwidth="133pt" align="left" /><tbody valign="top"><row><entry /><entry>“name”: “corp1”,</entry></row><row><entry /><entry>“connector”: “mysql”</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="70pt" align="left" /><colspec colname="2" colwidth="147pt" align="left" /><tbody valign="top"><row><entry /><entry>}</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="56pt" align="left" /><colspec colname="2" colwidth="161pt" align="left" /><tbody valign="top"><row><entry /><entry>...</entry></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables><br /> The above example creates a MySQL data source called “corp1”. The identifier determines the name by which the developer refers to the data source and can be any string. Now the developer can add data source credentials. For example, the developer can edit datasources.json to add the necessary authentication credentials for the data source, which is typically the hostname, username, password, and database name. For example:

0000<tables id="TABLE-US-00078" num="00078"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="28pt" align="left" /><colspec colname="2" colwidth="189pt" align="left" /><thead><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>“corp1”: {</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="56pt" align="left" /><colspec colname="2" colwidth="161pt" align="left" /><tbody valign="top"><row><entry /><entry>“name”: “corp1”,</entry></row><row><entry /><entry>“connector”: “mysql”,</entry></row><row><entry /><entry>“host”: “the userr-mysql-server.foo.com”,</entry></row><row><entry /><entry>“user”: “db-username”,</entry></row><row><entry /><entry>“password”: “db-password”,</entry></row><row><entry /><entry>“database”: “the userr-db-name”</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="42pt" align="left" /><colspec colname="2" colwidth="175pt" align="left" /><tbody valign="top"><row><entry /><entry>}</entry></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0226To make the model use the data source, the developer can edit the JSON file to set the data source used by a model:

0000<tables id="TABLE-US-00079" num="00079"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="49pt" align="left" /><colspec colname="2" colwidth="168pt" align="left" /><thead><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>“model-name”: {</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="63pt" align="left" /><colspec colname="2" colwidth="154pt" align="left" /><tbody valign="top"><row><entry /><entry>“properties” : {</entry></row><row><entry /><entry>...</entry></row><row><entry /><entry>}</entry></row><row><entry /><entry>“dataSource”: “datasource-name”,</entry></row><row><entry /><entry>...</entry></row><row><entry /><entry>}</entry></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables><br /> For example, using the previous example where the data source was named “mysq1,” the developer can edit the “books” data source, to change the “dataSource” property from “db” to “corp1” to use the corresponding MySQL database:

0000<tables id="TABLE-US-00080" num="00080"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="56pt" align="left" /><colspec colname="2" colwidth="161pt" align="left" /><thead><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>“book”: {</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="84pt" align="left" /><colspec colname="2" colwidth="133pt" align="left" /><tbody valign="top"><row><entry /><entry>“properties”: {</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="91pt" align="left" /><colspec colname="2" colwidth="126pt" align="left" /><tbody valign="top"><row><entry /><entry>...</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="84pt" align="left" /><colspec colname="2" colwidth="133pt" align="left" /><tbody valign="top"><row><entry /><entry>},</entry></row><row><entry /><entry>“public”: true,</entry></row><row><entry /><entry>“dataSource”: “corp1”,</entry></row><row><entry /><entry>“plural”: “books”</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="70pt" align="left" /><colspec colname="2" colwidth="147pt" align="left" /><tbody valign="top"><row><entry /><entry>}</entry></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables><br /> Then the books model would use the “corp1” data source that uses the MySQL connector instead of the “db” data source that uses the memory connector.

0227In some embodiments the following connectors are available for a developer:

0000<tables id="TABLE-US-00081" num="00081"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="1" colwidth="49pt" align="left" /><colspec colname="2" colwidth="70pt" align="left" /><colspec colname="3" colwidth="98pt" align="left" /><thead><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row><row><entry>Connector</entry><entry>Module</entry><entry>Installation</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>Memory</entry><entry>Built in to LoopBack</entry><entry>Not required</entry></row><row><entry>connector</entry></row><row><entry>Email</entry><entry>Built in to LoopBack</entry><entry>Not required</entry></row><row><entry>MongoDB</entry><entry>loopback-connector-</entry><entry>npm install --save loopback-</entry></row><row><entry /><entry>mongodb</entry><entry>connector-mongodb</entry></row><row><entry>MySQL</entry><entry>loopback-connector-</entry><entry>npm install --save loopback-</entry></row><row><entry /><entry>mysql</entry><entry>connector-mysql</entry></row><row><entry>Oracle</entry><entry>loopback-connector-</entry><entry>npm install --save loopback-</entry></row><row><entry /><entry>oracle</entry><entry>connector-oracle</entry></row><row><entry>PostgreSQL</entry><entry>loopback-connector-</entry><entry>npm install --save loopback-</entry></row><row><entry /><entry>postgresql</entry><entry>connector-postgresql</entry></row><row><entry>REST</entry><entry>loopback-connector-</entry><entry>npm install --save loopback-</entry></row><row><entry /><entry>rest</entry><entry>connector-rest</entry></row><row><entry>SOAP</entry><entry>loopback-connector-</entry><entry>npm install --save loopback-</entry></row><row><entry /><entry>soap</entry><entry>connector-soap</entry></row><row><entry>SQL Server</entry><entry>loopback-connector-</entry><entry>npm install --save loopback-</entry></row><row><entry /><entry>mssql</entry><entry>connector-mssql</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0228To install a connector, the developer can run JS package install and then save, for the connector module to add the dependency to package.json; for example:

0000<tables id="TABLE-US-00082" num="00082"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="35pt" align="left" /><colspec colname="2" colwidth="182pt" align="left" /><thead><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>...</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="49pt" align="left" /><colspec colname="2" colwidth="168pt" align="left" /><tbody valign="top"><row><entry /><entry>“dependencies”: {</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="63pt" align="left" /><colspec colname="2" colwidth="154pt" align="left" /><tbody valign="top"><row><entry /><entry>“loopback-connector-oracle”: “latest”</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="49pt" align="left" /><colspec colname="2" colwidth="168pt" align="left" /><tbody valign="top"><row><entry /><entry>}</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="35pt" align="left" /><colspec colname="2" colwidth="182pt" align="left" /><tbody valign="top"><row><entry /><entry>...</entry></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0229In order to create a data source in some embodiments, the developer can use the data source generator to create a new data source or create a data source programmatically. The data source properties of some embodiments depend on the specific data source being used. However, data sources for database connectors (e.g., Oracle, MySQL, PostgreSQL, MongoDB, etc.) in some embodiments share a common set of properties, as described in the following table:

0000<tables id="TABLE-US-00083" num="00083"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="1" colwidth="42pt" align="left" /><colspec colname="2" colwidth="28pt" align="left" /><colspec colname="3" colwidth="147pt" align="left" /><thead><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row><row><entry>Property</entry><entry>Type</entry><entry>Description</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>connector</entry><entry>String</entry><entry>Connector name; one of:</entry></row><row><entry /><entry /><entry>“memory”</entry></row><row><entry /><entry /><entry>“loopback-connector-mongodb” or “mongodb”</entry></row><row><entry /><entry /><entry>“loopback-connector-mysql” or “mysql”</entry></row><row><entry /><entry /><entry>“loopback-connector-oracle” or “oracle”</entry></row><row><entry /><entry /><entry>“loopback-connector-postgresql” or “postgresql”</entry></row><row><entry /><entry /><entry>“loopback-connector-rest” or “rest”</entry></row><row><entry /><entry /><entry>“loopback-connector-mssql” or “mssql”</entry></row><row><entry>database</entry><entry>String</entry><entry>Database name</entry></row><row><entry>debug</entry><entry>Boolean</entry><entry>If true, turn on verbose mode to debug</entry></row><row><entry /><entry /><entry>database queries and lifecycle.</entry></row><row><entry>host</entry><entry>String</entry><entry>Database host name</entry></row><row><entry>password</entry><entry>String</entry><entry>Password to connect to database</entry></row><row><entry>port</entry><entry>Number</entry><entry>Database TCP port</entry></row><row><entry>username</entry><entry>String</entry><entry>Username to connect to database</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0230As discussed before, some embodiments expose models over a REST API. In some embodiments, the framework automatically binds a model to a list of HTTP endpoints that provide REST APIs for model instance data manipulations (e.g., through CRUD operations) and other remote operations. By default, the REST APIs are mounted to the plural of the model name. For example, if the developer has a location model, it is mounted to /locations. By default, scaffolded applications expose models over REST using the loopback.rest router:

0000<tables id="TABLE-US-00084" num="00084"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="63pt" align="left" /><colspec colname="2" colwidth="154pt" align="left" /><thead><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>var app = loopback( );</entry></row><row><entry /><entry>app.use(loopback.rest( ));</entry></row><row><entry /><entry>// Expose the {grave over ( )}Product{grave over ( )} model</entry></row><row><entry /><entry>app.model(Product);</entry></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables><br /> After running the above codes, the developer will have the Product model with create, read, update, and delete (CRUD) functions working remotely from mobile clients. At this point, the model is schema-less and the data are not checked. The developer can then view generated REST documentation at a particular link (e.g., http://localhost:3000/explorer). In some embodiments, the framework provides a number of built-in models that have REST APIs. By default, for a model backed by a data source that supports it, the framework exposes a REST API that provides all the standard create, read, update, and delete (CRUD) operations.

0231As an example, consider a simple model called Location (that provides business locations), the framework automatically creates the following endpoints to illustrate the exposed REST APIs:

0000<tables id="TABLE-US-00085" num="00085"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="1" colwidth="98pt" align="left" /><colspec colname="2" colwidth="49pt" align="left" /><colspec colname="3" colwidth="70pt" align="left" /><thead><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row><row><entry>Model API</entry><entry>HTTP Method</entry><entry>Example Path</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>create( )</entry><entry>POST</entry><entry>/locations</entry></row><row><entry>upsert( )</entry><entry>PUT</entry><entry>/locations</entry></row><row><entry>exists( )</entry><entry>GET</entry><entry>/locations/:id/exists</entry></row><row><entry>findById( )</entry><entry>GET</entry><entry>/locations/:id</entry></row><row><entry>find( )</entry><entry>GET</entry><entry>/locations</entry></row><row><entry>findOne( )</entry><entry>GET</entry><entry>/locations/findOne</entry></row><row><entry>deleteById( )</entry><entry>DELETE</entry><entry>/locations/:id</entry></row><row><entry>count( )</entry><entry>GET</entry><entry>/locations/count</entry></row><row><entry>prototype.updateAttributes( )</entry><entry>PUT</entry><entry>/locations/:id</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0232The above API follows the standard model REST API that most built-in models extend. To expose a model over REST, the developer must set the public property to true in /server/model-config.json:

0000<tables id="TABLE-US-00086" num="00086"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="63pt" align="left" /><colspec colname="2" colwidth="154pt" align="left" /><thead><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>...</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="77pt" align="left" /><colspec colname="2" colwidth="140pt" align="left" /><tbody valign="top"><row><entry /><entry>“Role”: {</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="91pt" align="left" /><colspec colname="2" colwidth="126pt" align="left" /><tbody valign="top"><row><entry /><entry>“dataSource”: “db”,</entry></row><row><entry /><entry>“public”: false</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="77pt" align="left" /><colspec colname="2" colwidth="140pt" align="left" /><tbody valign="top"><row><entry /><entry>},</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="63pt" align="left" /><colspec colname="2" colwidth="154pt" align="left" /><tbody valign="top"><row><entry /><entry>...</entry></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0233If the developer does not wish to expose certain CRUD operations, the developer can easily hide them by setting the model's shared property to false. For example, following the previous example, by convention custom model code would go in the file server/location.js. The developer would add the following lines to “hide” one of the predefined remote methods:

0000<tables id="TABLE-US-00087" num="00087"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="14pt" align="left" /><colspec colname="2" colwidth="203pt" align="left" /><thead><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>var isStatic = true;</entry></row><row><entry /><entry>MyModel.sharedClass.find(‘deleteById’, isStatic).shared = false;</entry></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0234After adding these lines, the deleteById( ) operation and the corresponding REST endpoint will not be publicly available. In addition to the standard set of REST API endpoints that a model exposes, the developer can expose a model's static methods to clients over REST. These static methods are called, in some embodiments, remote methods. Additionally, the developer can define remote hooks that are functions called when a remote method is executed (typically, before or after the remote method).

0235In defining a remote method of some embodiments, the remote method must accept a callback with the conventional fn(err, result, . . . ) signature. A developer can expose a remote method in a model's custom script/common/models/modelName.js file by (1) exporting a function that takes the model as an argument (e.g., module.exports=function(modelName)), (2) in this function, defining the function as a static method of the model (e.g., modelName.functionName=function(args)), and (3) also in the function, calling remoteMethod( ) as described below to expose the function as a remote method. The first argument to remoteMethod( ) must be a string that exactly matches the static method defined in the second step.

0236A complete example of exposing a remote model, using a Person model, is illustrated below. The developer would add the following code in /common/models/person.js:

0000<tables id="TABLE-US-00088" num="00088"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="21pt" align="left" /><colspec colname="2" colwidth="196pt" align="left" /><thead><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>module.exports = function(Person){</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="35pt" align="left" /><colspec colname="2" colwidth="182pt" align="left" /><tbody valign="top"><row><entry /><entry>Person.greet = function(msg, cb) {</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="49pt" align="left" /><colspec colname="2" colwidth="168pt" align="left" /><tbody valign="top"><row><entry /><entry>cb(null, ‘Greetings... ’ + msg);</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="35pt" align="left" /><colspec colname="2" colwidth="182pt" align="left" /><tbody valign="top"><row><entry /><entry>}</entry></row><row><entry /><entry>Person.remoteMethod(</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="63pt" align="left" /><colspec colname="2" colwidth="154pt" align="left" /><tbody valign="top"><row><entry /><entry>‘greet’,</entry></row><row><entry /><entry>{</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="77pt" align="left" /><colspec colname="2" colwidth="140pt" align="left" /><tbody valign="top"><row><entry /><entry>accepts: [{arg: ‘msg’, type: ‘string’}],</entry></row><row><entry /><entry>returns: {arg: ‘greeting’, type: ‘string’}</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="63pt" align="left" /><colspec colname="2" colwidth="154pt" align="left" /><tbody valign="top"><row><entry /><entry>}</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="35pt" align="left" /><colspec colname="2" colwidth="182pt" align="left" /><tbody valign="top"><row><entry /><entry>);</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="21pt" align="left" /><colspec colname="2" colwidth="196pt" align="left" /><tbody valign="top"><row><entry /><entry>}</entry></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables><br /> Running the above code in a local application and sending a POST request with the argument “LoopBack Developer” to the default URL http://localhost:3000/api/people/greet will then return:

0000<tables id="TABLE-US-00089" num="00089"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="28pt" align="left" /><colspec colname="2" colwidth="189pt" align="left" /><thead><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>{</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="42pt" align="left" /><colspec colname="2" colwidth="175pt" align="left" /><tbody valign="top"><row><entry /><entry>“greeting”: “Greetings... LoopBack Developer”</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="28pt" align="left" /><colspec colname="2" colwidth="189pt" align="left" /><tbody valign="top"><row><entry /><entry>}</entry></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0237As summarized above, to expose a function as a remote method on a model, a developer may call the model's remote.Method( ) function. The function's signature, in some embodiments, is modelName.remoteMethod(function, [options]), where (i) modelName is the name of the model, (ii) function is the remote method being defined, and (iii) options is the optional JSON object with metadata about the function as described in the following table:

0000<tables id="TABLE-US-00090" num="00090"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="1" colwidth="49pt" align="left" /><colspec colname="2" colwidth="35pt" align="left" /><colspec colname="3" colwidth="133pt" align="left" /><thead><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row><row><entry>Option</entry><entry>Required?</entry><entry>Description</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>accepts</entry><entry>No</entry><entry>Describes the remote method's arguments.</entry></row><row><entry /><entry /><entry>The callback argument is assumed; do not</entry></row><row><entry /><entry /><entry>specify.</entry></row><row><entry>returns</entry><entry>No</entry><entry>Describes the remote method's callback</entry></row><row><entry /><entry /><entry>arguments.</entry></row><row><entry /><entry /><entry>The err argument is assumed; do not</entry></row><row><entry /><entry /><entry>specify.</entry></row><row><entry>http.path</entry><entry>No</entry><entry>HTTP path (relative to the model) at</entry></row><row><entry /><entry /><entry>which the method is exposed.</entry></row><row><entry>http.verb</entry><entry>No</entry><entry>HTTP method (verb) at which the method</entry></row><row><entry /><entry /><entry>is available. One of:</entry></row><row><entry /><entry /><entry>get</entry></row><row><entry /><entry /><entry>post (default)</entry></row><row><entry /><entry /><entry>put</entry></row><row><entry /><entry /><entry>del</entry></row><row><entry /><entry /><entry>all</entry></row><row><entry>description</entry><entry>No</entry><entry>A text description of the method. This</entry></row><row><entry /><entry /><entry>is used by API documentation generators</entry></row><row><entry /><entry /><entry>like Swagger.</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row></tbody></tgroup></table></tables><br /> The “accepts” and “returns” properties in the above table define either a single argument as an object or an ordered set of arguments as an array. Each individual argument has properties for:

0000<tables id="TABLE-US-00091" num="00091"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="1" colwidth="42pt" align="left" /><colspec colname="2" colwidth="28pt" align="left" /><colspec colname="3" colwidth="147pt" align="left" /><thead><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row><row><entry>Property</entry><entry /><entry /></row><row><entry>(key)</entry><entry>Type</entry><entry>Description</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>arg</entry><entry>String</entry><entry>Argument name</entry></row><row><entry>type</entry><entry>String</entry><entry>Argument datatype; must be an accepted type.</entry></row><row><entry>required</entry><entry>Boolean</entry><entry>True if argument is required; false otherwise.</entry></row><row><entry>root</entry><entry>Boolean</entry><entry>For callback arguments: set this property to</entry></row><row><entry /><entry /><entry>true if the user function has a single</entry></row><row><entry /><entry /><entry>callback argument to use as the root object</entry></row><row><entry /><entry /><entry>returned to remote caller. Otherwise the root</entry></row><row><entry /><entry /><entry>object returned is a map (argument-name to</entry></row><row><entry /><entry /><entry>argument-value).</entry></row><row><entry>http</entry><entry>String</entry><entry>For input arguments: a function or an object</entry></row><row><entry /><entry /><entry>describing mapping from HTTP request to the</entry></row><row><entry /><entry /><entry>argument value.</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0238An example of a single argument, specified as an object can be shown as: {arg: ‘myArg’, type: ‘number’}, while an example of multiple arguments, specified as an array can be shown as:

0000<tables id="TABLE-US-00092" num="00092"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="35pt" align="left" /><colspec colname="2" colwidth="182pt" align="left" /><thead><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>[</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="49pt" align="left" /><colspec colname="2" colwidth="168pt" align="left" /><tbody valign="top"><row><entry /><entry>{arg: ‘arg1’, type: ‘number’, required: true},</entry></row><row><entry /><entry>{arg: ‘arg2’, type: ‘array’}</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="35pt" align="left" /><colspec colname="2" colwidth="182pt" align="left" /><tbody valign="top"><row><entry /><entry>]</entry></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0239In some embodiments, there are two ways to specify HTTP mapping for input parameters (i.e., what the method accepts): (1) provide an object with a source property, and (2) specify a custom mapping function. To provide an object with a source property to specify HTTP mapping for input parameters, a developer can provide an object with a source property that has one of the values shown in the following table:

0000<tables id="TABLE-US-00093" num="00093"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="49pt" align="left" /><colspec colname="2" colwidth="168pt" align="left" /><thead><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row><row><entry>Value of source</entry><entry /></row><row><entry>property</entry><entry>Description</entry></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>body</entry><entry>The whole request body is used as the value.</entry></row><row><entry>form</entry><entry>The value is looked up using req.param, which searches</entry></row><row><entry>query</entry><entry>route arguments, the request body and the query string.</entry></row><row><entry>path</entry><entry>Note that query and path are aliases for form.</entry></row><row><entry>req</entry><entry>The whole HTTP request object is used as the value.</entry></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0240For example, an argument can get the whole request body as the value: {arg: ‘data’, type: ‘object’, http: {source: ‘body’}}. As described above, to specify HTTP mapping for input parameters, a developer can also specify a custom mapping function. For example, the developer can specify:

0000<tables id="TABLE-US-00094" num="00094"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="14pt" align="left" /><colspec colname="2" colwidth="203pt" align="left" /><thead><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>{</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="28pt" align="left" /><colspec colname="2" colwidth="189pt" align="left" /><tbody valign="top"><row><entry /><entry>arg: ‘custom’,</entry></row><row><entry /><entry>type: ‘number’,</entry></row><row><entry /><entry>http: function(ctx) {</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="42pt" align="left" /><colspec colname="2" colwidth="175pt" align="left" /><tbody valign="top"><row><entry /><entry>// ctx is LoopBack Context object</entry></row><row><entry /><entry>// 1. Get the HTTP request object as provided by Express</entry></row><row><entry /><entry>var req = ctx.req;</entry></row><row><entry /><entry>// 2. Get ‘a’ and ‘b’ from query string or form data</entry></row><row><entry /><entry>// and return their sum as the value</entry></row><row><entry /><entry>return +req.param(‘a’) + req.param(‘b’);</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="28pt" align="left" /><colspec colname="2" colwidth="189pt" align="left" /><tbody valign="top"><row><entry /><entry>}</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="14pt" align="left" /><colspec colname="2" colwidth="203pt" align="left" /><tbody valign="top"><row><entry /><entry>}</entry></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0241On the other hand, if the developer does not specify a mapping, the framework will determine the value by determining whether the HTTP request parameter args with a JSON content exists (assuming name as the name of the input parameter to resolve). If there is a HTTP request parameter args with a JSON content, then the value of args[‘name’] is used as the value if it is defined. Otherwise, req.param(‘name’) is returned as the value.

0242As mentioned above, a remote hook enables the developer to execute a function before or after a remote method is called by a client. The beforeRemote( ) function runs before the remote method and afterRemote( ) function runs after the remote method. For example:

0000<tables id="TABLE-US-00095" num="00095"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="28pt" align="left" /><colspec colname="2" colwidth="189pt" align="left" /><thead><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>var request = require(‘request’);</entry></row><row><entry /><entry>Users.afterRemote(‘count’, function(ctx, unused, next)</entry></row><row><entry /><entry>{</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="42pt" align="left" /><colspec colname="2" colwidth="175pt" align="left" /><tbody valign="top"><row><entry /><entry>request.post({</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="56pt" align="left" /><colspec colname="2" colwidth="161pt" align="left" /><tbody valign="top"><row><entry /><entry>url: ‘http://another.server.com/’,</entry></row><row><entry /><entry>method: ‘POST’,</entry></row><row><entry /><entry>json: ctx.result</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="42pt" align="left" /><colspec colname="2" colwidth="175pt" align="left" /><tbody valign="top"><row><entry /><entry>}, function(err, response) {</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="56pt" align="left" /><colspec colname="2" colwidth="161pt" align="left" /><tbody valign="top"><row><entry /><entry>if (err) console.error(err);</entry></row><row><entry /><entry>next( );</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="42pt" align="left" /><colspec colname="2" colwidth="175pt" align="left" /><tbody valign="top"><row><entry /><entry>});</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="28pt" align="left" /><colspec colname="2" colwidth="189pt" align="left" /><tbody valign="top"><row><entry /><entry>});</entry></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0243Below is another example that uses wildcards in the remote function name:

0000<tables id="TABLE-US-00096" num="00096"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="21pt" align="left" /><colspec colname="2" colwidth="196pt" align="left" /><thead><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>User.beforeRemote(‘*.save’, function(ctx, user, next) {</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="35pt" align="left" /><colspec colname="2" colwidth="182pt" align="left" /><tbody valign="top"><row><entry /><entry>if(ctx.req.accessToken) {</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="49pt" align="left" /><colspec colname="2" colwidth="168pt" align="left" /><tbody valign="top"><row><entry /><entry>next( );</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="35pt" align="left" /><colspec colname="2" colwidth="182pt" align="left" /><tbody valign="top"><row><entry /><entry>} else {</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="49pt" align="left" /><colspec colname="2" colwidth="168pt" align="left" /><tbody valign="top"><row><entry /><entry>next(new Error(‘must be logged in to update’))</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="35pt" align="left" /><colspec colname="2" colwidth="182pt" align="left" /><tbody valign="top"><row><entry /><entry>}</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="21pt" align="left" /><colspec colname="2" colwidth="196pt" align="left" /><tbody valign="top"><row><entry /><entry>});</entry></row><row><entry /><entry>User.afterRemote(‘*.save’, function(ctx, user, next) {</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="35pt" align="left" /><colspec colname="2" colwidth="182pt" align="left" /><tbody valign="top"><row><entry /><entry>console.log(‘user has been saved’, user);</entry></row><row><entry /><entry>next( );</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="21pt" align="left" /><colspec colname="2" colwidth="196pt" align="left" /><tbody valign="top"><row><entry /><entry>});</entry></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables><br /> The second argument to the hook (user in the above example) is the ctx.result, which is not always available. More examples of remote hooks with wildcards to run a function before any remote method is called, are given below:

0000<tables id="TABLE-US-00097" num="00097"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="14pt" align="left" /><colspec colname="2" colwidth="203pt" align="left" /><thead><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>// ** will match both prototype.* and *.*</entry></row><row><entry /><entry>User.beforeRemote(‘**’, function(ctx, user, next) {</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="28pt" align="left" /><colspec colname="2" colwidth="189pt" align="left" /><tbody valign="top"><row><entry /><entry>console.log(ctx.methodString, ‘was invoked remotely’); //</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="14pt" align="left" /><colspec colname="2" colwidth="203pt" align="left" /><tbody valign="top"><row><entry /><entry>users.prototype.save was invoked remotely</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="28pt" align="left" /><colspec colname="2" colwidth="189pt" align="left" /><tbody valign="top"><row><entry /><entry>next( );</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="14pt" align="left" /><colspec colname="2" colwidth="203pt" align="left" /><tbody valign="top"><row><entry /><entry>});</entry></row><row><entry /><entry>Other wildcard examples</entry></row><row><entry /><entry>// run before any static method eg. User.find</entry></row><row><entry /><entry>User.beforeRemote(‘*’, ...);</entry></row><row><entry /><entry>// run before any instance method eg. User.prototype.save</entry></row><row><entry /><entry>User.beforeRemote(‘prototype.*’, ...);</entry></row><row><entry /><entry>// prevent password hashes from being sent to clients</entry></row><row><entry /><entry>User.afterRemote(‘**’, function (ctx, user, next) {</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="28pt" align="left" /><colspec colname="2" colwidth="189pt" align="left" /><tbody valign="top"><row><entry /><entry>if(ctx.result) {</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="42pt" align="left" /><colspec colname="2" colwidth="175pt" align="left" /><tbody valign="top"><row><entry /><entry>if(Array.isArray(ctx.result)) {</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="56pt" align="left" /><colspec colname="2" colwidth="161pt" align="left" /><tbody valign="top"><row><entry /><entry>ctx.result.forEach(function (result) {</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="70pt" align="left" /><colspec colname="2" colwidth="147pt" align="left" /><tbody valign="top"><row><entry /><entry>result.password = undefined;</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="56pt" align="left" /><colspec colname="2" colwidth="161pt" align="left" /><tbody valign="top"><row><entry /><entry>});</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="42pt" align="left" /><colspec colname="2" colwidth="175pt" align="left" /><tbody valign="top"><row><entry /><entry>} else {</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="56pt" align="left" /><colspec colname="2" colwidth="161pt" align="left" /><tbody valign="top"><row><entry /><entry>ctx.result.password = undefined;</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="42pt" align="left" /><colspec colname="2" colwidth="175pt" align="left" /><tbody valign="top"><row><entry /><entry>}</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="28pt" align="left" /><colspec colname="2" colwidth="189pt" align="left" /><tbody valign="top"><row><entry /><entry>}</entry></row><row><entry /><entry>next( );</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="14pt" align="left" /><colspec colname="2" colwidth="203pt" align="left" /><tbody valign="top"><row><entry /><entry>});</entry></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0244In some embodiment, remote hooks are provided with a Context ctx object that contains transport-specific data (for HTTP: req and res). The ctx object also has a set of consistent APIs across transports. In some embodiments, applications that use loopback.rest( ) middleware, provide additional ctx properties such as ctx.req for expressing Request object; ctx.res for expressing Response object; ctx.req.accessToken for accessing token of the user calling the remote method (ctx.req.accessToken is undefined if the remote method is not invoked by a logged in user (or other principal)); and ctx.result (during afterRemote hooks) which will contain the data that is about to be sent to a client (a user can modify this object to transform data before it is sent). In addition to the hooks mentioned above, the user of some embodiments can define the following other hooks: <ul id="ul0027" list-style="none"><li id="ul0027-0001" num="0000"><ul id="ul0028" list-style="none"><li id="ul0028-0001" num="0245">afterInitialize,</li><li id="ul0028-0002" num="0246">beforeValidate/afterValidate,</li><li id="ul0028-0003" num="0247">beforeSave/afterSave,</li><li id="ul0028-0004" num="0248">beforeCreate/afterCreate,</li><li id="ul0028-0005" num="0249">beforeUpdate/afterUpdate, and</li><li id="ul0028-0006" num="0250">beforeDestroy/afterDestroy.</li></ul></li></ul>

0251As described before, a schema defines a static model that is backed by a database. A model can validate data before passing it on to a data store (such as a database) to ensure that it conforms to the backend schema. For example, the following code defines a schema and assigns it to the product model. The schema defines two fields (columns): name, a string, and price, a number. The field name is a required value.

0000<tables id="TABLE-US-00098" num="00098"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="28pt" align="left" /><colspec colname="1" colwidth="189pt" align="left" /><thead><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>var productSchema = {</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="42pt" align="left" /><colspec colname="1" colwidth="175pt" align="left" /><tbody valign="top"><row><entry /><entry>“name”: { “type”: “string”, “required”: true },</entry></row><row><entry /><entry>“price”: “number”</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="28pt" align="left" /><colspec colname="1" colwidth="189pt" align="left" /><tbody valign="top"><row><entry /><entry>};</entry></row><row><entry /><entry>var Product = Model.extend(‘product’,</entry></row><row><entry /><entry>productSchema);</entry></row><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0252A schema imposes restrictions on the model. If a remote client tries to save a product with extra properties (e.g., description), those properties are removed before the application saves the data in the model. Also, since name is a required value, the model will only be saved if the product contains a value for the name property. Rather than modifying the error responses returned by the server, the developer of some embodiments can localize the error message on the client. The validation error response contains error codes in error.details.codes, which enables clients to map errors to localized messages. Below is an example error response:

0000<tables id="TABLE-US-00099" num="00099"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="28pt" align="left" /><colspec colname="1" colwidth="189pt" align="left" /><thead><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>{</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="42pt" align="left" /><colspec colname="1" colwidth="175pt" align="left" /><tbody valign="top"><row><entry /><entry>“name”: “ValidationError”,</entry></row><row><entry /><entry>“status”: 422,</entry></row><row><entry /><entry>“message”: “The Model instance is not valid. \</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="28pt" align="left" /><colspec colname="1" colwidth="189pt" align="left" /><tbody valign="top"><row><entry /><entry>See {grave over ( )}details{grave over ( )} property of the error object for more info.”,</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="42pt" align="left" /><colspec colname="1" colwidth="175pt" align="left" /><tbody valign="top"><row><entry /><entry>“statusCode”: 422,</entry></row><row><entry /><entry>“details”: {</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="56pt" align="left" /><colspec colname="1" colwidth="161pt" align="left" /><tbody valign="top"><row><entry /><entry>“context”: “user”,</entry></row><row><entry /><entry>“codes”: {</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="70pt" align="left" /><colspec colname="1" colwidth="147pt" align="left" /><tbody valign="top"><row><entry /><entry>“password”: [</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="84pt" align="left" /><colspec colname="1" colwidth="133pt" align="left" /><tbody valign="top"><row><entry /><entry>“presence”</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="70pt" align="left" /><colspec colname="1" colwidth="147pt" align="left" /><tbody valign="top"><row><entry /><entry>],</entry></row><row><entry /><entry>“email”: [</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="84pt" align="left" /><colspec colname="1" colwidth="133pt" align="left" /><tbody valign="top"><row><entry /><entry>“uniqueness”</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="70pt" align="left" /><colspec colname="1" colwidth="147pt" align="left" /><tbody valign="top"><row><entry /><entry>]</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="42pt" align="left" /><colspec colname="1" colwidth="175pt" align="left" /><tbody valign="top"><row><entry /><entry>},</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="56pt" align="left" /><colspec colname="1" colwidth="161pt" align="left" /><tbody valign="top"><row><entry /><entry>“messages”: {</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="70pt" align="left" /><colspec colname="1" colwidth="147pt" align="left" /><tbody valign="top"><row><entry /><entry>“password”: [</entry></row><row><entry /><entry> “can’t be blank”</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="56pt" align="left" /><colspec colname="1" colwidth="161pt" align="left" /><tbody valign="top"><row><entry /><entry>],</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="70pt" align="left" /><colspec colname="1" colwidth="147pt" align="left" /><tbody valign="top"><row><entry /><entry>“email”: [</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="84pt" align="left" /><colspec colname="1" colwidth="133pt" align="left" /><tbody valign="top"><row><entry /><entry>“Email already exists”</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="70pt" align="left" /><colspec colname="1" colwidth="147pt" align="left" /><tbody valign="top"><row><entry /><entry>]</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="56pt" align="left" /><colspec colname="1" colwidth="161pt" align="left" /><tbody valign="top"><row><entry /><entry>}</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="42pt" align="left" /><colspec colname="1" colwidth="175pt" align="left" /><tbody valign="top"><row><entry /><entry>}</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="28pt" align="left" /><colspec colname="1" colwidth="189pt" align="left" /><tbody valign="top"><row><entry /><entry>}</entry></row><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0253As stated before, most applications need to implement authentication and authorization on the users who access the data (i.e., control who (or what) can access data). Typically, this involves requiring users to login to access protected data, or requiring authorization tokens for other applications to access protected data.

0254Applications of some embodiments access data through models, hence controlling access to data means putting restrictions on models. That is, specifying who or what can read, write, or change the data in the models. In some embodiments, the general process to implement access control for an application is first to define the user roles that the application requires. For example, the developer might create roles for anonymous users, authorized users, and administrators.

0255Next, the developer can define access for each role and model method. For example, the developer might enable anonymous users to read a list of banks, but not allow them to do anything else. In some embodiments, the models have a set of built-in methods, and each method maps to either the READ or WRITE access type. In essence, this step amounts to specifying whether access is allowed for each role and each model in addition to the access type. Lastly, the developer implements the authentication, i.e., in the application, by adding code to create (register) new users, login users (get and use authentication tokens), and logout users.

0256In order to control data access, the application developer specifies the application's users' roles. The first step in specifying user roles is to determine what roles the application needs. Most applications will have un-authenticated or anonymous users (those who have not logged in) and authenticated users (those who have logged in). Additionally, many applications will have an administrative role that provides broad access rights. Applications of some embodiments can have any number of additional user roles as appropriate.

0257The next step is specifying the user access types. The framework in some embodiments provides a built-in User model with a corresponding REST API that inherits all the “CRUD” (create, read, update, and delete) methods of the data access object. Each data access method on the User model maps to either the “READ” or “WRITE” access type, as follows: <ul id="ul0029" list-style="none"><li id="ul0029-0001" num="0000"><ul id="ul0030" list-style="none"><li id="ul0030-0001" num="0258">READ: <ul id="ul0031" list-style="none"><li id="ul0031-0001" num="0259">exists—Boolean method that determines whether a user exists</li><li id="ul0031-0002" num="0260">findById—Find a user by ID</li><li id="ul0031-0003" num="0261">find—Find all users that match specified conditions.</li><li id="ul0031-0004" num="0262">findOne—Finds a single user instance that matches specified conditions.</li><li id="ul0031-0005" num="0263">count—Returns the number of users that match the specified conditions.</li></ul></li><li id="ul0030-0002" num="0264">WRITE: <ul id="ul0032" list-style="none"><li id="ul0032-0001" num="0265">create—create a new user</li><li id="ul0032-0002" num="0266">upsert (equivalent to updateOrCreate)—update or insert a new user record.</li><li id="ul0032-0003" num="0267">deleteById (equivalent to removeById or destroyById)—delete the user with the specified ID.</li></ul></li></ul></li></ul>

0268For other methods, the default access type of some embodiments is “EXECUTE”. For example, a custom method maps to the “EXECUTE” access type. The table below is an example of the access control specification for an access control application of some embodiments. It specifies “ALLOW” or “DENY” for any combination of role and access types (READ or WRITE for a specific model).

0000<tables id="TABLE-US-00100" num="00100"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="4"><colspec colname="1" colwidth="70pt" align="left" /><colspec colname="2" colwidth="49pt" align="left" /><colspec colname="3" colwidth="56pt" align="left" /><colspec colname="4" colwidth="42pt" align="left" /><thead><row><entry namest="1" nameend="4" align="center" rowsep="1" /></row><row><entry>Model and</entry><entry>Anonymous</entry><entry>Authenticated</entry><entry>Teller</entry></row><row><entry>access type</entry><entry>user role</entry><entry>user role</entry><entry>(admin) role</entry></row><row><entry namest="1" nameend="4" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>READ Bank</entry><entry>ALLOW</entry><entry>ALLOW</entry><entry>ALLOW</entry></row><row><entry>WRITE Bank</entry><entry>DENY</entry><entry>DENY</entry><entry>ALLOW</entry></row><row><entry>READ Account</entry><entry>DENY</entry><entry>ALLOW</entry><entry>ALLOW</entry></row><row><entry>WRITE Account</entry><entry>DENY</entry><entry>DENY</entry><entry>ALLOW</entry></row><row><entry>READ Transaction</entry><entry>DENY</entry><entry>ALLOW</entry><entry>ALLOW</entry></row><row><entry>WRITE Transaction</entry><entry>DENY</entry><entry>DENY</entry><entry>DENY</entry></row><row><entry namest="1" nameend="4" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0269Some embodiments use the Yeoman ACL generator to define access controls as the simplest way to define access control for an application. This enables the developer to create a static definition for the application before runtime. The Yeoman generator prompts the developer for all the necessary information as explained below. In some embodiments, the basic process for an application to create and authenticate users is first to register a new user with the User.create( ) method, inherited from the generic model object. The next step is to call User.login( ) to request an access token from the client application on behalf of the user. The developer can create his own access tokens to customize authentication. User.login( ) is a good example of doing that. The developer needs to do verification on the server though to prevent someone from creating tokens even though they don't belong to them. The last step is then to invoke an API using the access token. The developer can provide the access token in the HTTP header or as a query parameter to the REST API call.

0270In order to create users, an application developer can create (register) a new user with the User.create method as follows (on a client side with calling a REST API and on the server side writing in JS):

0000<tables id="TABLE-US-00101" num="00101"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="left" /><thead><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>REST</entry></row><row><entry>curl -X POST -H “Content-Type:application/json” \</entry></row><row><entry>-d ‘{“email”: “me@domain.com”, “password”: “secret”}’ \</entry></row><row><entry>http://localhost:3000/api/users</entry></row><row><entry>Node.js</entry></row><row><entry>User.create({</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="14pt" align="left" /><colspec colname="1" colwidth="203pt" align="left" /><tbody valign="top"><row><entry /><entry>email: ‘me@domain.com’, // required by default</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="offset" colwidth="14pt" align="left" /><colspec colname="1" colwidth="70pt" align="left" /><colspec colname="2" colwidth="133pt" align="left" /><tbody valign="top"><row><entry /><entry>password: ‘secret’</entry><entry>// required by default</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="left" /><tbody valign="top"><row><entry>}, function (err, user) {</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="14pt" align="left" /><colspec colname="1" colwidth="203pt" align="left" /><tbody valign="top"><row><entry /><entry>console.log(user.id); // => the user id (default type: db specific |</entry></row><row><entry /><entry>number)</entry></row><row><entry /><entry>console.log(user.email); // => the user’s email</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="left" /><tbody valign="top"><row><entry>});</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0271Typically, the developer might want to add methods to use as a part of the registration process to determine whether a given username is available or if an email address is already registered. One way to do this is to add these methods as beforeRemote hooks on the User object. The developer then can authenticate a user by calling the User.login( ) method and providing a credentials object. By default, each user must provide a password and either a username or email. The developer may also specify how long the access token should be valid by providing a ttl (time to live) in a temporal scale (e.g., in seconds). The following example illustrates this on a client side with calling a REST API and on the server side in JS:

0000<tables id="TABLE-US-00102" num="00102"><table frame="none" colsep="0" rowsep="0" pgwide="1"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="14pt" align="left" /><colspec colname="1" colwidth="259pt" align="left" /><thead><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>REST</entry></row><row><entry /><entry>curl -X POST -H “Content-Type:application/json” \</entry></row><row><entry /><entry>-d ‘{“email”: “me@domain.com”, “password”: “secret”, “ttl”: 1209600000}’ \</entry></row><row><entry /><entry>http://localhost:3000/api/users/login</entry></row><row><entry /><entry>This example returns:</entry></row><row><entry /><entry>{</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="28pt" align="left" /><colspec colname="1" colwidth="245pt" align="left" /><tbody valign="top"><row><entry /><entry>“id”:</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="273pt" align="left" /><tbody valign="top"><row><entry>“GOkZRwgZ61q0XXVxvxlB8TS1D6lrG7Vb9V8YwRDfy3YGAN7TM7EnxWHqdbIZfheZ”,</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="28pt" align="left" /><colspec colname="1" colwidth="245pt" align="left" /><tbody valign="top"><row><entry /><entry>“ttl”: 1209600,</entry></row><row><entry /><entry>“created”: “2013-12-20T21:10:20.377Z”,</entry></row><row><entry /><entry>“userId”: 1</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="14pt" align="left" /><colspec colname="1" colwidth="259pt" align="left" /><tbody valign="top"><row><entry /><entry>}</entry></row><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0272The id property in this example is the user's access token.

0000<tables id="TABLE-US-00103" num="00103"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="left" /><thead><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>Node.js</entry></row><row><entry>var TWO_WEEKS = 1000 * 60 * 60 * 24 * 7 * 2;</entry></row><row><entry>User.login({</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="offset" colwidth="14pt" align="left" /><colspec colname="1" colwidth="98pt" align="left" /><colspec colname="2" colwidth="105pt" align="left" /><tbody valign="top"><row><entry /><entry>email: ‘me@domain.com’,</entry><entry>// must provide email or</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="112pt" align="left" /><colspec colname="1" colwidth="105pt" align="left" /><tbody valign="top"><row><entry /><entry>“username”</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="offset" colwidth="14pt" align="left" /><colspec colname="1" colwidth="77pt" align="left" /><colspec colname="2" colwidth="126pt" align="left" /><tbody valign="top"><row><entry /><entry>password: ‘secret’,</entry><entry>// required by default</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="offset" colwidth="14pt" align="left" /><colspec colname="1" colwidth="91pt" align="left" /><colspec colname="2" colwidth="112pt" align="left" /><tbody valign="top"><row><entry /><entry>ttl: TWO_WEEKS</entry><entry>// keep the AccessToken alive for at</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="105pt" align="left" /><colspec colname="1" colwidth="112pt" align="left" /><tbody valign="top"><row><entry /><entry>least two weeks</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="left" /><tbody valign="top"><row><entry>}, function (err, accessToken) {</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="14pt" align="left" /><colspec colname="1" colwidth="203pt" align="left" /><tbody valign="top"><row><entry /><entry>console.log(accessToken.id); // => GOkZRwg... the access token</entry></row><row><entry /><entry>console.log(accessToken.ttl); // => 1209600 time to live</entry></row><row><entry /><entry>console.log(accessToken.created); // => 2013-12-20T21:10:20.377Z</entry></row><row><entry /><entry>console.log(accessToken.userId); // => 1</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="left" /><tbody valign="top"><row><entry>});</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0273If a login attempt is successful, a new AccessToken is created that points to the user. This token is required when making subsequent REST requests for the access control system to validate that the user can invoke methods on a given Model.

0000<tables id="TABLE-US-00104" num="00104"><table frame="none" colsep="0" rowsep="0" pgwide="1"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="294pt" align="left" /><thead><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>REST</entry></row><row><entry>ACCESS_TOKEN=6Nb2ti5QEXIoDBS5FQGWIz4poRFiBCMMYJbYXSGHWuulOuy0GTEuGx2-</entry></row><row><entry>VCEVvbpBK</entry></row><row><entry># Authorization Header</entry></row><row><entry>curl -X GET -H “Authorization: $ACCESS_TOKEN” \</entry></row><row><entry>http://localhost:3000/api/widgets</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="14pt" align="left" /><colspec colname="1" colwidth="280pt" align="left" /><tbody valign="top"><row><entry /><entry># Query Parameter</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="294pt" align="left" /><tbody valign="top"><row><entry>curl -X GET http://localhost:3000/api/widgets?access_token=$ACCESS_TOKEN</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0274A user will be effectively logged out by deleting the access token they were issued at login. This affects only the specified access token; other tokens attached to the user will still be valid. To destroy access tokens over REST API, the following /logout endpoint can be used:

0000<tables id="TABLE-US-00105" num="00105"><table frame="none" colsep="0" rowsep="0" pgwide="1"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="14pt" align="left" /><colspec colname="1" colwidth="294pt" align="left" /><thead><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>REST</entry></row><row><entry /><entry>ACCESS_TOKEN=6Nb2ti5QEXIoDBS5FQGWIz4poRFiBCMMYJbYXSGHWuulOuy0GTEuGx-</entry></row><row><entry /><entry>2VCEVvbpBK</entry></row><row><entry /><entry>VERB=POST # any verb is allowed</entry></row><row><entry /><entry># Authorization Header</entry></row><row><entry /><entry>curl -X VERB -H “Authorization: $ACCESS_TOKEN” \</entry></row><row><entry /><entry>http://localhost:3000/api/users/logout</entry></row><row><entry /><entry># Query Parameter</entry></row><row><entry /><entry>curl -X VERB http://localhost:3000/api/users/logout?access_token=$ACCESS_TOKEN</entry></row><row><entry /><entry>Node.js</entry></row><row><entry /><entry>varUSER_ID = l;</entry></row><row><entry /><entry>var ACCESS_TOKEN = ‘6Nb2ti5QEXIoDBS5FQGWIz4poRFiBCMMYJbYXSGHWuulOuy0GT-</entry></row><row><entry /><entry>EuGx2VCEVvbpBK’;</entry></row><row><entry /><entry>// remove just the token</entry></row><row><entry /><entry>var token = new AccessToken({id: ACCESS_TOKEN});</entry></row><row><entry /><entry>token.destroy( );</entry></row><row><entry /><entry>// remove all user tokens</entry></row><row><entry /><entry>AccessToken.destroyAll({</entry></row><row><entry /><entry>where: {userId: USER_ID}</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="308pt" align="left" /><tbody valign="top"><row><entry>});</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0275As described before, in order to control data access, the first step is to specify the application users' roles. The framework of some embodiments enables the developer to define both static and dynamic roles. Static roles are stored in a data source and are mapped to users. In contrast, dynamic roles are not assigned to users and are determined during access. Below is an example of defining a new static role and assigning a user to that role:

0000<tables id="TABLE-US-00106" num="00106"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="left" /><thead><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>// Create a new user</entry></row><row><entry>User.create({name: ‘John’, email: ‘x@y.com’, password: ‘foobar’},</entry></row><row><entry>function (err, user) {</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="14pt" align="left" /><colspec colname="1" colwidth="203pt" align="left" /><tbody valign="top"><row><entry /><entry>// Create the static admin Role</entry></row><row><entry /><entry>Role.create({name: ‘admin’}, function (err, role) {</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="28pt" align="left" /><colspec colname="1" colwidth="189pt" align="left" /><tbody valign="top"><row><entry /><entry>// Make John an admin</entry></row><row><entry /><entry>role.principals.create({principalType: RoleMapping.USER,</entry></row><row><entry /><entry>principalId: user.id});</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="14pt" align="left" /><colspec colname="1" colwidth="203pt" align="left" /><tbody valign="top"><row><entry /><entry>});</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="left" /><tbody valign="top"><row><entry>});</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0276After defining the new static role, the developer can use the role in the access controls. For example, the developer can add the following lines to the file models.json to enable users in the “admin” role to call all REST APIs:

0000<tables id="TABLE-US-00107" num="00107"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="56pt" align="left" /><colspec colname="1" colwidth="161pt" align="left" /><thead><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>{</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="70pt" align="left" /><colspec colname="1" colwidth="147pt" align="left" /><tbody valign="top"><row><entry /><entry>“accessType”: “*”,</entry></row><row><entry /><entry>“permission”: “ALLOW”,</entry></row><row><entry /><entry>“principalType”: “ROLE”,</entry></row><row><entry /><entry>“principalId”: “admin”</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="56pt" align="left" /><colspec colname="1" colwidth="161pt" align="left" /><tbody valign="top"><row><entry /><entry>}</entry></row><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0277Sometimes static roles of some embodiments are not flexible enough and therefore dynamic roles are needed. Below is an example of defining a user defined dynamic role:

0000<tables id="TABLE-US-00108" num="00108"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="14pt" align="left" /><colspec colname="1" colwidth="203pt" align="left" /><thead><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>Role.registerResolver(‘$friend’, function(role, ctx, callback) {</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="28pt" align="left" /><colspec colname="1" colwidth="189pt" align="left" /><tbody valign="top"><row><entry /><entry>var targetUserId = ctx.modelId;</entry></row><row><entry /><entry>// Below has a callback signature: callback(err, isFriend)</entry></row><row><entry /><entry>MyUser.isFriend(targetUserId, ctx.getUserId( ), callback);</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="14pt" align="left" /><colspec colname="1" colwidth="203pt" align="left" /><tbody valign="top"><row><entry /><entry>});</entry></row><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables><br /> Using the dynamic role defined above, we can restrict access of user info to users that are friends.

0000<tables id="TABLE-US-00109" num="00109"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="56pt" align="left" /><colspec colname="1" colwidth="161pt" align="left" /><thead><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>{</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="70pt" align="left" /><colspec colname="1" colwidth="147pt" align="left" /><tbody valign="top"><row><entry /><entry>“accessType”: “READ”,</entry></row><row><entry /><entry>“permission”: “ALLOW”,</entry></row><row><entry /><entry>“principalType”: “ROLE”,</entry></row><row><entry /><entry>“principalId”: “$friend”</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="56pt" align="left" /><colspec colname="1" colwidth="161pt" align="left" /><tbody valign="top"><row><entry /><entry>}</entry></row><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0278Some embodiments allow to manually enable the access controls. However, in these embodiments, if the application is created with slc loopback, then there is no need to do anything to enable the access control. Otherwise, to add access control manually, the developer must call the LoopBack enableAuth( ) method. The following example shows how a user can manually add an access control:

0000<tables id="TABLE-US-00110" num="00110"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="49pt" align="left" /><colspec colname="1" colwidth="168pt" align="left" /><thead><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>var loopback = require(‘loopback’);</entry></row><row><entry /><entry>var app = loopback( );</entry></row><row><entry /><entry>app.enableAuth( );</entry></row><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0279In some applications, the developer may need to make changes to ACL definitions at runtime. There are two different ways to change ACL definitions at runtime: (1) call the data source method createModel( ) and provide an ACL specification (in JSDL) as an argument, and (2) call the ACL.create( ) method. A user can also control access to a model by passing a JSDL specification when creating the model with the data source createModel( ) method:

0000<tables id="TABLE-US-00111" num="00111"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="left" /><thead><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>var Customer = loopback.createModel(‘Customer’, {</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="28pt" align="left" /><colspec colname="1" colwidth="189pt" align="left" /><tbody valign="top"><row><entry /><entry>name: {</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="42pt" align="left" /><colspec colname="1" colwidth="175pt" align="left" /><tbody valign="top"><row><entry /><entry>type: String,</entry></row><row><entry /><entry>// Property level ACLs</entry></row><row><entry /><entry>acls: [</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="56pt" align="left" /><colspec colname="1" colwidth="161pt" align="left" /><tbody valign="top"><row><entry /><entry>{principalType: ACL.USER, principalId: ‘u001’,</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="left" /><tbody valign="top"><row><entry>accessType: ACL.WRITE, permission: ACL.DENY},</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="56pt" align="left" /><colspec colname="1" colwidth="161pt" align="left" /><tbody valign="top"><row><entry /><entry>{principalType: ACL.USER, principalId: ‘u001’,</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="left" /><tbody valign="top"><row><entry>accessType: ACL.ALL, permission: ACL.ALLOW}</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="42pt" align="left" /><colspec colname="1" colwidth="175pt" align="left" /><tbody valign="top"><row><entry /><entry>]</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="28pt" align="left" /><colspec colname="1" colwidth="189pt" align="left" /><tbody valign="top"><row><entry /><entry>}</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="14pt" align="left" /><colspec colname="1" colwidth="203pt" align="left" /><tbody valign="top"><row><entry /><entry>}, {</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="28pt" align="left" /><colspec colname="1" colwidth="189pt" align="left" /><tbody valign="top"><row><entry /><entry>// By default, access will be denied if no matching ACL entry</entry></row><row><entry /><entry>is found</entry></row><row><entry /><entry>defaultPermission: ACL.DENY,</entry></row><row><entry /><entry>// Model level ACLs</entry></row><row><entry /><entry>acls: [</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="42pt" align="left" /><colspec colname="1" colwidth="175pt" align="left" /><tbody valign="top"><row><entry /><entry>{principalType: ACL.USER, principalId: ‘u001’,</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="left" /><tbody valign="top"><row><entry>accessType: ACL.ALL, permission: ACL.ALLOW}</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="28pt" align="left" /><colspec colname="1" colwidth="189pt" align="left" /><tbody valign="top"><row><entry /><entry>]</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="14pt" align="left" /><colspec colname="1" colwidth="203pt" align="left" /><tbody valign="top"><row><entry /><entry>});</entry></row><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0280ACLs defined as part of the model creation are hard-coded into the application. The framework of some embodiments also allows the user to dynamically define ACLs through code or a dashboard. The ACLs can also be saved to and loaded from a database in some embodiments.

0281In general, some client applications (e.g., mobile applications) need to be able to operate without constant network connectivity. This means the client application must synchronize data with the server application after a disconnection period. In order to achieve synchronization, (1) the client (browser) application should replicate changes made in the server application, and (2) the server application should replicate the changes made in the client (browser) application. The synchronization (sync) process replicates data from the source to the target, and the target calls a replication API. The replication API of some embodiments is a JavaScript API, and thus works with a JavaScript client. The replication API of other embodiments can be other non-JS APIs that can run on non-JS clients.

0282Replication means intelligently copying data from one location to another. The framework copies data that has changed from source to target, but does not overwrite data that was modified on the target since the last replication. So, the sync process of some embodiments is a bi-directional replication. In general, there may be conflicts when performing replication. For example, while disconnected, a user may make changes on the client that conflict with changes made on the server. When an object or field is modified both locally and remotely and there is a risk of generating conflicts, the framework of some embodiments handles the conflict resolution for the users, and enables the developers to easily present a user interface in the application to allow the end user to make informed decisions to resolve conflicts when they occur.

0283The framework of some embodiments implements synchronization using the browser API that provides the same client JS API as for the server. Thus, the framework in the browser is sometimes referred to as isomorphic, because a user can call exactly the same APIs on the client and server. The framework in the browser of some embodiments uses Browserify to handle dependencies and gulp to generate the client API based on the backend models and REST API.

0284In addition to basic client-server replication, the framework of some embodiments also supports replicating data (1) from a server application to another server application and (2) from one database to another database. Synchronization as described above to handle offline operation is called offline sync in some embodiments. The framework also provides the ability to consolidate (or “batch”) data changes the user makes on the device and send them to the server in a single HTTP request. This type of synchronization is called online sync in some embodiments.

0285A conflict occurs when a change to a model is not based on the previous revision of the model. The callback of Model.replicate( ) takes err and conflict[ ]. Each conflict represents a change that was not replicated and must be manually resolved. The developer can fetch the current versions of the local and remote models by calling conflict.models( ). The developer can also manually merge the conflict by modifying both models. Calling conflict.resolve( ) will set the source change's previous revision to the current revision of the (conflicting) target change. Since the changes are no longer conflicting and appear as if the source change was based on the target, they will be replicated normally as part of the next replicate( ) call.

0286The model object provides a number of methods to support sync, mixed in via the DataModel object. Some of these sync methods are as follows: <ul id="ul0033" list-style="none"><li id="ul0033-0001" num="0000"><ul id="ul0034" list-style="none"><li id="ul0034-0001" num="0287">1. diff—Get a set of deltas and conflicts since the given checkpoint.</li><li id="ul0034-0002" num="0288">2. changes—Get the changes to a model since a given checkpoint. Provide a filter object to reduce the number of results returned.</li><li id="ul0034-0003" num="0289">3. checkpoint—Create a checkpoint.</li><li id="ul0034-0004" num="0290">4. currentCheckpoint—Get the current checkpoint ID.</li><li id="ul0034-0005" num="0291">5. replicate—Replicate changes since the given checkpoint to the given target model.</li><li id="ul0034-0006" num="0292">6. createUpdates—Create an update list for Model.bulkUpdate( ) from a delta list from Change.diff( ).</li><li id="ul0034-0007" num="0293">7. bulkUpdate—Apply an update list.</li><li id="ul0034-0008" num="0294">8. getChangeModel—Get the Change model.</li><li id="ul0034-0009" num="0295">9. getSourceId—Get the source identifier for this model/dataSource.</li><li id="ul0034-0010" num="0296">10. enableChangeTracking—Start tracking changes made to the model.</li><li id="ul0034-0011" num="0297">11. handleChangeError—Handle a change error. Override this method in a subclassing model to customize change error handling.</li><li id="ul0034-0012" num="0298">12. rectifyChange—Tell the framework that a change to the model with the given ID has occurred.</li><li id="ul0034-0013" num="0299">13. Created—an entry in the change list without a previous revision or if an entry does not exist and the given model does exist</li><li id="ul0034-0014" num="0300">14. Modified—an entry with a current and previous revision</li><li id="ul0034-0015" num="0301">15. Deleted—an entry with only a previous revision or if an entry does not exist and the given model also does not exist</li></ul></li></ul>

0302In some embodiments, the change list and replication can be used against existing data sources with large sets of data. This is made possible by using the revision semantics described above. The changes made without the framework API, however, will be treated as “created” or “deleted” change list entries. The Changes made to a data source that supports replication will be tracked as revisions in that data source's change list. A data source's change list is stored like any other model data. Each model has its own “Change” model. The “Change” model may be attached to any data source. This allows the user to store the change lists in any data source.

0303During replication a user may supply a filter in some embodiments. The less data the user tries to replicate, the faster and more memory efficient the replication will be. If the user is manually implementing the replication algorithm, the user should run as many steps in the replication process in parallel as possible. This is usually called the “bulk update” step(s).

0304As discussed above, the framework in the client machine is sometimes referred to as isomorphic framework, because it provides the exact same API as the server framework. A user can create models and use the memory adapter and have his application fully running in the browser machine. The user can seamlessly connect models using the Remote Connector to connect different devices (e.g., browser to server or server to server). Some embodiments accomplish this by enhancing remoting to be able to accept and return ModelTypes in addition to the JSON and its JSON primitives. Because the models do not need to know where they are being run, the developer can share the same API regardless of where developer's code is running, thus making the API isomorphic. Models are referenced through one way—“local” versus “remote”. This is a foundation for how the replication API for data synchronization between browser and server is built in some embodiments.

0305In the browser, the main application file calls the function exported by the boot module to setup the application by executing the instructions contained in the browser bundle:

0000<tables id="TABLE-US-00112" num="00112"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="42pt" align="left" /><colspec colname="1" colwidth="175pt" align="left" /><thead><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>browser-app.js</entry></row><row><entry /><entry>var loopback = require(‘loopback’);</entry></row><row><entry /><entry>var boot = require(‘loopback-boot’);</entry></row><row><entry /><entry>var app = module.exports = loopback( );</entry></row><row><entry /><entry>boot(app);</entry></row><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables><br /> The application object created above can be accessed via require(‘loopback-app’), where loopback-application is the identifier used for the main application file in the Browserify build shown above. Below is a simple example demonstrating this concept:

0000<tables id="TABLE-US-00113" num="00113"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="35pt" align="left" /><colspec colname="1" colwidth="182pt" align="left" /><thead><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>index.html</entry></row><row><entry /><entry><script src=“app.bundle.js”> </script></entry></row><row><entry /><entry><script></entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="49pt" align="left" /><colspec colname="1" colwidth="168pt" align="left" /><tbody valign="top"><row><entry /><entry>var app = require(‘loopback-app’);</entry></row><row><entry /><entry>var User = app.models.User;</entry></row><row><entry /><entry>User.login({</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="63pt" align="left" /><colspec colname="1" colwidth="154pt" align="left" /><tbody valign="top"><row><entry /><entry>email: ‘test@example.com’,</entry></row><row><entry /><entry>password: ‘12345’</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="49pt" align="left" /><colspec colname="1" colwidth="168pt" align="left" /><tbody valign="top"><row><entry /><entry>}, function(err, res) {</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="63pt" align="left" /><colspec colname="1" colwidth="154pt" align="left" /><tbody valign="top"><row><entry /><entry>if (err) {</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="77pt" align="left" /><colspec colname="1" colwidth="140pt" align="left" /><tbody valign="top"><row><entry /><entry>console.error(‘Login failed: ’, err);</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="63pt" align="left" /><colspec colname="1" colwidth="154pt" align="left" /><tbody valign="top"><row><entry /><entry>} else {</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="77pt" align="left" /><colspec colname="1" colwidth="140pt" align="left" /><tbody valign="top"><row><entry /><entry>console.log(‘Logged in.’);</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="63pt" align="left" /><colspec colname="1" colwidth="154pt" align="left" /><tbody valign="top"><row><entry /><entry>}</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="49pt" align="left" /><colspec colname="1" colwidth="168pt" align="left" /><tbody valign="top"><row><entry /><entry>});</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="35pt" align="left" /><colspec colname="1" colwidth="182pt" align="left" /><tbody valign="top"><row><entry /><entry></script></entry></row><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0306Many of the above-described features and applications are implemented as software processes that are specified as a set of instructions recorded on a computer readable storage medium (also referred to as computer readable medium). When these instructions are executed by one or more processing unit(s) (e.g., one or more processors, cores of processors, or other processing units), they cause the processing unit(s) to perform the actions indicated in the instructions. Examples of computer readable media include, but are not limited to, CD-ROMs, flash drives, RAM chips, hard drives, EPROMs, etc. The computer readable media does not include carrier waves and electronic signals passing wirelessly or over wired connections.

0307In this specification, the term “software” is meant to include firmware residing in read-only memory or applications stored in magnetic storage, which can be read into memory for processing by a processor. Also, in some embodiments, multiple software inventions can be implemented as sub-parts of a larger program while remaining distinct software inventions. In some embodiments, multiple software inventions can also be implemented as separate programs. Finally, any combination of separate programs that together implement a software invention described here is within the scope of the invention. In some embodiments, the software programs, when installed to operate on one or more electronic systems, define one or more specific machine implementations that execute and perform the operations of the software programs.

0308<figref idref="DRAWINGS">FIG. 8</figref> conceptually illustrates an electronic system <b>800</b> with which some embodiments of the invention are implemented. The electronic system <b>800</b> may be a computer (e.g., a desktop computer, personal computer, tablet computer, server computer, mainframe, a blade computer etc.), phone, PDA, or any other sort of electronic device. Such an electronic system includes various types of computer readable media and interfaces for various other types of computer readable media. Electronic system <b>800</b> includes a bus <b>805</b>, processing unit(s) <b>810</b>, a system memory <b>825</b>, a read-only memory <b>830</b>, a permanent storage device <b>835</b>, input devices <b>840</b>, and output devices <b>845</b>.

0309The bus <b>805</b> collectively represents all system, peripheral, and chipset buses that communicatively connect the numerous internal devices of the electronic system <b>800</b>. For instance, the bus <b>805</b> communicatively connects the processing unit(s) <b>810</b> with the read-only memory <b>830</b>, the system memory <b>825</b>, and the permanent storage device <b>835</b>.

0310From these various memory units, the processing unit(s) <b>810</b> retrieve instructions to execute and data to process in order to execute the processes of the invention. The processing unit(s) may be a single processor or a multi-core processor in different embodiments.

0311The read-only-memory (ROM) <b>830</b> stores static data and instructions that are needed by the processing unit(s) <b>810</b> and other modules of the electronic system. The permanent storage device <b>835</b>, on the other hand, is a read-and-write memory device. This device is a non-volatile memory unit that stores instructions and data even when the electronic system <b>800</b> is off. Some embodiments of the invention use a mass-storage device (such as a magnetic or optical disk and its corresponding disk drive) as the permanent storage device <b>835</b>.

0312Other embodiments use a removable storage device (such as a floppy disk, flash drive, etc.) as the permanent storage device. Like the permanent storage device <b>835</b>, the system memory <b>825</b> is a read-and-write memory device. However, unlike storage device <b>835</b>, the system memory is a volatile read-and-write memory, such a random access memory. The system memory stores some of the instructions and data that the processor needs at runtime. In some embodiments, the invention's processes are stored in the system memory <b>825</b>, the permanent storage device <b>835</b>, and/or the read-only memory <b>830</b>. From these various memory units, the processing unit(s) <b>810</b> retrieve instructions to execute and data to process in order to execute the processes of some embodiments.

0313The bus <b>805</b> also connects to the input and output devices <b>840</b> and <b>845</b>. The input devices enable the user to communicate information and select commands to the electronic system. The input devices <b>840</b> include alphanumeric keyboards and pointing devices (also called “cursor control devices”). The output devices <b>845</b> display images generated by the electronic system. The output devices include printers and display devices, such as cathode ray tubes (CRT) or liquid crystal displays (LCD). Some embodiments include devices such as a touchscreen that function as both input and output devices.

0314Finally, as shown in <figref idref="DRAWINGS">FIG. 8</figref>, bus <b>805</b> also couples electronic system <b>800</b> to a network <b>865</b> through a network adapter (not shown). In this manner, the computer can be a part of a network of computers (such as a local area network (“LAN”), a wide area network (“WAN”), or an Intranet, or a network of networks, such as the Internet. Any or all components of electronic system <b>800</b> may be used in conjunction with the invention.

0315Some embodiments include electronic components, such as microprocessors, storage and memory that store computer program instructions in a machine-readable or computer-readable medium (alternatively referred to as computer-readable storage media, machine-readable media, or machine-readable storage media). Some examples of such computer-readable media include RAM, ROM, read-only compact discs (CD-ROM), recordable compact discs (CD-R), rewritable compact discs (CD-RW), read-only digital versatile discs (e.g., DVD-ROM, dual-layer DVD-ROM), a variety of recordable/rewritable DVDs (e.g., DVD-RAM, DVD-RW, DVD+RW, etc.), flash memory (e.g., SD cards, mini-SD cards, micro-SD cards, etc.), magnetic and/or solid state hard drives, read-only and recordable Blu-Ray® discs, ultra density optical discs, any other optical or magnetic media, and floppy disks. The computer-readable media may store a computer program that is executable by at least one processing unit and includes sets of instructions for performing various operations. Examples of computer programs or computer code include machine code, such as is produced by a compiler, and files including higher-level code that are executed by a computer, an electronic component, or a microprocessor using an interpreter.

0316While the above discussion primarily refers to microprocessor or multi-core processors that execute software, some embodiments are performed by one or more integrated circuits, such as application specific integrated circuits (ASICs) or field programmable gate arrays (FPGAs). In some embodiments, such integrated circuits execute instructions that are stored on the circuit itself.

0317As used in this specification, the terms “computer”, “server”, “processor”, and “memory” all refer to electronic or other technological devices. These terms exclude people or groups of people. For the purposes of the specification, the terms display or displaying means displaying on an electronic device. As used in this specification, the terms “computer readable medium,” “computer readable media,” and “machine readable medium” are entirely restricted to tangible, physical objects that store information in a form that is readable by a computer. These terms exclude any wireless signals, wired download signals, and any other ephemeral or transitory signals.

0318While the invention has been described with reference to numerous specific details, one of ordinary skill in the art will recognize that the invention can be embodied in other specific forms without departing from the spirit of the invention. For instance, a number of the figures conceptually illustrate processes. The specific operations of these processes may not be performed in the exact order shown and described. The specific operations may not be performed in one continuous series of operations, and different specific operations may be performed in different embodiments. Furthermore, the process could be implemented using several sub-processes, or as part of a larger macro process. Therefore, one of ordinary skill in the art would understand that the invention is not to be limited by the foregoing illustrative details, but rather is to be defined by the appended claims.