Возврат новых данных после POST-запроса

avatar
Liviu Ganea
9 августа 2021 в 06:40
85
1
0

TL;DR: Как лучше всего обновить список пользователей в клиентском приложении после того, как запрос изменил список?

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

В настоящее время в моем приложении React я делаю запрос к API, чтобы добавить нового пользователя в качестве администратора или изменить имя существующего пользователя и т. д. Я выполняю запрос, отправляю некоторые данные (о новом пользователе или что должно быть изменено) и получаю новый список с пользователями, который я установил в состоянии компонента, который повторно отображает страницу с новыми данными.

В API-контроллере я получаю эти данные, выполняю некоторые проверки и, если все в порядке, создаю/обновляю пользователя, запрашиваю в БД список пользователей и возвращаю его клиенту. Все в том же методе контроллера.

Мой руководитель сказал мне, что это плохая идея, и что он должен убедиться, что метод контроллера должен делать только одну вещь (SOLID) и найти другой способ сделать это. Я хочу убедиться, что после любой операции, взаимодействующей с БД, страница обновляется с изменениями. Я проверил Получить запрос после рекомендации по отправке запроса? и не нашел там своего ответа.

Некоторые примеры кода:

// calling the user creation method
export const createUser = (user, onSucceed, onFail) => {
    axios.post("api/users/creation", {
            "firstName": user.firstName,
            "lastName": user.lastName,
            "email": user.email,
            "password": user.password,
            "roles": user.role
        })
        .then((response) => {
            // onSucceed simply performs a few minor
            // tasks for antd Table component and sets the state
            // with the users list
            onSucceed(response);
        })
        .catch((exception) => {
            // shows notification with the error and message of the error
            onFail(exception);
        })
}

Мой метод контроллера:

async public Task<IActionResult> CreateUser(CreateUserModel userToCreate)
{
      // some checks for incoming data and other logic

      // TODO: Best practice for updating list 

      // queries the DB and returns the latest list of users
      var userDbList = _userManager.Users.ToList();
      var userReturnList = userDbList.Select(async user => new GetUsersModel
      {
           Name = $"{user.FirstName} {user.LastName}",
           UserName = user.UserName,
           Email = user.Email,
           Roles = await _userManager.GetRolesAsync(user)
      });

      return Ok(new { Users = userReturnList, Message = AppResources.UserCreated });
}
Источник
Divyesh Kanzariya
9 августа 2021 в 06:46
1

для создания используйте POST, а когда вам нужно полностью заменить существующий ресурс, они могут использовать PUT. Когда они делают частичное обновление, они могут использовать PATCH.

bokibeg
9 августа 2021 в 10:58
0

Принципы SOLID применяются только там, где они имеют смысл и имеют явные преимущества. Выполняет ли ваш раундрип HTTP 1, 2 или 3 внутренних действия и/или то, что он возвращает, зависит от ваших потребностей потребителя, а не от соглашений и принципов кодирования. Представь, через 2 года твой код на проде и тебе звонит начальник инфры, он спрашивает тебя, почему ты всегда делаешь GET после POST около 5 000 000 раз в день? Позвольте мне сказать вам, что «Потому что SOLID» с ними не смоется :). Не оптимизируйте преждевременно, но и не вводите дополнительные штрафы только из-за стиля кода.

bokibeg
9 августа 2021 в 11:00
0

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

Ответы (1)

avatar
Ahmad
9 августа 2021 в 07:31
0

Есть два стандартных способа:

Оптимистичный способ:

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

Пессимистичный способ:

вы хотите убедиться, что изменения были сохранены в базе данных, а затем показать пользователю. поэтому вы должны просто получить данные после создания или обновления данных.