This Gist provides a prototype of what a @latticework/quiles configuration might look like. (see Goals)
http://services.my-company.com
http://todo.services.my-company.com
http://todo.services.my-company.com/resources/todos
http://todo.services.my-company.com/resources/todo/routines/new-todo
- For DNS configuration: May have separate endpoints for internal access:
http://services.my-company.infra
http://services.my-company.com
Directory: http://services.my-company.com
Name Location Description todo http://todo.services.my-company.com Provides TODO application services.
- $schema is used in Visual Studio, but is it a standard?
- How should versions be handled?
- Version is currently at resource level. Is that correct?
- Should version be in path or in header? I like the idea of using either. But:
- We need to use client contracts for access. (What about discovery?)
{
"$schema": "http://quiles.io/schemas/v0.0.1/directory/schema#",
"uri": "http://services.my-company.com",
"services": [
{
"uri": "http://todo.services.my-company.com",
"description": {"$ref": "http://todo.services.my-company.com#"}
}
]
}
Property | Description |
---|---|
$schema | Specifies conforming JSON Schema |
uri | For DNS: URL of directory |
For distributed config: directory URI |
Property | Description |
---|---|
uri | Unique name of resource and path rooted at service uri |
description | JSON Pointer to Resource description (i.e., resourcequiles.json) folder |
{
"$schema": "http://quiles.io/schemas/v0.0.1/service/schema#",
"uri": "http://todo.services.my-company.intra",
"name": "todo",
"resources": [
{
"uri": "/resources/todo",
"description": {"$ref": "/resources/todo#"}
}
]
}
Property | Description |
---|---|
$schema | Specifies conforming JSON Schema |
uri | For DNS: Rooted path to service "load balancer" |
For distributed config: Unique service name | |
registry | The location of service registry |
name | Unique name of service in registry |
resources | List of resources provided by service |
Property | Description |
---|---|
uri | Unique name of resource and path rooted at service id |
description | JSON Pointer to Resource description (i.e., resourcequiles.json) folder |
uri
must be unique in the service and matchinguri
in quiles file.
Property | Description |
---|---|
uri | Unique name of resource |
For DNS: rooted at service uri | |
schema | JSON Schema of resouce |
routines | List of routines for resource |
Property | Description |
---|---|
uri | The URI of routine and root for relative paths |
description | JSON Pointer to Routine description (i.e., routinequiles.json) folder |
uri
must be unique in the service and matchinguri
in quiles file.
Property | Description |
---|---|
$schema | Specifies conforming JSON Schema |
uri | The uri of routine and root for relative paths |
resource | The resource on which the action is routine is being executed |
name | The routine's action name |
messages | Lists all messages associated with this routine's conversation |
uri
must be unique in the servicename
must be unique for the resource
resource
is in the path of the routineuri
. Does it function as a back pointer then? Is that the right division? Is it a reasonable convention?- What security information is needed?
Property | Description |
---|---|
verbopt | The message's HTTP Message type |
action | The message's action |
direction | Either to the resource or from the resource |
schema | The JSON Schema that defines the action. Includes Hyperschema |
action
must be unique within routine
- action should be should follow a vocabulary. Should there be a canonical set of actions?
- Is
to
sufficient to mark a message as an event? Probably not enough information. All subscribers would need to query the resource definition. Soundsverychatty. schema
could theoretically be inline. Good or bad? Enforce JSON Pointer? Can you?- Can you group a set of supporting routines, for reference id lookups? (Say you want to person id, for example, you would need to look up users.)
- Self description with HTML
- Self description static interface (i.e., hyperschema)
- Self description dynanic interface (i.e., hypermedia)
- REST based
- Supports HTTP
- Supports DNS routing
- Supports embedding REST in WebSockets
- Supports embedding REST in socket.io for public APIs.
- Supports destributed configuration manager for routing
- Supports embedding REST in brokered message queue transport.
- Supports versioning
- Semver'ed Server Contract
- Client Contracts
- Client Driven Server Contracts including Client Unit tests
- Supports scaling
- Asyncronous
- Reactive & Actor-based
- Self scaling
- Polyglot service implementation
- Provides PaaS container abstraction (i.e. "microcontainers")
- Provides explicit abstracted support for
- destributed configuration management
- metrics
- logging
- error/notification propegation
- Supports explicit abstracted support for security
- Authentication, Authorization, Accounting
- Ecryption, Hashing services, etc.
- Identity Services