Weave Code
Weaver
Helps Laravel developers discover, compare, and choose open-source packages. See popularity, security, maintainers, and scores at a glance to make better decisions.
Feedback
Share your thoughts, report bugs, or suggest improvements.
Subject
Message

Http Laravel Package

wandu/http

wandu/http is a lightweight HTTP component for PHP, offering request/response abstractions and helpers for headers, cookies, and common web interactions. It provides a clean, framework-friendly foundation for building HTTP applications in Wandu or standalone projects.

Deep Wiki
Context7

Getting Started

Treat wandu/http as a small outbound HTTP client plus request/response value objects, not as a replacement for Laravel's HTTP layer. Laravel already gives you Illuminate\Http\Request (Symfony-backed) for inbound traffic and Illuminate\Support\Facades\Http (Guzzle-backed) for outbound calls. The realistic entry point for this package is a narrow outbound integration in a legacy or framework-agnostic service class where you don't want a Guzzle dependency chain.

Minimal steps:

  1. Confirm it will install and run on your PHP version. The last release is from September 2016 and the repository is archived. Before anything else, run composer require wandu/http in a scratch project on the exact PHP version your app uses (7.4, 8.1, 8.2…). If it fails on deprecations or reserved-word conflicts, stop there — do not force it into a Laravel app you have to maintain.
  2. Read src/ before the README. For a package this small and this old, the classes themselves are the documentation. Look for the request, response, header, URI/query, and client classes; the header and query helpers are the parts the description actually promises, and they are usually the most self-explanatory.
  3. Read the tests. With 17 stars and no living docs, tests/ is the only reliable source of intended usage — especially for how headers are set/merged and how a client call is issued.
  4. First use case: wrap a single third-party API call. Build the request (method, URI, query params, headers), send it through the package's client, and convert the result into a plain array/DTO before it touches your domain code. Keep the surface area to one service class so you can delete it later.

If you only need one call, write Http::withHeaders(...)->get(...) and skip the package. Adopt it only if you specifically want its request/response/header abstractions outside of Laravel's helpers.

Implementation Patterns

Bind it behind your own interface. Never let Wandu\Http\* types appear in controllers, jobs, or domain services. Define App\Contracts\ApiClient with methods like fetchUser(int $id): array, implement it with WanduHttpApiClient, and bind it in a service provider. This is the single most important pattern given the package's archived status — it makes replacement a one-line container change.

Adapter at the boundary. Convert in both directions inside the adapter: Laravel/Symfony request data → package request object, and package response → PSR-7-ish or plain arrays. If you need PSR-7 interoperability, do the conversion explicitly rather than type-hinting PSR interfaces; "PSR-friendly" in the description is not a guarantee of PSR-7 conformance, and this package predates widespread PSR-7 adoption.

Use the header/query helpers for the boring parts. The genuine value here is assembling multi-value headers and encoding query strings without hand-rolling http_build_query. Centralize those helpers in the adapter so signature generation, API keys, and Accept headers are built in exactly one place.

Configuration through Laravel config, not package globals. Put base URL, timeout, and credentials in config/services.php under a named entry, and read them in the service provider when constructing the client. Avoid static/global configuration if the package offers it — it makes tests order-dependent.

Testing pattern. Because you hid the package behind an interface, tests bind a fake implementation and never hit the network. For the adapter itself, keep one small integration test against a local stub server so upgrades or PHP bumps surface breakage immediately.

Keep it at the edge. Do not use the package's request/response objects as your application's transport types. Map to DTOs in the adapter; this also protects you from body-stream consumption quirks and header-case differences leaking into business logic.

Gotchas and Tips

  • Archived since 2016. No security patches, no PHP 8 fixes, no maintenance. Pin an exact version, commit the lock file, and add a note to your upgrade checklist. Treat any CVE scan hit as "replace, don't patch."
  • "PSR-friendly" ≠ PSR-7 compliant. Do not type-hint Psr\Http\Message\RequestInterface against these objects without verifying. Assume incompatibility and write explicit conversion.
  • PHP version landmines. Code from this era commonly trips on reserved words used as method names, curly-brace string/array offsets, and each()/create_function() style helpers. Run the full suite on your target PHP before merging anything.
  • Header semantics. Header names are case-insensitive per RFC, but implementations vary. Check whether setting a header replaces or appends, and how multi-value headers (Accept, Set-Cookie) are represented. Always read headers through a case-insensitive accessor, never by array key.
  • Query encoding. http_build_query defaults to PHP_QUERY_RFC1738 (spaces as +). APIs that expect RFC 3986 (%20) will silently misbehave. Confirm which encoding the helper uses and override if necessary.
  • No retries, backoff, pooling, or circuit breaking by default. Wrap the client with your own timeout and a single retry on connection errors. A "lightweight, minimal dependencies" toolkit means you own the resilience story.
  • Stream/body consumption. If responses are stream-backed, the body is often readable once. Buffer it to a string immediately in the adapter; don't pass the response object around.
  • TLS verification. Verify that peer verification is on by default. If the package exposes a way to disable it, make sure that flag is never reachable from config in production.
  • Extension points. Favor decoration over subclassing: wrap the package's client in your own class that adds logging, timing, and error mapping. This survives minor internal changes far better than extending its classes.
  • Debugging. Add a Log::debug() of the fully-built URL, method, and header names (redact secrets) right before sending, and the status plus body length after. When something fails silently in a package this old, raw request/response dumps are faster than stepping through the source.
  • Have an exit plan. For almost every Laravel codebase today, Illuminate\Support\Facades\Http is the better default: maintained, testable via Http::fake(), and already in the framework. If you adopt wandu/http, write the adapter so migrating back is an afternoon's work, not a refactor.
Weaver

How can I help you explore Laravel packages today?

Conversation history is not saved when not logged in.
Prompt
Add packages to context
No packages found.
jinas/dhivatar
store-doc/laravel-storage-driver
plus-it/laravel-translation-manager
diephp/perhaps
diephp/telegraph
osmaviation/spreadsheet
microsoft/fluentui-system-icons
mmccook/php-json-canonicalization-scheme
middlewares/firewall
qubiqx/montapacking
nyoncode/laravel-package-console
pnscripts/filament-broadquill-lite
pnscripts/laravel-sentfold-lite
vleap/mx-sdk-laravel-internal
twidpay/utils
htetmyathlaing/scout-elasticsearch-driver
artisan-toolbox/front-awesome
ls/client-assistant
users-au/laravel-client
cgv/localized-resource