Василий Банников

Если на js можно использовать sessionStorage, но говорят так делать не правильно.

Кто говорит? И в какой ситуации не правильно? Если хранить только клиентские данные, типа корзины, то можно и в local/session storage

Раз так, тогда как отслеживать их, постоянно отправлять гет запрос?

Когда делаешь запрос к серверу, в запрос кладётся некоторый идентификатор, по которому можно отличить одного клиента от другого. Тот самый session id. По нему уже можно из бд вытащить всякие сохранённые данные.

То есть получается, что бы взаимодействовать с сессией нужно постоянно использовать ajax, как по мне sessionStorage использовать куда дешевле...

Если в вашей ситуации использовать session storage безопасно, то используйте.

делай запрос https://localhost:5000/Home

Нужно создать DesignTimeContextFactory https://go.microsoft.com/fwlink/?linkid=851728

IOptions можно создать при помощи
IOptions<A> options = Options.Create(new A());
Options.Create

С чего начать учить Unit тестирование?

С покрывания тестами простых модулей (которые не зависит от других модулей), которые не имеют побочных-эффектов (не лезут на диск или в сеть, не спрашивают ничего у пользователя).
Модулем может быть метод или класс.

Можно ещё почитать книжку

Видел что существует много их, типу Moq, XUnit и тд.

Это инструменты для решения разных задач.
Moq - для создания моковых объектов
XUnit - непосредственно фреймворк для описания и запуска тестов.

1. В DbContext можно включить логирование всех SQL-запросов
2. Чтобы посмотреть данные в БД - используйте SSMS

Емнип, при использовании convention-based маршрутизации, префис Get у имени метода отбрасывается.
Тоесть путь должен получиться такой:
http://localhost:5000/api/Rtb/Param?ids=1&ids=2

P.S. Если удалить первое действие, то все выполняется как надо

Видимо коллизия, тк у вас они оба отмечены HttpGet - значит оба будут на одном пути. А FromQuery параметры опциональны - вот он и не может выбрать один из них (о чём написано в логе, скорее всего)

Уберите первое действие и оставьте только вариант с параметром

А если в коде контроллера нет вызова асинхронных методов, будет ли какая-то разница?

Если асинхронных вызовов нет, то нет смысла делать метод контроллера асинхронным.

Или может быть имеет смысл этот код без асинхронных вызовов обернуть в таск и авейтить его, сделав метод контроллера асинхронным?

Нет. Перед и после контроллера есть ещё куча middleware и Action / Result фильтров, которые и так асинхронные, так что вы и так получите все преимущества асинхронного IO при работе с HTTP

Читайте ASP.NET Core Performance Best Practices
Самое главное:

Do not:

• Block asynchronous execution by calling Task.Wait or Task.Result.
  
• Acquire locks in common code paths. ASP.NET Core apps are most performant when architected to run code in parallel.
  
• Call Task.Run and immediately await it. ASP.NET Core already runs app code on normal Thread Pool threads, so calling Task.Run only results in extra unnecessary Thread Pool scheduling. Even if the scheduled code would block a thread, Task.Run does not prevent that.
  

Да. Есть sink для записи json, вместо голого текста.
UPD: не sink, а formatter.
https://github.com/serilog/serilog-formatting-compact

1. Любое исключание, которое вы хотите кинуть должно наследоваться от System.Exception
2. CustomerException выглядит странно. Зачем там вообще метод "DisplayException"?