Валидация данных на конечных точках api ? Какого подхода придерживаетесь вы, ребята?

Чтобы обеспечить контекст для моего вопроса, рассмотрим следующий пример. У нас есть три таблицы (они вымышленные)

animal -> [id, name]
animal_breed -> [id, name, animal, userId]
animal_registration_table -> [id, userId, breedId]

Теперь я видел два типа разработчиков,

  1. One who does not validate if the breedId being inserted actually belongs to the user. They just enter the data to db directly assuming that the app or frontend will send them valid data.
  2. One who first checks if the breedId belongs to userId by checking from the animal_breed table

Теперь я больше склоняюсь к подходу 2. Но я хочу знать, какой подход является хорошим, подход 2 требует дополнительного запроса или проверки, или есть лучший способ сделать это, имея ограничения в БД, и если да, то не могли бы вы мне помочь, направив меня на то, какие ограничения я должен иметь или любую другую лучшую альтернативу, так как я не чувствую, что пункт 1 является хорошим способом пойти. (p.s. я не очень хорошо разбираюсь в db, поэтому мне нужна помощь и руководство)

Если есть указанный пользователь, который "вставляет" данные, то должна быть проверка, является ли этот пользователь реальным пользователем. У front-end нет и не должно быть такой возможности выбора.

Теперь о вашем втором вопросе, Если userId логически является внешним ключом, то вы должны установить соответствующее ограничение с правилами on delete и on update и все такое. В принципе, вы не хотите программно делать то, что должно быть правилами базы данных.

Не знаю, ответил ли я на ваш вопрос или нет, но это хорошая тема для разговора.

Вернуться на верх