ДОКЛАДНО ПРО ПРОЄКТ
Insurance Management API
Бізнес-правила й передбачуваний запис даних у власному API на .NET.
Завдання
Керувати клієнтами й життєвим циклом полісів, обробляючи повторні запити та конфліктні зміни.
Моя роль
У цьому власному проєкті я реалізувала backend, бізнес-правила й тести API.
Рішення
API на .NET 8 для керування клієнтами та життєвим циклом полісів автострахування, медичного страхування й страхування життя. В основі — бізнес-правила, передбачувані помилки та надійний запис даних.
Переглянути в дії
API керування
страхуванням
API на .NET 8 для керування клієнтами та життєвим циклом полісів автострахування, медичного страхування й страхування життя. В основі — бізнес-правила, передбачувані помилки та надійний запис даних.
Власний проєкт · Реалізація серверної частини, бізнес-правил і тестів API.
Спробувати інтерактивний приклад Переглянути репозиторійПовторний запит повертає той самий поліс. Конфліктні зміни позначаються, а дії з полісами можна відстежити.
Технічні подробиці
- 01APIВалідація · автентифікація · HTTP
- 02Домен і сервісиПравила полісів · життєвий цикл · ідемпотентність
- 03Збереження данихEF Core · інваріанти SQL · події аудиту
409Застарілі зміни та конфліктні запити повертають явні помилки.
Технічні рішення
Безпечні повторні запити
Операції випуску та скасування приймають ключ ідемпотентності. Однакові ключ і дані повертають початковий результат; змінені дані спричиняють конфлікт.
Правила на двох рівнях
Клієнт може мати лише один активний поліс автострахування. Це правило забезпечують перевірки сервісу та фільтрований унікальний індекс SQL.
Одночасні зміни
Токен версії рядка виявляє застарілі оновлення поліса й повертає конфлікт замість непомітного перезапису чужих змін.
Відстежуваний життєвий цикл
Випуск, оновлення та скасування полісів створюють події аудиту. Скасування зберігає запис, а скасовані поліси не можна змінювати.
Тести та контракти
Тести кінцевих точок xUnit перевіряють конфліктні ключі ідемпотентності, повторне повернення результату, валідацію, дозволи JWT та обмеження частоти запитів.
Переглянути код безпечного повторного запиту
Перед створенням ще одного поліса сервіс шукає наявну операцію та ключ. Він перевіряє відбиток даних запиту й повертає початкову сутність.
var existingIdempotency = await GetIdempotencyAsync(operation, idempotencyKey, cancellationToken);
if (existingIdempotency is not null)
{
// Same operation+key should return the original result unless payload changed.
ValidateFingerprint(existingIdempotency, idempotencyFingerprint);
return await GetByIdAsync(existingIdempotency.ResponseEntityId, cancellationToken);
}Фрагмент PolicyService.cs. Повний сервіс також обробляє конфліктні дані та одночасні вставки.
НЕВЕЛИКЕ ТЕХНІЧНЕ ЗАВДАННЯ
Ви двічі натискаєте «Зберегти». Що має статися?
Перший запит виконано, але відповідь загубилася. Ви повторюєте запит із тим самим ключем і тими самими даними.
Оберіть відповідь, а потім подивіться, як це працює.
Ілюстративна симуляція з тестовими даними. Без запитів до реального API.
Переглянути приклад повторного запиту
ІНТЕРАКТИВНИЙ ТЕХНІЧНИЙ ПРИКЛАД
Повторюйте безпечно.
Уникайте дублікатів полісів.
Якщо відповідь загубилася, клієнт може повторити той самий запит. Цей приклад повертає наявний поліс замість створення дубліката.
Ілюстративна симуляція правила ідемпотентності проєкту. Використовує тестові дані; без запитів до реального API.
Простежте шлях запиту
Створіть поліс, повторіть запит або змініть премію, щоб простежити результат.
Створено полісів 0
POST /api/customers/{id}/policies{
"type": "Health",
"premium": 100
}
Надішліть перший запит, щоб створити тестовий поліс.
Однаковий повторний запит має повернути початковий поліс.
Підтвердження та обмеження
Інтерактивний приклад — симуляція в браузері. Він не звертається до опублікованого API; повний запуск із SQL Server у цій демонстрації портфоліо не перевірено.