Какой тип данных лучше использовать для передачи расшифровки статуса на фронтенд: строку или перечисление (enum)?

Question

AstralArchitect

фронтенд , api

Какой тип данных лучше использовать для передачи расшифровки статуса на фронтенд: строку или перечисление (enum)?

Как наиболее эффективно передать сообщения об ошибках или информации о успешном завершении операции пользователю на русском языке через API, учитывая две возможные структуры данных? <br/><br/> <b>1. Должен ли бэкенд отправлять сообщение об ошибке или успешном завершении в виде строки?</b> <br/> Пример структуры ответа: <br/><pre><code>{
    id: int
    status: Status
    statusDescription: string
}</code></pre> <br/> Пример ответа: <br/><pre><code>{
    id: 210,
    status: "ERROR",
    statusDescription: "Товар не найден"
}</code></pre> <br/><br/> <b>2. Либо же правильнее передавать значение из перечисления (enum), а формирование текста сообщения оставить на фронтенде?</b> <br/> Пример структуры ответа: <br/><pre><code>{
    id: int
    status: Status
    statusDescription: StatusDescription
}

enum StatusDescription {
    PRODUCT_NOT_FOUND,
    CUSTOMER_NOT_FOUND
}</code></pre> <br/> Пример ответа: <br/><pre><code>{
    id: 210,
    status: "ERROR",
    statusDescription:  "PRODUCT_NOT_FOUND"
}</code></pre>

20 ноября 2024 г. 3:23

Ответы на вопрос 2

Похожие вопросы

Answer 1

При выборе между передачей сообщения об ошибке или успешном завершении операции в виде строки или значения из перечисления (enum) следует учитывать несколько факторов, включая простоту поддержки, локализацию и масштабируемость.

### 1. Передача сообщений в виде строки:

**Преимущества:**
- **Простота использования:** Получая сообщение об ошибке в виде строки, фронтенд тут же может его отобразить пользователю, без дополнительных преобразований.
- **Локализация:** Не нужно заботиться о локализации на уровне фронтенда: бэкенд отвечает за формирование сообщений на нужном языке.

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

Пример структуры ответа:
```json
{
    "id": 210,
    "status": "ERROR",
    "statusDescription": "Товар не найден"
}
```

### 2. Передача статусов с использованием enum:

**Преимущества:**
- **Строгость и согласованность:** Использование перечисления позволяет четко определить возможные состояния и соблюсти их.
- **Упрощенное обновление логики нагруженности:** Если в будущем потребуется изменить сообщение об ошибке, можно сделать это в одном месте — на фронте, без изменения API.
- **Локализация:** Позволяет сохранить только идентификаторы статусов на бэкенде, а тексты сообщений могут храниться во фронтенд-коде и адаптироваться под разные языки.

**Недостатки:**
- **Дополнительные преобразования:** Фронтенд теперь несет ответственность за отображение текста в зависимости от статуса, что требует дополнительного кода и может увеличить сложность.
- **Больше потенциальных ошибок:** Если текст в фронтенде не будет обновлен при добавлении новых статусов, это может привести к неотображению сообщений или неправильной интерпретации.

Пример структуры ответа:
```json
{
    "id": 210,
    "status": "ERROR",
    "statusDescription": "PRODUCT_NOT_FOUND"
}
```
### Резюме

**Рекомендованный подход:**
- Если основной язык вашего фронтенда — это русский, и локализация является важной частью вашего проекта, лучше использовать первый вариант - передавать сообщения об ошибках в виде строк. Это улучшит UX (опыт пользователя) и упростит локализацию.
- Если же ваше приложение многоязычное и предполагается частое изменение сообщений, стоит рассмотреть второй подход с использованием enum и разработать систему локализации на фронтенде.

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

Answer 2

Я за первый вариант