Enma, какого просмотра не предусмотрено? Причем тут просмотр.. create - показ формы создания ресурса, edit - показ формы редактирования. Это только показы и больше ничего. Для самого запроса создания store, апдейта update. это не вкусовщина, а необходимый набор роутов для работы с ресурсами в самом правильном его виде, с правильными put patch url а не как обычно лепят отсебятину.
snake2, делить юзеров на таблицы плохая идея. 10ки полей обычно можно вынести в сущности. Например, всякие адреса, контакты можно в полиморфные, тк много где нужны.
Василий Банников,
1. Загаженная файловая структура в которой ничего не видно.
2. И толку? Тебе все равно нужно смотреть изменения.
3. Есть сервис классы
Дмитрий, когда ты прописываешь в hidden твой базис нарушается. Ибо далеко не ВСЁ запрещено, а только то малое, что ты прописал. Сам себе противоречишь.
Дмитрий, азы доступов, как раз наоборот - должно быть запрещено всё, что не разрешено, а не запрещено только то, что ты прописал. Для этого нужно прописать то, что разрешено. Это логично, просто контролировать и так работают, например, политики в Ларавел. Пишешь $model->user_id === $user->id и все остальное мимо. С ресурсами также - добавил 3 нужных поля и потом пофиг какие ты со временем поля в модель добавил, забыл/не забыл и т.д. на фронт улетит только то, что тебе нужно.
Дмитрий, конфиденциальные поля в одном месте конфиденциальные, а в другом нет и придется продолжать костыль. К тому же нет смысла отдавать на фронт лишние данные, даже если поля не конфиденциальные. Проекты есть и с 4000 дублирующих запросов на одной странице и возможностью зарегить админа кому угодно. И ничего, живут. Автор новичок, который может не знать, что делает и лучше ему учиться сразу делать красиво и безопасно.
Дмитрий, кого где что не спасает нужно разбирать на конкретном примере. В данном примере (json ресурсы) нужно использовать Ларавел ресурсы ибо захочет притянуть к проектам user.profile и вывалит и в них все, что не надо. Не надо приучаться к костылям, когда ты используешь фреймворк и есть удобные инструменты.
Дмитрий, ресурсы не просто так придумали. Связи, набор полей для разных запросов к одной модели и т.д. Вдруг у него там в проектах конфиденциальные поля и он их тупо на фронт вывалит, как часто в Ларавел проектах бывает. Лучше сразу делать по нормальному.
lexstile, как Дмитрий + вызывать геттер в АПИ ресурсе, а ресурс в контроллере. Метод из модели убрать в контроллер если не повторяется или вынести в свой класс если повторяется. Подобных методов в модели быть не должно. Ну и называть методы контроллера правильно (см примеры в ресурсном контроллере), а лучше сразу генерить ресурсные роуты/контроллеры с помощью Ларавел ибо get по смыслу это и index может быть и show в апи контроллере.