Я согласен с ответом, который дал ученик выше, однако я бы не рекомендовал его с точки зрения организации кода и тестируемости.
Глядя на код, я вижу, что вам нужно получить список пользователей, и поэтому вы должны вызывать пользовательский контроллер API с другого контроллера. Однако вы можете легко извлечь логику из сервиса или даже из черты.
если бы вы использовали черту, вы могли бы сделать что-то вроде следующего:
trait ApiUser {
public function getList()
{
// get the list for users from api
}
}
//Then you can simply use this trait any where you want,
class SomeController
{
// correct namespace for ApiUser trait
use ApiUser;
}
Еще один способ сделать это, который я люблю использовать снова и снова, в зависимости от сценария; это придерживаться принципа кодирования для интерфейса, а не для реализации. Это будет что-то вроде следующего.
interface ApiUserInterface
{
public function getList();
}
class ApiUser implements ApiUserInterface
{
public function getList()
{
// logic to get users from api
}
}
Убедитесь, что, когда приложению требуется интерфейс, оно знает, где найти его реализацию. Если вы используете Laravel, то вы можете зарегистрировать свой интерфейс в классе в AppServiceProvider
Как только это будет сделано, вы можете использовать эту услугу в любом месте в качестве контракта.
class OneController
{
protected $apiUserContract;
public function __construct(ApiUserInterface $apiUserContract)
{
$this->apiUserContract = $apiUserContract;
}
public function index()
{
// You can retrieve the list of the contract
$this->apiUserContract->getList();
}
}
// you could also just typehint the contact in method without requiring
// it in constructor and it will get resolved out of IOC i.e. container
class AnotherController
{
public function index(ApiUserInterface $apiUserContract)
{
// You can retrieve the list of the contract
$apiUserContract->getList();
}
}
Дайте мне знать, если вам нужны дальнейшие объяснения, и надеюсь, что это поможет