Adding persistence

The logical next step after reading sample in-memory data is to let the API user create its own data entities and store this data in a persistent manner, which means it will still be there when the application goes down and is restarted, which was admittedly a big limitation of our first version. With an agile approach, we could be even more conservative and start with a version that deals with in-memory data creation and modification, only then adding some persistence means. But it is a deliberate choice to carry out these two steps at the same time – because our data referential service will not work in the same way as lots of existing applications that store successive states of data: it will save modifications of data over time, and deduce states from this, still storing them in order to accelerate further querying of the data. The consequence is that the data schema will evolve, so it would be a waste of time to show the creation and modification of entities...