graham-campbell/core-api
Core API provides a lightweight foundation for building APIs in Laravel, offering reusable interfaces, traits and helpers that keep endpoint development consistent, structured and easy to extend.
Read the source before the README. The README is thin and the package is archived — the authoritative spec is the code. Open these files in order:
composer.json — confirm the illuminate/* 4.x constraints and the Guzzle generation. This tells you immediately whether your target stack can even resolve it (on Laravel 5+ it cannot).src/ service provider — see what it binds into the container, what config it merges, and what it registers.Wire it into a legacy app (Laravel 4.1/4.2 only). Add the service provider and facade alias to app/config/app.php (providers and aliases), publish the config with php artisan config:publish graham-campbell/core-api, then fill in the base URL and credentials. There is no composer require path to a modern Laravel project — treat everything below as legacy-app or reference-only.
First use case: one real call. Subclass the abstract API base for a single upstream resource, resolve it from the container (via the facade or by type-hinting the class), and make one GET against a sandbox endpoint. Do this before anything else. It validates three unknowns at once: that the credentials work, that the request shape the package builds is still what the upstream expects, and that the response decoding produces what you think it does. Everything downstream — DTOs, error handling, tests — is guesswork until that one call succeeds.
Subclass per upstream service. The package's intended pattern is one subclass of the abstract API base per remote resource or service surface. Put the endpoint paths, vendor-specific headers, and response quirks in the subclass, and keep domain logic out of it. This is the one genuinely good idea the package encodes and it survives the migration.
Resolve through the container, not the facade. The facade is convenient at the REPL but it hardcodes a static dependency and makes tests brittle. Inject the API class (or, better, your own CoreApiClient interface) into controllers and jobs. The container binding is the seam that lets you swap in a fake.
Hide the transport behind an interface you own. Define CoreApiClient with methods that speak in your domain (fetchOrder($id), listAccounts()), and let the package subclass be one implementation. Call sites never see Guzzle, never see the facade, and never see the package — which is what makes the eventual replacement a one-file change rather than a grep-and-replace across the codebase.
Config drives everything runtime-visible. Base URL, credentials, and timeouts live in the published config. Keep them there and out of the subclass; the subclass should not hardcode a host or a timeout. In a legacy app the config file is also your migration checklist — it enumerates every knob you must reproduce when you rewrite.
Confine Guzzle-era idiom to the subclass. Exception handling, request options, and header assembly are all Guzzle-generation-specific. Isolating them means the rest of your application is written against your interface and does not inherit the package's age.
Testing pattern: bind a fake. Because the transport sits behind your interface, the day-to-day test workflow is a container swap — bind a stub CoreApiClient in the test case and assert against your domain methods. Do not unit-test the package's request-building by mocking Guzzle internals; it is not worth the effort and the package has no tests of its own to lean on.
Migrate incrementally behind the interface. When you replace it, cut consumers over one at a time. The interface keeps both old and new implementations temporarily compatible, so you can ship the rewrite without a big-bang cutover.
The package is a client, not a server. The description reads like a "JSON API foundation," but the technical reality is a config-driven HTTP client for one upstream. If you were expecting routing, controllers, and resources, you have the wrong package — and if your requirement is "call an HTTP API from Laravel," the answer is the Http facade or Guzzle 7, not this.
Abandonment is explicit. It lives under a GrahamDeprecated org, with zero stars, zero dependents, and no maintainer. There is no upstream security response, no triage, no release. If a codebase depends on it, register it as frozen in your dependency inventory with a named owner and a retirement date — do not plan around fixes arriving.
EOL runtime is the real risk, not the code. PHP 5.x and Laravel 4.x have had no security support since 2018. Every latent CVE in the runtime and in the package's Guzzle generation is your exposure with no patch path. This is what should drive prioritization, not the package's few hundred lines.
Composer will hard-conflict on any modern Laravel. illuminate/* 4.x constraints will not resolve against Laravel 5 through 12. There is no tagged compatible release and no maintainer to produce one. Do not start an evaluation expecting to composer require it anywhere current.
The upstream contract is undocumented. Auth scheme, rate limits, retry semantics, token refresh, and error shapes are not in the README — they must be reverse-engineered from source and live traffic. Capture what you learn as a written spec plus recorded fixtures. That spec is the durable asset; the code is not, and it outlives the package.
Supply-chain fragility is a build-integrity problem. An archived repository can disappear from Packagist and silently break reproducible builds and new-engineer onboarding. If a legacy consumer must keep the dependency, pin exact versions, commit composer.lock, mirror the repo to internal VCS, and document the mirror in the runbook.
Guzzle-generation API drift bites on migration. Guzzle 3/4-era ConnectException handling and request-option conventions differ from Guzzle 7; 4.x helpers (array_get, str_*, array_except) are gone; PSR-0/PSR-4 expectations differ; PHP 8 reserved words and type signatures may conflict. Price these as line items up front rather than discovering them mid-rewrite.
Facade access defeats testing. Reaching for the facade is the path of least resistance and the most common day-to-day mistake. It couples your code to a static container key and makes isolated tests awkward. Inject instead — the extra constructor argument is cheap and the seam pays for itself immediately.
Extension point: the container binding. The cleanest way to customize behavior (alternate auth, extra logging, a retry wrapper) is to rebind the API class or your interface in a service provider, not to edit vendored code. Editing vendored code is how a temporary legacy fix becomes unmergeable — and given the package is archived, there is no upstream to send the patch to.
Budget the replacement as days, not sprints. The realistic migration is 50–150 lines of first-party code behind an interface: extract endpoints, headers, auth, and error handling; rebuild on Http/Guzzle 7; add timeouts, retries, logging, and contract tests against fixtures; cut consumers over one at a time; delete the dependency. Attach it to your Laravel upgrade rather than funding it as a standalone initiative, and frame the outcome as "keep the layering pattern, drop the artifact."
How can I help you explore Laravel packages today?