Motivations

Some ideas that lead to creating this data persistence library:

• The API server defines the resources for my client application(s) to consume.
• The data models in the client application reflect the data format as presented by the API server.
• Define ORM concerns in one place, on the server.
• Less code means less bugs.
• Nomenclature that follows the API format and documentation.
• The server's cache settings are authoritative. The client application may also define caching concerns. The resource prototypes may honor the cache headers from the server response. (304's are fine. HTTP has solved caching already.)
• Given a list of resources which have duplicate data relationships, avoid redundant requests.
• Model prototypes may define the resource's states.
• Compute model properties from the resource attributes per the needs of the user interface.
• Define relationships between resources in a similar fashion to the API response format.
• The resources should keep track of their own meta data, relationships, and links. A resource's service should not need to construct URLs for operations on a resource.
• URLs are first class. The API server sends the links for the client to use.
• Use window.fetch or XHR.
• Background story: My Battle with Data Persistence in Ember Apps