How Follow the Don't Repeat Yourself Principle When Consuming My Own Laravel API

How Follow the Don't Repeat Yourself Principle When Consuming My Own Laravel API?

I'm actually tinkering with the same idea and it's pretty neat. With Laravel you do have the ability to make internal requests (some might refer to this as HMVC, but I won't). Here's the basics of an internal request.

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

$response = Route::dispatch($request);

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

What you should look at doing is constructing some sort of internal Dispatcher that allows you to dispatch API requests and return the original object. The dispatcher should also handle malformed requests or bad responses and throw exceptions to match.

The idea itself is solid. But planning an API is hard work. I'd recommend you write up a good list of all your expected endpoints and draft a couple of API versions then select the best one.

how to adhere to the Don't-Repeat-Yourself (DRY) principle when there will be too many if-then-else making the code unreadable?

Short of a full framework, what I tend to do for content (even if it contains logic) is separate it out into files and use another logical evaluation to merge them together (mangle them) and then evaluate the templating logic after that. This chunkifies your content and makes chunks sharable / reusable on common state.

This way each final template buffer is a flattened tree of discrete re-usable content nuggets that you can store on disk or a database. Even something as simple as a little parser that replaces:

<h1>{{insert:shared_page_header}}</h1>

With shared_page_header.txt helps keep things separate. It also forces you to look at separation on concerns even in the logic that is embedded in your templates. Manageable, reusable chunks of anything (dynamic or not) are always the way to go. Your templates are just strings until evaluated, so treat them as shared components merged into a big-dirty-string(TM) and then evaluated.

Good Luck

SOLID in Laravel

I'd rather suggest you create service User and have all methods inside this service. And from ExcelController call:

(new UserService())->import($parameters);

And from UserController call:

(new UserService())->create($parameters);

In laravel you can use Service Container and write something like:

$userService = $this->app->make('UserService');
$userService->import($parameters);
// or
$userService->create($parameters);

Stop Route Group from being processed

The callback function closure is executed as part of the call to Route::group(), so there is no way to prevent the callback from executing. You could, however, prevent the routes from being defined in the first place.

// only create the api routes if the current request is for the api
if (Request::getHttpHost() == Config::get('app.api_server')) {
Route::group(['domain' => Config::get('app.api_server')], function ()
{
//API entry point
});
}

// only create the web app routes if the current request is for the web app
if (Request::getHttpHost() == Config::get('app.web_server')) {
Route::group(['domain' => Config::get('app.web_server')], function ()
{
//Web Application entry point
});
}

How to redirect user invoking a function in contoller Class? - Laravel

If I understand right, you want call controller method from another controller method.
You could try it this way:

$request = Request::create('calculate/some_payload', 'GET', $params);
return Route::dispatch($request)->getContent();

For more info see Jason Lewis answer here: Consuming my own Laravel API



Related Topics



Leave a reply



Submit