Использование моего собственного API Laravel

Я разрабатываю приложение Laravel 4, которое будет выполнять те же операции CRUD в моем наборе данных, доступные через API JSON REST и веб-интерфейс. Похоже, что для предотвращения нарушения принципа DRY мой пользовательский интерфейс должен использовать собственный API, перенаправляя все запросы из интерфейса пользователя обратно в API. Я не уверен, что об оптимальном подходе к этой работе. Предположительно, у меня были бы отдельные контроллеры пользовательского интерфейса и API и как-то маршрутизировать запросы. Или я должен вообще искать другой подход?

Благодарю.

Related of "Использование моего собственного API Laravel"

Я на самом деле разбираюсь в одной и той же идее, и это довольно аккуратно. С Laravel у вас есть возможность делать внутренние запросы (некоторые могут ссылаться на это как на HMVC, но я не буду). Вот основные сведения о внутреннем запросе.

$request = Request::create('/api/users/1', 'GET'); $response = Route::dispatch($request); 

$response теперь будет содержать возвращаемый ответ API. Как правило, этому будет возвращена кодированная строка JSON, которая отлично подходит для клиентов, но не настолько хороша для внутреннего запроса API. Вы должны будете расширить несколько вещей здесь, но в основном идея состоит в том, чтобы вернуть фактический объект обратно для внутреннего вызова, а для внешних запросов вернуть отформатированный ответ JSON. Вы можете использовать такие вещи, как $response->getOriginalContent() здесь для такого рода вещей.

То, что вы должны посмотреть, это создание своего рода внутреннего Dispatcher который позволяет отправлять запросы API и возвращать исходный объект. Диспетчер должен также обрабатывать неверные запросы или плохие ответы и выдавать исключения для соответствия.

Сама идея прочная. Но планирование API – это тяжелая работа. Я бы рекомендовал вам составить хороший список всех ожидаемых конечных точек и подготовить несколько версий API, а затем выбрать лучший.

ПРИМЕЧАНИЕ. Как указал vcardillo ниже, фильтры маршрутов не вызываются с помощью этих методов.

В настоящее время я делаю то же самое, и ответ Джейсона заставил меня идти в отличном направлении. Глядя на документацию Symfony \ Component \ HttpFoundation \ Request , я выяснил, как POST, а также все остальное, что мне нужно будет сделать. Предполагая, что вы используете форму, вот какой код может вам помочь:

ПОЛУЧИТЬ:

 $request = Request::create('/api/users/1', 'GET'); $response = Route::dispatch($request); 

ПОСЛЕ:

 $request = Request::create('/api/users/1', 'POST', Input::get()); $response = Route::dispatch($request); 

POST с cookies

 $request = Request::create('/api/users/1', 'POST', Input::get(), Cookie::get('name')); $response = Route::dispatch($request); 

POST с файлами

 $request = Request::create('/api/users/1', 'POST', Input::get(), null, Input::file('file')); $response = Route::dispatch($request); 

Надеюсь, это поможет кому-то другому. Если вы не используете форму или используете, но не используете фасад Input / Cookie Laravel, замените фасады Input / Cookie своим собственным контентом.

Тейлор Отуэлл предложил использовать app()->handle() а не Route::dispatch() чтобы получить чистый запрос.

Для Route::dispatch($request) я заметил, что если конечная точка вашего запроса, отличного от GET (параметры в теле запроса HTTP), использует экземпляр расширения с расширением \Illuminate\Http\Request или \Illuminate\Foundation\Http\FormRequest , состояние параметров, файлы cookie, файлы и т. д. из исходного HTTP-запроса. т.е. для метода действия контроллера вашего приложения.

Если имена параметров и тип почтового метода для вашего контроллера приложения и контроллера API одинаковы, вы не заметите разницу, так как исходные значения параметров передаются. Но когда вы вручную собираете третий параметр Request::create() , Route::dispatch() приведет к его игнорированию.

app()->handle() исправляет эту проблему контекста в жизненном цикле запроса Laravel.

Caveat: app()->handle() влияет на Illuminate\Support\Facades\Request , обновляя его с помощью этого нового экземпляра запроса. В качестве эффекта детонации вызовы типа Request::isXmlHttpRequest() или redirect()->back() вызванные после app()->handle() , вызовут непредсказуемое поведение. Я бы предложил отслеживать контекст вашего первоначального запроса и вместо этого использовать redirect()->to(route('...')) чтобы вы строго контролировали поток и состояние вашего приложения.

Учитывая все эти угловые случаи, лучше всего просто выполнить ручное завивание, используя HTTP-клиент Guzzle .

Если вы используете свой собственный API, используйте app()->handle() вместо Route::dispatch() как предложил Derek MacDonald.

app()->handle() создает новый запрос, в то время как Route::dispatch() запускает маршрут внутри стека, эффективно игнорируя параметры, которые являются частью отправляемого запроса.

Редактировать : Просто хедз-ап. Тейлор Отуэлл советует не использовать подзапросы, чтобы делать внутренние вызовы API, поскольку они препятствуют текущему маршруту . Guzzle этого вы можете использовать HTTP API-клиент, такой как Guzzle для вызова API.

Вы можете использовать пользователя Optimus API , API чист и прост, например, делая внутренний запрос:

 $response = app()->make('apiconsumer')->post('/oauth/token', $data); 

В его основе он использует Illuminate\Routing\Router и Illuminate\Http\Request для вызова

 // create the request $this->request->create($uri, $method, $data, [], [], $server, $content); // get the response $response = $this->router->prepareResponse($request, $this->app->handle($request)); 

Если вы ищете внутреннюю паспортную регистрацию api, вам необходимо добавить параметры к исходному запросу:

 protected function manualLogin(Request $request) { $email = $request->input('email'); $password = $request->input('password'); $request->request->add([ 'username' => $email, 'password' => $password, 'grant_type' => 'password', 'client_id' => $clientID, 'client_secret' => $clientSecret, 'scope' => '*']); $newRequest = Request::create('/oauth/token', 'post'); return Route::dispatch($newRequest)->getContent(); } 

Если вы ищете внутреннюю паспортную регистрацию api, вам необходимо добавить параметры к исходному запросу:

  protected function manualLogin(Request $request) { $email = $request->input('email'); $password = $request->input('password'); $request->request->add([ 'username' => $email, 'password' => $password, 'grant_type' => 'password', 'client_id' => $clientID, 'client_secret' => $clientSecret, 'scope' => '*']); $newRequest = Request::create('/oauth/token', 'post'); return Route::dispatch($newRequest)->getContent(); }