A model of a business

RESTful Business models seem to proceed presently as follows:

/business/address/street/street_number
/business/contact/email
/business/staff/executive/manager

and so forth. Nouns are nice as they relate to tangibles, that in turn have attributes, actions resulting in changes in their state.

This subject-noun centralisation appears to make sense but is that Resource Orientated? Probably not, unless you see a business as a container of raw materials. It enforces hierachy in development. This is our business module. This is our contacts module. And so forth. Objects are then "business", "user", "customer", "inventory", "cash", etc.

Seems right. Which means it is probably best deconstructed.



An earlier approach was to use gerunds to name actions:

/contact[ing]/customers
/sell[ing]/products

but then software to "contact" has to interface with diffent data types, each one differently. It makes more sense to define a business as a thing that can contact, and to define other things that can contact similiarly. The OO concept of extensibility addresses this linguistically:

where the path:
/entity/contact/email

may define
/business/contact/email
and
/staff/contact/email

by making entity a parent class to business and staff. But why include the path in the URI? If we consider each element as a semantic pair:

entity/business contact/email

then we are constructing our URI to include implied parent classes.

Our objects define:
entity as a parent of business
entity contact method when its a business
business contact method is inherently the entity contact method

the uri may say:
/business/contact/email
or
/entity/contact (which type of contact may be defined by the entity type)

therefore:
subject nouns require a superclass (categorisation) to define generic methods.
Generic actions imply a switch/case decision tree.