Using my own Laravel API

I am developing a Laravel 4 application that will perform the same CRUD operations in my dataset, accessible through the JSON REST API and the web interface. It seems that to prevent a violation of the DRY principle, my user interface should use its own API, redirecting all requests from the user interface back to the API. I am not sure about the optimal approach to this work. Presumably, I would have separate UI and API controllers and somehow route the requests. Or should I even look for a different approach?

Thank.

+45
rest api php laravel laravel-4
May 13 '13 at 11:12
source share
7 answers

I am really doing the same thing, and it's pretty neat. With Laravel, you have the ability to make internal requests (some may refer to this as HMVC, but I will not). Here is the basics of internal query.

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

$response will now contain the returned API response. Typically, this will return a JSON encoded string that is great for clients, but not so good for an internal API request. You will need to expand a few things here, but basically the idea is to return the actual object back for an internal call, and for external requests, return a formatted JSON response. You can use things like $response->getOriginalContent() here for this kind of thing.

What you should do is build some kind of internal Dispatcher that allows you to send API requests and return the original object. The dispatcher should also handle invalid requests or bad responses and throw exceptions to match.

The idea itself is solid. But planning an API is hard work. I would recommend you write a good list of all expected endpoints and prepare several versions of the API, and then choose the best one.

+37
May 14 '13 at
source share

NOTE. As vcardillo pointed out below, route filters are not called using these methods.

I am doing the same thing now, and Jason replied that I was going in a different direction. Looking at the Symfony \ Component \ HttpFoundation \ Request documentation, I figured out how to POST, as well as everything else, that I will need to do. Assuming you are using a form, here is some code that might help you:

Get

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

POST:

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

Cookie post

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

POST with files

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

Hope this helps someone else. If you are not using a form or using but not using the Laravel Input / Cookie facade, replace the Input / Cookie facades with your content.

+20
Mar 18 '14 at 23:36
source share

Taylor Otwell suggested using app()->handle() instead of Route::dispatch() to achieve a clean request.

In Route::dispatch($request) I noticed that if the endpoint of your non-GET request (parameters in the body of the HTTP request) uses the extension added to the \Illuminate\Http\Request or \Illuminate\Foundation\Http\FormRequest , with extension, parameter status, cookies, files, etc .. from the original HTTP request. that is, for your application controller action method.

If the parameter names and the type of the mail method are the same for your application controller and API controller, you will not notice the difference, since the original parameter values ​​are transmitted. But when you manually collect the 3rd parameter Request::create() , Route::dispatch() will ignore it.

app()->handle() fixes this context issue in the Laravel request life cycle.

Caveat: app()->handle() affects Illuminate\Support\Facades\Request , updating it with this new instance of the request. As a detonation effect, calls like Request::isXmlHttpRequest() or redirect()->back() , called after app()->handle() , will cause unpredictable behavior. I would suggest tracking the context of your original request and using redirect()->to(route('...')) instead, so that you strictly control the flow and state of your application.

Given all these corner cases, it might be best to do a manual curl using the Guzzle HTTP client .

+8
Dec 01 '15 at 21:57
source share

If you use your own API, use app()->handle() instead of Route::dispatch() , as suggested by Derek MacDonald.

app()->handle() creates a new request, and Route::dispatch() starts the route inside the stack, effectively ignoring the parameters that are part of the sent request.

Edit : just heads-up. Taylor Otwell advises against using subqueries to create internal API calls, as they exchange the current route . You can use the HTTP API client, such as Guzzle , to invoke API calls.

+1
Jun 30 '17 at 3:56 on
source share

You can use the Optimus API user , the API is clean and simple, the example makes an internal request:

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

In it, the kernel uses Illuminate\Routing\Router and Illuminate\Http\Request to make a call

 // create the request $this->request->create($uri, $method, $data, [], [], $server, $content); // get the response $response = $this->router->prepareResponse($request, $this->app->handle($request)); 
0
May 26 '17 at 18:55
source share

If you are looking for internal passport logic api, you need to add parameters to the original request:

 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(); } 
0
Oct 17 '17 at 8:07 on
source share

If you are looking for internal passport logic api, you need to add parameters to the original request:

  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(); } 
0
Oct 17 '17 at 8:59 on
source share



All Articles