The idea is to have an in-memory version of the Web API available on Azure for testing different frontend solutions. Switching between a fake and real service implementation should be done via the application configuration.

• Add tests for verifying that /orders are sorted so that oldest come first
• Add tests for verifying that /resolvedorders are sorted so that newest come first
• Add test for orders/count
• Name or Order type string with length over 50 characters
• Adding order with same name/orderType should return BadRequest

Incorrect input should be handled via HTTP status codes
This applies both to obviously unsupported input (such as non-existent OrderType), as well as logically inconsequential requests (such as adding another order of the same type for the same user).
The functionality has been implemented directly in controller methods. Instead, an ActionFilter should be used for model validation and an ExceptionFilter should be used to map exception to error codes (rather than InternalServerError).

Apparently a blend of VS for Mac, VS for Windows and VS Code introduced some indentation issues.

NOTE: Strictly speaking this is overkill, the point of this application is rapid development (porting from node.js) and getting up and running in production. However, this is a good practice and is not extremely difficult to implement either.

So the service calls are to be async and should make use of EntityFramework async database calls.

This API is to be used by multiple test frontends from different servers, so CORS should be enabled API-wide

Exception handling scoped out from #5.
Considering to use middleware as in https://stackoverflow.com/questions/38630076/asp-net-core-web-api-exception-handling

Swashbuckle Swagger is an option worth looking into

The current implementation is fully functional in-memory, which is applicable for testing a frontend implementation. This should be replaced with actual database calls.

An SQL database should be created from the existing entities. Entity Framework Code First and Migrations to be used for database version handling

The Id is currently expected in the body of the request - should be moved to the URL for resolve/unresolve endpoints.

The following scenarios should be tested

Normal cases

• Adding an order and checking whether it's in the list of orders
• Resolving an order and checking that it's not in the list of orders but in the list of resolved orders
• Unresolving and order and checking that it's in the list of orders and not in the list of resolved orders
• Adding several orders and checking the number of orders

Error cases

• Calling add with an invalid model and verifying that Bad Request status code is returned
• Calling resolve and unresolve with invalid data and verifying that Bad Request status code is returned
• Calling resolve and unresolve with an unexisting order id and verifying that NotFound status code is returned

The users should only see the Name, OrderType and Date in the list
The admin needs the Ids for resolving/unresolving

This would require splitting the viewmodel classes into two - either by complicating the design via inheritance, or code repetition