belamov / ypgo-gophermart Goto Github PK

https://github.com/go-chi/jwtauth

Сейчас используется глобальный мьютекс - поэтому мы начисляем баланс только не одновременно
Можно оптимизировать, если блокировать по айди пользователя, поскольку начисление денег двум разным пользователям не пересекается и может происходить параллельно
https://pkg.go.dev/golang.org/x/[email protected]/singleflight

Конфигурирование сервиса накопительной системы лояльности

Сервис должн поддерживать конфигурирование следующими методами:

• адрес и порт запуска сервиса: переменная окружения ОС RUN_ADDRESS или флаг -a
• адрес подключения к базе данных: переменная окружения ОС DATABASE_URI или флаг -d
• адрес системы расчёта начислений: переменная окружения ОС ACCRUAL_SYSTEM_ADDRESS или флаг -r

Запрос на списание средств

Хендлер: POST /api/user/balance/withdraw

Хендлер доступен только авторизованному пользователю. Номер заказа представляет собой гипотетический номер нового заказа пользователя в счет оплаты которого списываются баллы.

Примечание: для успешного списания достаточно успешной регистрации запроса, никаких внешних систем начисления не предусмотрено и не требуется реализовывать.

Формат запроса:

POST /api/user/balance/withdraw HTTP/1.1
Content-Type: application/json

{
	"order": "2377225624",
    "sum": 751
}

Здесь order — номер заказа, а sum — сумма баллов к списанию в счёт оплаты.

Возможные коды ответа:

• 200 — успешная обработка запроса;
• 401 — пользователь не авторизован;
• 402 — на счету недостаточно средств;
• 422 — неверный номер заказа;
• 500 — внутренняя ошибка сервера.

Получение информации о выводе средств

Хендлер: GET /api/user/withdrawals.

Хендлер доступен только авторизованному пользователю. Факты выводов в выдаче должны быть отсортированы по времени вывода от самых старых к самым новым. Формат даты — RFC3339.

Формат запроса:

GET /api/user/withdrawals HTTP/1.1
Content-Length: 0

Возможные коды ответа:

• 200 — успешная обработка запроса.

  Формат ответа:

  200 OK HTTP/1.1
  Content-Type: application/json
  ...
  
  [
      {
          "order": "2377225624",
          "sum": 500,
          "processed_at": "2020-12-09T16:09:57+03:00"
      }
  ]
  

• 204 - нет ни одного списания.

• 401 — пользователь не авторизован.

• 500 — внутренняя ошибка сервера.

Клиент должен сам себя тротлить - не выполнять больше установленного значения запросов к стороннему сервису в секунду
https://medium.com/mflow/rate-limiting-in-golang-http-client-a22fba15861a

Для валидации реализовать алгоритм луна. Не валидировать отрицательные номера заказа

Аутентификация пользователя

Хендлер: POST /api/user/login.

Аутентификация производится по паре логин/пароль.

Формат запроса:

POST /api/user/login HTTP/1.1
Content-Type: application/json
...

{
	"login": "<login>",
	"password": "<password>"
}

Возможные коды ответа:

• 200 — пользователь успешно аутентифицирован;
• 400 — неверный формат запроса;
• 401 — неверная пара логин/пароль;
• 500 — внутренняя ошибка сервера.

Регистрация информации о вознаграждении за товар

Хендлер: POST /api/goods.

Регистрация информации о вознаграждении за товар. Хендлер используется менеджерами для добавления механик вознаграждения за покупки.

Полученные системой расчёта начислений составы чеков проверяются на совпадение с зарегистрированными в данном хендлере вознаграждениями.

Механика должна иметь уникальный ключ поиска (поле match).

Формат запроса:

POST /api/goods HTTP/1.1
Content-Type: application/json

{
	"match": "Bork",
	"reward": 10,
	"reward_type": "%"
}

Поля объекта запроса:

• match — ключ поиска (проверяется на наличие в строке наименования товара), не может быть пустым;
• reward — размер вознаграждения;
• reward_type — тип вознаграждения:
  • % — процент от стоимости товара;
  • pt — точное количество баллов.

Возможные коды ответа:

• 200 — вознаграждение успешно зарегистрировано;
• 400 — неверный формат запроса;
• 409 — ключ поиска уже зарегистрирован;
• 500 — внутренняя ошибка сервера.

Регистрация пользователя

Хендлер: POST /api/user/register.

Регистрация производится по паре логин/пароль. Каждый логин должен быть уникальным.
После успешной регистрации должна происходить автоматическая аутентификация пользователя.

Формат запроса:

POST /api/user/register HTTP/1.1
Content-Type: application/json
...

{
	"login": "<login>",
	"password": "<password>"
}

Возможные коды ответа:

• 200 — пользователь успешно зарегистрирован и аутентифицирован;
• 400 — неверный формат запроса;
• 409 — логин уже занят;
• 500 — внутренняя ошибка сервера.

В хэндлере возвращать 402 при такой ошибке

Конфигурирование сервиса системы расчёта вознаграждений

Сервис должн поддерживать конфигурирование следующими методами:

• адрес и порт запуска сервиса: переменная окружения ОС RUN_ADDRESS или флаг -a
• адрес подключения к базе данных: переменная окружения ОС DATABASE_URI или флаг -d

Научить сервис регистрировать пользователя: создание модельки в бд с захешированным паролем
https://astaxie.gitbooks.io/build-web-application-with-golang/content/en/09.5.html

Получение текущего баланса пользователя

Хендлер: GET /api/user/balance.

Хендлер доступен только авторизованному пользователю. В ответе должны содержаться данные о текущей сумме баллов лояльности, а также сумме использованных за весь период регистрации баллов.

Формат запроса:

GET /api/user/balance HTTP/1.1
Content-Length: 0

Возможные коды ответа:

• 200 — успешная обработка запроса.

  Формат ответа:

  200 OK HTTP/1.1
  Content-Type: application/json
  ...
  
  {
  	"current": 500.5,
  	"withdrawn": 42
  }
  

• 401 — пользователь не авторизован.

• 500 — внутренняя ошибка сервера.

Регистрация нового совершённого заказа

Хендлер: POST /api/orders.

Регистрация нового совершённого заказа. Для начисления баллов состав заказа должен быть проверен на совпадения с зарегистрированными записями вознаграждений за товары. Начисляется сумма совпадений.

Принятый заказ не обязан браться в обработку непосредственно в момент получения запроса.

Формат запроса:

POST /api/orders HTTP/1.1
Content-Type: application/json

{
	"order": "<number>",
	"goods": [
		{
			"description": "Чайник Bork",
			"price": 7000
		},
		...
	]
}

Поля объекта запроса:

• order — номер заказа;
• goods — список купленых товаров:
  • description — наименование товара;
  • price — цена оплаченного товара.

Возможные коды ответа:

• 202 — заказ успешно принят в обработку;
• 400 — неверный формат запроса;
• 409 — заказ уже принят в обработку;
• 500 — внутренняя ошибка сервера.

Номер заказа должен быть уникальным в хранилище. Отделять два случая: если заказ был повторно загружен тем же пользователем и другим пользователем. Доработать хэндлер, чтобы отдавать корректный код ошибки в каждом случае

Обработка должна быть асихронной. Обрабатывать заказ при его добавлении.
У заказа может быть 4 статуса:

• NEW — заказ загружен в систему, но не попал в обработку;
• PROCESSING — вознаграждение за заказ рассчитывается;
• INVALID — система расчёта вознаграждений отказала в расчёте;
• PROCESSED — данные по заказу проверены и информация о расчёте успешно получена.

Загрузка номера заказа

Хендлер: POST /api/user/orders.

Хендлер доступен только аутентифицированным пользователям. Номером заказа является последовательность цифр произвольной длины.

Номер заказа может быть проверен на корректность ввода с помощью алгоритма Луна

Формат запроса:

POST /api/user/orders HTTP/1.1
Content-Type: text/plain
...

12345678903

Возможные коды ответа:

• 200 — номер заказа уже был загружен этим пользователем;
• 202 — новый номер заказа принят в обработку;
• 400 — неверный формат запроса;
• 401 — пользователь не аутентифицирован;
• 409 — номер заказа уже был загружен другим пользователем;
• 422 — неверный формат номера заказа;
• 500 — внутренняя ошибка сервера.

При старте приложения сервис должен начать обрабатывать все заказы со статусом NEW - это будут те заказы, которые завершились с ошибкой. см #35

Получение списка загруженных номеров заказов

Хендлер: GET /api/user/orders.

Хендлер доступен только авторизованному пользователю. Номера заказа в выдаче должны быть отсортированы по времени загрузки от самых старых к самым новым. Формат даты — RFC3339.

Доступные статусы обработки расчётов:

• NEW — заказ загружен в систему, но не попал в обработку;
• PROCESSING — вознаграждение за заказ рассчитывается;
• INVALID — система расчёта вознаграждений отказала в расчёте;
• PROCESSED — данные по заказу проверены и информация о расчёте успешно получена.

Формат запроса:

GET /api/user/orders HTTP/1.1
Content-Length: 0

Возможные коды ответа:

• 200 — успешная обработка запроса.

  Формат ответа:

  200 OK HTTP/1.1
  Content-Type: application/json
  ...
  
  [
  	{
          "number": "9278923470",
          "status": "PROCESSED",
          "accrual": 500,
          "uploaded_at": "2020-12-10T15:15:45+03:00"
      },
      {
          "number": "12345678903",
          "status": "PROCESSING",
          "uploaded_at": "2020-12-10T15:12:01+03:00"
      },
      {
          "number": "346436439",
          "status": "INVALID",
          "uploaded_at": "2020-12-09T16:09:53+03:00"
      }
  ]
  

• 204 — нет данных для ответа.

• 401 — пользователь не авторизован.

• 500 — внутренняя ошибка сервера.

Если в бд уже заведен пользователь с переданным логином, то сервис должен отдавать специальную ошибку
При такой ошибке хэндлер должен возвращать статус 409

https://github.com/rs/zerolog

Получение информации о расчёте начислений

Хендлер: GET /api/orders/{number}.

Получение информации о расчёте начислений баллов лояльности за совершённый заказ.

Номером заказа является последовательность цифр произвольной длины. Номер заказа может быть проверен на корректность ввода с помощью алгоритма Луна

Формат запроса:

GET /api/orders/{number} HTTP/1.1
Content-Length: 0

Возможные коды ответа:

• 200 — успешная обработка запроса.

  Формат ответа:

  200 OK HTTP/1.1
  Content-Type: application/json
  ...
  
  {
      "order": "<number>",
      "status": "PROCESSED",
      "accrual": 500
  }
  

  Поля объекта ответа:

  • order — номер заказа;

  • status — статус расчёта начисления:

    • REGISTERED — заказ зарегистрирован, но не начисление не рассчитано;
    • INVALID — заказ не принят к расчёту, и вознаграждение не будет начислено;
    • PROCESSING — расчёт начисления в процессе;
    • PROCESSED — расчёт начисления окончен;

  • accrual — рассчитанные баллы к начислению, при отсутствии начисления — поле отсутствует в ответе.

• 429 — превышено количество запросов к сервису.

  Формат ответа:

  429 Too Many Requests HTTP/1.1
  Content-Type: text/plain
  Retry-After: 60
  
  No more than N requests per minute allowed
  

• 500 — внутренняя ошибка сервера.

При завершении приложения все заказы, находящиеся в обработке должны возвращаться в статус NEW, все горутины, обрабатывающие заказы должны завершаться и перестать запрашивать инфу о начислениях
https://go101.org/article/channel-closing.html