Should static and historical data be split in the API? To what extend?

Question

The project is a read-only interface for a company database.

In the database, there is some 'static' data about departments, in a Departments table. The value of these fields don't change with time (eg. DepartmentID, DepartmentName, DepartmentDescription, HistoryTableName, etc.).

There is also some timestamped data. The historical data for each department is stored in a dedicated table (named HistoryTableName, with fields such as timestamp, numberOfEmployees, Energy Consumption, ...). As you can guess, the layout of the data is not something that can be changed is this scope.

The point of the interface is to be able to access the data for all departments, at any time.

I have the 'static' part figured out: there is a company controller, which returns an object with a departments property, with their IDs, descriptions, etc.

I am however confused about how to handle the historical data:

• Should it be a part of the 'static' data? I would alter the department class with properties for the historical data. (And therefore, I would return the entire configuration every time new data is requested).

• Shoud I create a parallel flow (new controller companyHistory, new class, etc. which returns only the ID of the departments and their history, and the binding is done in the UI?)

• ...

I have little doubt that this has been studied before, and that there is a well-known pattern to handle such cases, but I have not been able to find any reference to it.

Could you point me to such a pattern?

Answer 1

As a first step, I'd question the staticness of department information. Truly unchanging organizational structures probably don't exist in companies that live for some time. Regarding your actual question, I don't offhand know of a specific pattern. The most useful solution might be an API that takes an optional timestamp parameter to show data (and possibly organizational structure) for that point in time, or current data if the parameter isn't given. Don't let the details of which part of the data is static creep into the client code, it makes things complicated and brittle.

Answer 2

If your API is customer-facing, its design should be driven by product requirements, not the data model. Your particular requirements might not call for access to historical data at all (how useful would it be to know the history of a department's name?)

If it were to be exposed, I would imagine that the current department records would be needed much, much more than the historical ones, so you'd probably want to keep those lightweight and not burden them with carrying around their history every time a department is retrieved.