...

• Nexus – Keeps track of Services and their Resources. Proxies requests between Services.
• Core – Manages People, Events and Involvement between them.
• Involvement Services
  • Programme – Manages scheduled event programme via Schedules, Schedule Views, Schedule View Blocks, Venues, Rooms and Programmes
  • Labour – Manages event volunteers via Job Categories, Signups etc.
  • Signup – The simplest possible type of involvement, a free-of-cost sign up with some extra information. Manages Signups.
  • Commerce – Manages paid-for tickets via Orders, Products etc.
• Support Services
  • Badges – Manages Badges and admittance lists
  • External Auth – Synchronizes users and groups to an external service, namely IPA, for consumption by legacy applications
  • Mailings – Used to send mass e-mail Messages on grounds of an Involvement

Anatomy of a Service

Resources

A Service declares Resources which are persisted into a database.

Basic REST methods are provided for all Resources:

• GET /resource (list, search)
• GET /resource/:id (retrieve)
• POST /resource (create)
• PUT /resource/:id (update)
• DELETE /resource/:id (remove)

Resources are versioned. An attempt to PUT a stale Resource will fail.

Local and remote Resources offer an identical API to the programmer. Under the hood local Resources are persisted directly and remote Resources are käpisteld via REST.  Should all Resources be treated as Remote, and should we delegate talking to the database to the Nexus?

Core

Involvement – Connects a Person to an Entity. Further information about the nature of the Involvement is managed by an Involvement Service.

...