Exercise HTTP request parsing, validation, routing and response output together. The examples separate the essential operation from the conditions a production implementation must enforce.
What It Does
Exercise HTTP request parsing, validation, routing and response output together.
Prerequisites
Use a dedicated development environment with test accounts and records. Separate authorization, validation and error handling from response formatting; never copy demonstration-only secrets into production.
Example 1: Core Behavior
The first example isolates the core operation so its result is easy to understand.
<?php
function respond(string $method): array {return $method==='GET'?[200,['items'=>[]]]:[405,['error'=>'Method Not Allowed']];}
[$code,$body]=respond('GET'); if ($code!==200||!isset($body['items'])) throw new LogicException('Integration failure'); echo 'OK';
Example 2: Alternative or Failure Case
The second example demonstrates an alternative outcome, rule or failure condition.
<?php
function parsePayload(string $raw): array {return json_decode($raw,true,512,JSON_THROW_ON_ERROR);}
try { parsePayload('{invalid'); echo 'Failed'; } catch (JsonException $e) { echo 'Invalid JSON rejected'; }
Practical Example: Applying the Rule
The practical example shows how to carry the same constraint into application code.
<?php
function policy(int $tenant,int $actor): int { return $tenant===$actor?200:404; }
foreach ([[2,2,200],[2,3,404]] as [$t,$a,$want]) {if (policy($t,$a)!==$want) throw new LogicException('Policy regression');} echo 'Passed';
Important Behavior and Edge Cases
Tests should isolate persistent state and use a separate database or an in-memory fake.
Comparison with Related Functions or Patterns
| Approach | When it differs |
|---|---|
| Creating Integration Tests for PHP APIs | Exercise HTTP request parsing, validation, routing and response output together. |
| Related API or pattern | Unit tests of a controller do not verify the HTTP transport boundary. |
Common Beginner Mistakes
| Mistake | Correct approach |
|---|---|
| Testing only a helper function, not the API request/response boundary | Tests should isolate persistent state and use a separate database or an in-memory fake. |
| Substituting a related API without checking its semantics | Unit tests of a controller do not verify the HTTP transport boundary. |
Key Takeaways
- Exercise HTTP request parsing, validation, routing and response output together.
- Tests should isolate persistent state and use a separate database or an in-memory fake.
- Unit tests of a controller do not verify the HTTP transport boundary.
Select this API or pattern based on its documented behavior and the trust boundaries in your own application, and test all external integrations against their actual deployments.