Http Helpers Laravel Package

Getting Started

Install pinned, not floated:

composer require juststeveking/http-helpers:0.0.3

Commit the lockfile. Then read vendor/juststeveking/http-helpers/src/ end to end — it's small, and this is the documentation. The release notes are a bare changelog link, so the source is the only place to learn the API. While you're in there, answer three questions that determine everything downstream:

1. Does it register a Laravel service provider, facade, or publishable config, or is it manually wired?
2. Does it require a PSR-18 client, bundle one, or consume Laravel's Http facade? This decides whether it complements or collides with Guzzle.
3. What PHP/Laravel versions does composer.json declare?

First use case: pick exactly one repetitive, low-stakes HTTP spot — a webhook dispatch or a status-poll lookup — and try to replace what's already there. Not auth, not payments. Verify in a single feature test that you can (a) make one real call and (b) observe the error path for a 4xx/timeout before you write a second call site.

Implementation Patterns

Put an adapter in front of it immediately. App\Support\Http\Client exposes the operations your app actually needs and delegates to the package inside. Call sites depend on your interface, never on package classes. This is the single rule that keeps the decision reversible.

Normalize at the boundary. Whatever response/exception types the package hands back, convert them in the adapter to your own DTOs or plain PSR responses and to consistent domain exceptions. Business logic should not know the package exists.

Use request-inspection helpers in one place. Header/Accept/content-type predicates belong in a base controller or middleware, not sprinkled per action — otherwise you've just moved the boilerplate.

Testing. If it composes over Laravel's client, Http::fake() works as usual. If it takes an injected PSR-18 client, bind a mock in the adapter's unit tests and keep the adapter thin enough that tests exercise your code rather than the package's.

Standardize the wrapper across squads. The real win isn't the helper functions, it's stopping three teams from writing their own Http::withHeaders(...) wrapper. Make the adapter the only approved path, and review for direct package imports.

Keep a short README in the adapter listing which helpers you actually use, why, and the fork/swap procedure. That file is the dependency's real documentation.

Gotchas and Tips

• 0.0.x patches may break. Pin to the exact version with no caret or tilde — ^0.0.3 will quietly take 0.0.4 on an unrelated composer update.
• Every release costs a diff read. Release notes say nothing, so budget ~10 minutes per bump to read the GitHub compare view. Cheap for one package; don't let it multiply.
• Never catch package exceptions in domain code. Exception types are the most common thing to shift in a 0.0.x line. Convert at the adapter edge.
• Check for a second HTTP client. After install, run composer why guzzlehttp/guzzle (or inspect composer.lock) to confirm it didn't pull a duplicate or constrain the version your app already uses.
• Verify timeout/retry reachability. If the helpers hide retry and timeout behind fixed defaults, you'll discover it under load. Set them explicitly at the adapter layer and prove they take effect in the spike.
• No service provider? Bind the client as a singleton in a service provider yourself — don't let new calls scatter into controllers.
• Last release April 2023, zero dependents, one maintainer. Write the fork trigger down while the adapter is fresh. MIT means you can vendor a patch; with the boundary in place, forking or swapping is a day of work.
• If it fights you, inline it. Thin helper layers are the easiest kind of dependency to outgrow, and the ~100 lines you actually need are yours to own. That's a legitimate outcome of the spike, not a failure.
• Confirm what's running: composer show juststeveking/http-helpers should match your pin, and diff the installed source against the 0.0.3 tag on GitHub if behavior surprises you.