Не бойтесь разветвлять логику приложения в библиотечных классах. Вам не нужно вписываться в структуру папок Laravel.
Фактически, добавление в свою группу классов с именами может иметь большое преимущество. Вы можете увидеть некоторые настройки на creating your own application library here.
После того, как вы создали эту настройку, вы можете создать класс, задачей которого является выбор возвращаемого типа содержимого. Это может быть основано на заголовке Accept
, параметре URL или том, что вы определяете (это зависит от вас, создателя API).
Возможно, этот класс возьмет заголовок Accept
и нормализует его к чему-то вроде «json», «xml» и «html».
Класс запроса имеет somemethods, чтобы помочь вам, если вы сделаете это через заголовок Accept
.
Так, в псевдокоде (! Синтаксических ошибок, чтобы следовать), контроллер может сделать что-то вроде этого:
/* GET /api/users */
public function index()
{
// Might return "json" or "xml" or "html"
$contentType = \My\ContentType\Class->getContentType();
$users = User::all();
// Not shown here is logic to set `content-type` header in the returned response (json vs xml vs html)
// Perhaps a method to go into your implementation of \My\ContentType\Class
return View::make('users.'.$contentType)->with(array('users' => $users));
}
Это просто идея о том, что вы могли бы сделать. Ключевым моментом является заставить себя работать в библиотеке, в которую вы можете включить бизнес-логику, чтобы вы начали с идеи о том, как выполнить добавление бизнес-логики для вашего приложения.
Надеюсь, что это поможет.
Спасибо @fideloper, это здорово! Я разрабатываю веб-приложение, которое потребляет мой собственный API, и API, и логика приложения находятся в одном проекте. Как вы думаете, лучше ли отделить часть API от своих контроллеров в библиотеке или в пакете? – ramdemon
Предупреждение: вы должны дать ** мнение **: вы МОЖЕТЕ их разделить, но нужно ли вам это или нет, зависит от вашего варианта использования. Если вы разработчик, возможно, не отделите их. Если есть команда, разделение их может иметь смысл. Пойдите с тем, что облегчает жизнь разработчиков. Разделение связано с ремонтопригодностью (как с точки зрения изменения кода в будущем, так и для работы в команде) – fideloper