Restlogger Laravel Package

Getting Started

This release (2.1.2) is a maintenance patch — composer metadata, README corrections, and log-handling tweaks — so there are no migration steps from 2.1.1. Treat the README refresh as the authoritative setup guide since the require field was corrected alongside it.

1. Install via Composer: composer require sunny-mahajan/laravel-rest-apis-logger.
2. Publish the package assets: php artisan vendor:publish --provider="SunnyMahajan\RestApisLogger\RestApisLoggerServiceProvider" (tag/config/migrations may differ — check the published README's provider class name).
3. Run php artisan migrate to create the API log table.
4. Register the logging middleware in app/Http/Kernel.php (or bootstrap/app.php on Laravel 11+) — typically appended to the api middleware group so it captures every REST route.
5. Hit a test endpoint and confirm a row lands in the log table.

First use case: drop the middleware on your api group and you immediately get a request/response audit trail (method, path, payload, status, timing) without touching controller code.

Implementation Patterns

Global API logging. Add the middleware to the api group in the HTTP kernel. This is the lowest-effort pattern and covers all versioned API routes at once.

Scoped logging. Register the middleware as a route middleware alias and apply it only to sensitive or high-value routes (e.g. ->middleware('api-logger') on payment or auth endpoints) so you avoid table bloat on noisy health-check or webhook routes.

Custom log model. If you need extra columns or relationships, extend the package's log model and point the config at your subclass. This keeps package upgrades intact while letting you attach user_id, tenant IDs, or correlate to an internal request ID.

Config-driven filtering. Use the published config to toggle logging, set the storage connection, and exclude paths. Prefer excluding via config over conditional middleware placement — it's easier to audit and change per environment.

Pair with auth context. Log after authentication middleware runs so you can enrich entries with the authenticated user. Middleware ordering matters here: the logger should run after auth but still capture the response, which means relying on the terminating phase rather than just the request phase.

Environment gating. Enable full payload logging in staging, and restrict to metadata (status, duration, route) in production if compliance or volume is a concern. The corrected composer.json/require field in 2.1.2 mainly affects install-time dependency resolution, so pin your Laravel version explicitly if you're on an older LTS.

Gotchas and Tips

• Sensitive data leakage. Request bodies routinely contain passwords, tokens, and card data. Check whether the package masks fields by default; if not, add a redaction layer in your custom log model or a middleware that sanitises before persistence.
• Response capture timing. Capturing the response body usually requires a terminating middleware. If you log only in handle(), you'll record the request but miss the actual response payload and status.
• Log table growth. There's no built-in retention mentioned; plan a pruning job (php artisan model:prune or a scheduled delete) or the table will balloon fast on busy APIs.
• Performance overhead. Writing a row per request adds latency and DB load. For high-throughput APIs, consider queueing the write or sampling requests.
• Config caching. After editing the published config, run php artisan config:clear (or config:cache) — stale cached config is the most common "why isn't it logging" cause.
• Middleware order. Placing the logger before auth means unauthenticated requests get logged too (often desirable) but user context is missing; placing it after means auth failures are invisible. Decide deliberately.
• Payload size limits. Large multipart uploads or file bodies can bloat rows or exceed column limits. Truncate or skip non-JSON bodies in config.
• 2.1.2 specifics. The "Log changes" PR from a first-time contributor is worth a quick review of the diff before upgrading in production — patch releases touching logging internals can subtly change what gets written. No breaking changes are indicated, but verify the log schema hasn't shifted if you have custom reporting on the table.
• Extension points. The config file and the log model are your main hooks; avoid editing vendor files so future patches apply cleanly.