Splitting the original project into Lavinia-api and Lavinia-client likely had the side-effect of XmlDocument.xml not being configured properly. The original project has working comments, whereas the split project does not.

Description

To ease onboarding and make sure code reviews only focus on what matters, it is important to have a common standard of contribution (and reviews), conventions relevant for the repository in question.

Right now we are using an InMemory database; this is less than ideal as the database has to be re-populated every single time it restarts, and should we want to have some actual "history" of the data (ie, fixes, etc) then InMemory is less than ideal.

I suggest we use PostgreSQL as a database, but other options are also available (PostgreSQL is known to work well on both Windows and Linux, but I am unsure about how well it integrates with say, Azure).

It would have made more sense to create a new Context, perhaps NorwayContext as all the data inserted here is Norway specific.

Originally posted by @simendag in #11

This would allow us to only have public get, and remove the existing setters.

Add the models of the data structures described here:
https://docs.google.com/drawings/d/1TtV8-navSE9dWlVHq1JItb7TIUE19sesAFusJfCBpfA

Gather missing data for CountyData.csv.

This includes Area before 1957 and the Population before 2001.

The API should have a way to return a dictionary of party code - party names for all parties in all elections.

I dislike the usage of "default values" in the constructor, as it messes up Swagger's documentation and gives an indication to the user that all the parameters are necessary. I also think the defaults should be set in constants since they are re-used.

        public IActionResult GetVotes(int year?, string? partyCode, string? district)

Originally posted by @simendag in #11

This is found under app.UseSwaggerUI, right now it just says SwaggerUI, which less informative than desired.

There has been little to no testing on the API in regards to Linux, and it could very well be that our hosting solution ends up being there, so it should be tested that this is a viable possibility.

Currently we would have to compute the total number of votes on the front-end.
This value never changes and as such should never be computed.

Right now a consumer of the API has to "guess" the election years available. There is no reason not to have a database-entry for which election years are currently accessible, or even an endpoint for that matter.

There have been problems with development as some kind of scan/Denial of Service attack is executed at 12 hour intervals. In response we need to implement rate limiting to slow down the consumption.

Initially something like 1-2 requests per minute per endpoint seems reasonable.

ModelDB is perhaps the least informative database name of all time, and we can do better.

The new API should also support returning predetermined district seat numbers for elections before 2005, where these were not calculated based on population and area.
It should be handled in a way so that you always return values for both area factor and predetermined seat numbers. But in the case where the seat numbers are calculated, the predetermined seats should be listed as 0. And when the seat numbers are predetermined area factor should be a big negative number, preferably -inf if possible, otherwise -999. This makes it easy to check for and still allows for plausible but unlikely situations where the area factor might actually be 0.