если он пытается создать запись, которая уже существует по двум полям?
В сервисном слое находим дубликат, бросаем исключение, а вот какое исключение должно быть - вопрос? Можно бросать 403 код и какой-то текст в духе <resource> already exists by field1 and field2, но такое себе
RESTful API only.
Через полгода устроил тотальный рефакторинг крупного проекта, решил поставить под сомнение такую простую вещь
Кастомные коды сделай
я бы свалил бы это в валидацию. 422 обычный и перечисление полей, которые не уникальны
1 - такая проверка у нас была в сервисе 2 - попробовал сделать в форм реквесте через валидацию, но мне совсем не нравится визуально эта портянка с Rule::unique Думаю, что из сервиса не стоит убирать проверку, потому что могут быть вызову из сидеров, консольных команд и тинкера, а валидация реквеста слишком высоко. Вопрос меняется: можно ли искусственно вызвать ValidationFailed, чтобы он указывал поле errors корректно, без костылей?
я думал речь про контроллер, а не сервис ) контроллер нет смысла вызывать из сидера или тинкера, так что в моём случае правила в реквесте — самое оно, тем более что твой Rule::unique можно обернуть в своё правило аля NeedUniqueField(['name', 'url']), как пример. про ValidationFailed и костыли непонятно, что значит корректно? добавить в валидатор свою ошибку?
та не контроллер вызывать же из сидера, а метод create в сервисе. Если перенести проверку в реквест, то логично, что из сервиса её лучше убрать для оптимизации, но тогда сидер или кто-то с тинкера может вызвать метод в сервисе, в котором не будет проверки - случится ошибка метод в сервисе теряет защиту. Я ищу способ оставить защиту в сервисе, но чтобы она бросала правильное исключение, которое даст 422 код
сделай троу ValidationException
Обсуждают сегодня