- Is kipchak/driver-http for inbound HTTP endpoints or outbound HTTP clients?
- The official overview describes an HTTP driver for the Kipchak microservices framework that maps HTTP verbs and paths to service methods, with request parsing, response serialization, and middleware. The package blurb and technical assessment also describe it as a named-driver abstraction over Laravel's outbound HTTP client. Because those descriptions point in different directions, confirm the intended use in the source and README before adopting.
- How do I install kipchak/driver-http in a Laravel app?
- Install it with Composer using composer require kipchak/driver-http. In Laravel, the package may be auto-discovered; if not, register its service provider manually. Publish any provided configuration before defining drivers or routes, and verify the PHP and Laravel constraints in composer.json.
- Which Laravel and PHP versions does kipchak/driver-http support?
- The provided context does not state PHP or Laravel version constraints. Check composer.json for require entries and look for a CI matrix covering Laravel 9, 10, 11, or other versions. Do not assume support based on the package name alone.
- Does kipchak/driver-http wrap Laravel's HTTP client or implement its own transport?
- The technical assessment expects it to be a thin abstraction over Laravel's outgoing HTTP client, which would preserve Http::fake(), Http::assertSent(), retry and timeout options, and client events. That delegation is the key integration question and must be verified in source, not assumed. If it implements its own transport, integration and testing costs rise materially.
- How are drivers registered and resolved in kipchak/driver-http?
- The context mentions named drivers and integration with the Kipchak service container, but it does not specify whether registration is config-based, container-based, or both. Check the service provider and configuration files for how base URIs, headers, auth, and default options are bound. Confirm resolution behavior in tests before standardizing on it.
- Can I use Http::fake() to test integrations built with kipchak/driver-http?
- If the package delegates to Laravel's HTTP client underneath, Http::fake() and Http::assertSent() should work as usual. If it implements a custom transport, you will need separate test scaffolding. Verify by reading the driver implementation and running a small fake-based test.
- What middleware and authentication features does kipchak/driver-http support?
- The overview lists middleware support for auth, CORS, and validation, plus PSR-7 compatible request and response handling. For outbound drivers, auth, headers, base URI, and default options are described as driver configuration. Middleware ordering and exact auth mechanisms are not documented in the provided context, so review the source and test the order.
- How does kipchak/driver-http handle non-2xx responses, retries, and timeouts?
- The context does not define whether non-2xx responses throw exceptions or return response objects, nor how retries and timeouts are configured. If it wraps Laravel's HTTP client, those behaviors may follow Laravel's defaults and driver options. Confirm exception-versus-response semantics and middleware ordering before relying on them in production.
- Is kipchak/driver-http safe to use in production?
- The package has effectively zero adoption signals in the technical assessment: no stars, no dependents, and a score of 0. A small wrapper has a small attack surface, but it also lacks community QA and downstream bug reports. The bigger risk is architectural: centralizing auth, base URIs, and defaults means one bad driver config can break every integration that uses it. Review code size, test coverage, license, maintainer activity, and your ability to fork it internally.
- What alternatives to kipchak/driver-http should I consider?
- For outbound HTTP in Laravel, teams often use Laravel's Http client directly or a dedicated wrapper such as a first-party SDK; the technical assessment warns against adopting this package for a single integration. For inbound service exposure, use the Kipchak framework's routing or another HTTP driver rather than assuming this package is an API gateway. If adoption evidence or vendor support is required, this package may not pass dependency approval.