REST as Template Services
Company management consistently struggle with exposing internal products as REST services. There is a lack of balance between organizing internal products to be used in combination with other internal products (to create a new type of service) and REST principles. Understanding the difference between controllers and REST resources will eliminate confusion and misuse of fundamental REST principles.
Previously explained, REST is best used for static objects that Create, Retrieve, Update, and Delete (i.e., the HTTP equivalent POST, GET, PUT, and DELETE). If the service acts as a function, consider designing the service as a REST controller (see How to identify objects as REST Controllers or Resources). Otherwise, the service is data.
The ultimate REST architecture is a service structure that combines with other REST services to create a totally new service as depicted in the following diagram:
A Powerful REST Architecture that Focuses on Monetization
The platform is the application, or system exposed to external developers. Platforms are used individually or with other Platforms to create unique services.
The service template defines configurable attributes of a platform. The service template is used to create a service, which has commercial value to an enterprise or an independent developer.
The service variant is a configured version of a service template. The service variant is an item with the necessary configuration to provide value to a developer and supports necessary provisioning actions.
In summary, when creating a REST architecture remember one internal service can be used with another to create a completely new API. Try to stay abstract. Do not release a finished product as a REST service by pointing the URL to the product. When a finished product is used as a REST service, a developer has no options to consume the API. Separate data as resources and actions as controllers. Nouns vs verbs.