Create a Web API that will provide persistence to your JavaScript application (from task 5) using the latest .NET Framework (not .NET Core).

• Web API will (eventually) provide CRUD operations for items in your JS front-end
• Database provider might change at any time – has to be isolated in a single assembly
• Controllers have only and single responsibility – they react to user calls
• Dependency injection is a must (since you favor TDD, right)
• It is a simple application, so some simplifications are allowed (some are not): (OK) having a single assembly for all contracts and (single) DTO is perfectly OK (OK) dependency injection framework is referenced in all assemblies (BAD) having a public implementation of a contract is NOT OK → their implementation must be internal (BAD) having single assembly is NOT OK → (Web) API, (intra-assembly) contracts and database assemblies should emerge by now

• be as async as possible in controllers and services and repositories
• use Mongo DB as NoSQL storage provider. mLab is at your service (and for free) – single assembly reference expected
• use Unity as Dependency Injection container – all contract-implementing assemblies and API assembly reference expected
• use NUnit as test automation framework and NSubstitute as mocking framework – only test assemblies reference expected
• do not use AutoMapper as this is not necessary for API of this size, however, get to know it at least theoretically

• Use newest (RC is permissible) version of Visual Studio – check out the link to ensure you are set-up correctly and leverage your R# license.
• Use Postman to tune (and debug) API calls

• Preferably work in pairs (strong preference)

• kentico-onboarding-cs sounds like a good name for the repository of yours (it is a terrible name for a solution, though ;-))
• Use this file as README of your repository
• Give write access to your peer and possible reviewers
• Commit correct .gitignore
• Use GitFlow workflow
• Commit to a feature branch ( _{features/task-0 in this case)}
• There will be no upstream repository in this case

• Set-up continuous integration in the same way as in your JS repository (look at the CI part of JS task 0)

• Be careful about difference between Name and Solution name (the name should have .Api suffix)
• Use your default Git repository folder as Location
• Do not forget to Create directory for solution

• Check Add folders and core references for Web API
• Add unit tests, but do NOT check Host in the cloud

• Remove any empty classes, clean up the solution to contain only as much *.cs files as necessary
• Push your solution to your origin repository
• Create a pull-request to your develop branch

• motivation on constraint asserts (already familiart jest tests)

• All following actions can be "implemented" in the controller (for now)
• All controller actions are covered by tests (preferably use TDD)
• Provide list of (random static) items
• Add a new item
• Display item with given ID (whatever ID one provides, a predefined static item will be served)
• Delete item with given ID (whether it exists or not, it will act like it did)
• Change item with given ID (whether it exists or not, it will act like it did)

• Read a bit about versioning, its motivation, and differences of individual approaches
• Apply at least URL versioning in your dummy controller

(!) Important

• When you finish this task and your peer is not available, work on task Connect JS to CS from now on.
• Everybody needs to develop the functionality of Connect JS to CS on their own (and to their own JS onboarding repository) {panel}

• One might encounter problems with obtaining an instance of HttpRequestMessage outside API controller
• Repository itself and routing does not have to be covered by tests

• you will provide yourself with a database URL and username and password later in this task, let's looks on web application secrets topic and prepare our ground for them properly.
• Understand why a connection string must not be in code directly and should not be a part of database layer
• Make sure your connection string (or any other sensitive/instance-specific/secret information) is not checked-in in your public GitHub repository
• Store your secrets in web.config file of your presentation layer
• Sanitize your web.config based on this article
• Do not forget your connection string is a dependency

• Use mLab to create a sandbox NoSQL database
• Select the Azure cloud provider with the location in North Europe
• While replacing dummy repository's logic completely, implement only unconditional obtainment_ and _addition in API controller

• Make sure your controller's actions have a single responsibility and act on a single (highest) level of abstraction.
• Extend your model with two properties each representing date and time of model's creation_ and its _last update/change (these values will be sent through API to clients, however, it will not be consumed by your JS front-end in any way)
• Make sure (API) user input is sanitized (at least somewhat) properly
• If you have no service layer so far, there is something wrong – do not forget you write a simplified version of (somewhat large) multitier application with separated presentation

• ask <petrs2> to share Academy subscription with you
• prefix all your resources with your login (including resource group)
• be careful not create a resource that consumes money - let's start low and watch our expenses before first customers pay
• add Application Insights Telemetry
  • do not use Visual Studio to create any resources, always use Azure portal
• be extra careful not create a resource that consumes money
• configure resource group and create/use (free) service plan in North Europe

• extend CI set-up of your CS repository so each push to the master branch triggers release
• alternatively set-up deployment options of the service plan for your CS repository on the Azure portal so each push to the master branch triggers release