Restful API создает несколько зависимых ресурсов

#backend #rest

Вопрос:

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

Давайте определим 3 простых ресурса:

 class User {
   // some props
}

class Company {
   users: MongoId[]; // Referencing an array of User object
   logo: MongoId; // Referencing a File object 
}

class File {
   name: string;
   base64: string;
}
 

Теперь, если я хочу создать новую компанию, используя классическую POST /companies , и я отправлю в тело идентификаторы ранее созданных пользователей файл…

Но здесь я не знаю, что делать, если создание компании завершится неудачей по причине x (в основном ошибка проверки). Я ранее создал 2 сущности, которые никогда не будут использоваться, что мне с этим делать ? Есть ли способ в парадигме покоя избежать этого ?

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

Ответ №1:

Обычно это зависит от того, кто создал ресурсы, чтобы удалить их, если они им больше не нужны, и я думаю, что это был бы стандартный подход в RESTful API. Если это вызывает серьезную озабоченность, вы можете добавить методы, которые облегчат отслеживание объектов, которые не связаны с другими объектами.

В противном случае самым простым способом было бы включить их в организм, как вы говорите.

 {
    users: [{username: "gooby"}],
    logo: {name: "hello.jpg", base64: "something in base64"}
}
 

Затем вы можете вернуть созданный объект компании с заполненными идентификаторами, если вы все еще хотите сохранить их в качестве независимых ресурсов:

 {
    companyId: 15,
    users: [{username: "gooby", id: 74}],
    logo: {name: "hello.jpg", base64: "something in base64", id: 85}
}
 

После чего пользователь может быть извлечен с помощью, например GET /users/74 .

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

Вы можете создать какой-то ресурс транзакций, который будет содержать все ваши ресурсы в массиве, и удалить их, если один из них не будет создан, но это приведет к довольно абстрактному и неинтуитивному API.

Комментарии:

1. Итак, по вашему мнению, второй вариант не нарушает никаких спокойных «правил» ? Я не был уверен в этом