Page 8 - REST-API

Anyone calling external APIs in PHP with cURL or Guzzle often ends up with fragile integrations that lack retry logic, clean mocking in tests, and type safety. Symfony HttpClient delivers all of that as part of the framework, with scoped clients, automatic retries, asynchronous concurrency and a MockHttpClient for fully isolated unit tests.

GraphQL doesn't put version numbers in the URL, and that's intentional, not an accident. Running a GraphQL API stably over years requires a different discipline: additive schema evolution, clearly defined deprecation cycles, and automated checks that catch breaking changes before they ever get deployed.

JWT or sessions for Symfony REST APIs? The answer depends on scaling requirements, revocation needs, client type, and security model. Anyone who understands the difference between stateless and stateful authentication can make the right decision for their specific use case.

An API key needs to be renewed regularly or immediately in an emergency for various reasons, whether as a routine security measure or in response to an actual compromise. But a naive, immediate revocation of the old key instantly breaks every integration still using it, which is unnecessary for plannable routine rotations and often avoidable even in an emergency through a short, controlled transition period.

OAuth 2.0 handles authorization, OpenID Connect adds the missing identity layer, and confusing the two leads to insecure logins. This article explains the authorization code flow with PKCE as the current standard, covers common implementation mistakes around redirect URIs, state, and nonce, and shows how to integrate a social login securely into a Magento store.

A client sends a payment request, the network drops before the response arrives, and the client doesn't know whether the payment was actually processed. A naive retry at this moment can trigger a second, unintended charge, a problem that's unacceptable for financially sensitive operations. Idempotency keys solve this problem structurally, by letting the server reliably recognize a repeated request as a duplicate.

A script that simply aborts on the first 429 response is not automation, it is a ticking time bomb. Rate-limited API requests with retry in Bash respect Retry-After headers, use exponential backoff with jitter, and deliver reliable results even under strict API limits.

Many PHP APIs call themselves REST but are, on closer inspection, RPC calls wrapped in HTTP: one POST endpoint per action, always status code 200 regardless of outcome. Genuine RESTful API design in PHP requires resources instead of actions, correctly applied HTTP verbs, deliberate status codes and idempotency where it is expected, and none of that needs a framework to implement cleanly.

Unstable APIs fail in different ways: a short timeout, a 503, or sometimes no response at all. curl ships with built-in retry behavior through --retry, --retry-delay and --retry-connrefused that covers many of these cases, but understanding idempotency is what actually decides whether a retry is safe at all, without processing data twice.

GraphQL and gRPC solve different problems, even though both often sit side by side in the same architecture. GraphQL shines at flexible, client-driven queries for frontends, gRPC at binary, low-latency communication between backend services. This article shows when each protocol is the better choice.