Laravel: Объединить REST-контроллеры с обычными контроллерами и представлениями?
Я хочу создать новое приложение, и для этого я выбрал laravel. Так что я тоже новичок в Laravel.
Я хочу с самого начала интегрировать API для таких вещей, как аддоны браузера или мобильные приложения. Конечно, я не хочу делать это приложение только для API. Мне все еще понадобятся нормальные представления и контроллеры, которые справятся с этим. Теперь я немного озадачен правильной структурой. Он должен выводить данные в виде JSON, когда это запрос API, в противном случае в обычном представлении.
Каков был бы лучший способ достичь этого? Все учебные пособия основаны только на приложениях API, которые мне не помогают.
Это хорошая практика, чтобы сделать UserController.php и ApiUserController.php? Или UserController.php и структура подпапок, например API / v1.0 / UserController.php? Разве я не буду часто повторять вещи с такой структурой? Я имею в виду, что часто единственное, что меняется, это результат, не так ли?
Заранее спасибо!
Решение
Ваш API должен обслуживаться по маршрутам API, они могут быть в том же контроллере, что и другие пользовательские ресурсы, но на самом деле они не должны быть.
Мне нравится использовать ApiController со всеми функциями API в нем. В этом вы можете реализовать такие вещи, как «showUsers» и заставить его возвращать User :: all () или User :: paginate (50). Если вы напрямую вернете модель в Laravel, она будет выводиться как JSON по умолчанию, что довольно удобно.
Теперь для некоторого истинного совершенства API, я люблю использовать пакет API от dingo в сочетании с оберткой artdarek Laravel OAuth 2. Он предоставляет действительно высококачественный безопасный API с множеством функциональных возможностей, таких как ограничение скорости и области действия, и тому подобное.
Вы действительно не хотите использовать контроллеры RESTful для API, поскольку вам, вероятно, нужны конечные точки с разными именами. Мне нравится держать всех пользователей в api / users, но одиночных пользователей в user / USER, например. Это то, что я предпочитаю, мой API должен быть полностью настраиваемым и маршрутизируемым, по моему мнению.
Другие решения
Других решений пока нет …
detector