Andrej PrusSenior Laravel systems
StartProject
Back to blog

APIs

How to Build a REST API in PHP Without a Framework in 2020

Step-by-step tutorial building a lightweight, dependency-free REST API using only native PHP and best-practice folder structure.

APIs12 min read2450 words
  • PHP
  • REST API
  • Native PHP
  • Architecture

SEO Metadata

SEO Title Options

  1. How to Build a REST API in PHP Without a Framework in 2020
  2. How to Build a REST API in PHP Without a: Practical 2026
  3. APIs Playbook: How to Build a REST API in PHP Without a

Meta Description Options

  1. Learn How to Build a REST API in PHP Without a Framework in 2020 with a practical APIs framework, expert mistakes, implementation steps, examples, FAQ.
  2. Step-by-step tutorial building a lightweight, dependency-free REST API using only native PHP and best-practice folder structure.

URL Slug

how-to-build-rest-api-php-without-framework-2020

Focus Keyword

How to Build a REST API in PHP Without a Framework in 2020

Additional LSI Keywords

  • APIs
  • PHP
  • REST API
  • Native PHP
  • Architecture
  • How to Build a REST API in PHP Without a Framework in 2020
  • production checklist
  • implementation guide
  • best practices
  • architecture decisions
  • testing strategy
  • performance impact

Table of Contents

Article overview

How to Build a REST API in PHP Without a Framework in 2020 is the kind of topic that looks simple until it reaches production. Teams usually discover the real cost late: unclear boundaries, weak defaults, hidden maintenance work, and decisions that seemed harmless when the codebase was small.

The problem gets worse when the article, tutorial, or implementation guide only explains the happy path. This guide closes that gap with a practical framework, a comparison table, common mistakes, and a deep technical section you can use while planning real work.

Keep reading for the non-obvious part: the safest implementation is rarely the most impressive-looking one. It is the one your team can debug, test, document, and evolve without turning every future change into archaeology.

Key Takeaways

  • How to Build a REST API in PHP Without a Framework in 2020 should be evaluated as a production decision, not only as a syntax or tooling choice.
  • The best implementation keeps responsibilities visible, with clear ownership, tests, documentation, and rollback paths.
  • Search visibility improves when practical depth, structured answers, and expert examples live on the same page.

[IMAGE: A mobile-first technical article layout showing the main concept, decision table, implementation checklist, and FAQ blocks. Alt: How to Build a REST API in PHP Without a Framework in 2020 expert guide for APIs]

What How to Build a REST API in PHP Without a Framework in 2020 means

How to Build a REST API in PHP Without a Framework in 2020 means applying apis knowledge to a concrete engineering decision, then turning that decision into reliable code, documentation, and operational behavior. In practice, it combines the topic's core concepts with trade-off analysis, implementation boundaries, testing strategy, and maintenance discipline.

This is the definition worth optimizing for featured snippets because it avoids hype. It tells the reader what the topic does and what a professional implementation must include.

Why it matters now

The technical web is more crowded than it was a few years ago. Thin tutorials can still get indexed, but they rarely earn trust from senior developers, buyers, AI answer systems, or teams that need production guidance.

For apis topics, the strongest content now has three layers:

  • a clear answer for fast scanning
  • a practical framework for implementation
  • expert context that explains what breaks later

That same structure helps search engines understand the page. It also helps readers decide whether the advice fits their project.

Implementation framework

Use this framework before adopting the approach described in this article.

  1. Define the user problem and the production risk.
  2. Identify the smallest reliable implementation boundary.
  3. Keep configuration, secrets, and environment-specific behavior outside the article's core logic.
  4. Add tests for the behavior that would hurt if it regressed.
  5. Document the trade-off, not only the final code.
  6. Measure the result with logs, metrics, or user-facing outcomes.
  7. Revisit the decision after real usage exposes edge cases.

The sequence is deliberately conservative. It keeps the work grounded in outcomes instead of novelty.

[IMAGE: A seven-step implementation framework with discovery, boundary design, configuration, tests, documentation, measurement, and iteration. Alt: How to Build a REST API in PHP Without a Framework in 2020 implementation framework]

Practical comparison

Decision areaStrong approachWeak approachWhy it matters
ScopeSolve one clear problemMix unrelated concernsFocus improves testing and search intent
ArchitecturePut logic in explicit classes or documented boundariesHide behavior in templates or incidental callbacksFuture changes stay easier to review
Data flowPass prepared data into the view or endpointQuery or compute in presentation codeReduces regressions and performance surprises
TestingCover the risky behavior directlyTest only the happy pathCatches production failures earlier
DocumentationExplain trade-offs and limitsRepeat generic definitionsBuilds E-E-A-T and reader trust
OperationsTrack logs, metrics, and rollback stepsShip without measurementMakes the decision reversible

This table is intentionally practical. It gives a reviewer something to check before the implementation becomes expensive to change.

Expert workflow

Expert tip: "Treat How to Build a REST API in PHP Without a Framework in 2020 as a system boundary. If the next developer cannot find where the decision lives, how it is tested, and when it should be avoided, the implementation is not finished."

A useful workflow is simple:

  • Start with the smallest working example.
  • Add the constraints that exist in your real project.
  • Remove anything that only demonstrates cleverness.
  • Write down the failure modes.
  • Add links to related decisions so future readers can navigate the topic cluster.

That last point matters for both humans and search systems. A single article can answer a question; a cluster proves authority.

Common mistakes

Mistake 1: Copying a pattern without its context

A pattern that works in a small demo can fail in a real application. The missing context is usually data volume, team experience, deployment process, security requirements, or observability.

Before copying the pattern, ask what assumption made it safe in the original example.

Mistake 2: Putting business logic in the wrong layer

This is the fastest way to make future debugging expensive. In Laravel, PHP, and server-rendered websites, presentation should receive prepared data, not discover rules on its own.

Keep decision logic in models, actions, services, policies, requests, jobs, or documented helpers where it can be tested directly.

Mistake 3: Optimizing for novelty instead of maintainability

Newer tools and language features can be valuable. They can also hide simple behavior behind unfamiliar syntax.

Use the option that makes the next production incident easier to understand.

Mistake 4: Publishing without a measurement plan

If the article describes a performance, SEO, security, or architecture improvement, define how success will be checked. Logs, tests, crawl diagnostics, analytics, and user behavior are all stronger than assumptions.

[IMAGE: A common-mistakes board with context loss, wrong layer, novelty bias, and missing measurement highlighted. Alt: How to Build a REST API in PHP Without a Framework in 2020 common mistakes]

Image placeholders

  • [IMAGE: A concept diagram for How to Build a REST API in PHP Without a Framework in 2020 with input, decision boundary, implementation, tests, and production feedback. Alt: How to Build a REST API in PHP Without a Framework in 2020 concept diagram]
  • [IMAGE: A mobile screenshot-style checklist for How to Build a REST API in PHP Without a Framework in 2020. Alt: How to Build a REST API in PHP Without a Framework in 2020 mobile checklist]
  • [IMAGE: A comparison table visualization for strong versus weak implementation choices. Alt: How to Build a REST API in PHP Without a Framework in 2020 comparison table]

Video placeholder

[VIDEO: Insert a 5-8 minute YouTube walkthrough that demonstrates the main decision, the implementation boundary, the test strategy, and the production caveats for How to Build a REST API in PHP Without a Framework in 2020.]

Internal linking opportunities

Original Technical Deep Dive

Why build without a framework

In 2020, a small REST API did not always need Laravel, Symfony, Slim, or Lumen. A framework is useful when you need routing, middleware, authentication, validation, database abstractions, queues, and long-term team conventions. But for a small internal API, webhook receiver, prototype, or learning project, native PHP can be enough.

The goal is not to recreate a framework badly. The goal is to keep the surface area small, make HTTP behavior explicit, and leave a clean path to migrate later if the API grows.

This tutorial uses plain PHP, no Composer packages, and a simple JSON file as storage. In production, replace the repository layer with PDO and a real database, but keep the same boundaries.

Folder structure

Start with a structure that separates the public entrypoint from application code:

project/
  public/
    index.php
  src/
    Controllers/
      UserController.php
    Http/
      Request.php
      Response.php
      Router.php
    Repositories/
      UserRepository.php
  storage/
    users.json

Only public/index.php should be web-accessible. Everything else is application code or storage.

If you use Apache, point the virtual host document root to public. If you cannot change the document root, use rewrite rules carefully and block direct access to src and storage.

Front controller

The front controller receives every request, loads the small application pieces, registers routes, and sends a response.

<?php

declare(strict_types=1);

require_once __DIR__ . '/../src/Http/Request.php';
require_once __DIR__ . '/../src/Http/Response.php';
require_once __DIR__ . '/../src/Http/Router.php';
require_once __DIR__ . '/../src/Repositories/UserRepository.php';
require_once __DIR__ . '/../src/Controllers/UserController.php';

$request = Request::fromGlobals();
$router = new Router();
$controller = new UserController(
    new UserRepository(__DIR__ . '/../storage/users.json')
);

$router->get('/users', [$controller, 'index']);
$router->get('/users/{id}', [$controller, 'show']);
$router->post('/users', [$controller, 'store']);

$router->dispatch($request)->send();

This keeps index.php boring. It should not contain validation, persistence, or response-building logic beyond wiring the application together.

Request object

Native PHP gives you $_SERVER, $_GET, and php://input. Wrap them so the rest of the application does not depend on globals.

<?php

declare(strict_types=1);

final class Request
{
    public function __construct(
        public string $method,
        public string $path,
        public array $query,
        public array $body,
    ) {
    }

    public static function fromGlobals(): self
    {
        $path = parse_url($_SERVER['REQUEST_URI'] ?? '/', PHP_URL_PATH) ?: '/';
        $body = json_decode(file_get_contents('php://input') ?: '{}', true);

        return new self(
            strtoupper($_SERVER['REQUEST_METHOD'] ?? 'GET'),
            rtrim($path, '/') ?: '/',
            $_GET,
            is_array($body) ? $body : [],
        );
    }
}

For a JSON API, invalid JSON should eventually produce a 400 Bad Request. Keep the first version simple, then add stricter parsing once the route behavior is working.

Response helper

Every endpoint should return JSON with the correct HTTP status and content type.

<?php

declare(strict_types=1);

final class Response
{
    public function __construct(
        private array $payload,
        private int $status = 200,
    ) {
    }

    public static function json(array $payload, int $status = 200): self
    {
        return new self($payload, $status);
    }

    public function send(): void
    {
        http_response_code($this->status);
        header('Content-Type: application/json; charset=utf-8');

        echo json_encode($this->payload, JSON_UNESCAPED_SLASHES);
    }
}

This is not fancy, but it prevents controllers from repeating headers and json_encode() everywhere.

Router

A tiny router only needs to match method, static path segments, and simple path parameters.

<?php

declare(strict_types=1);

final class Router
{
    private array $routes = [];

    public function get(string $path, callable $handler): void
    {
        $this->add('GET', $path, $handler);
    }

    public function post(string $path, callable $handler): void
    {
        $this->add('POST', $path, $handler);
    }

    private function add(string $method, string $path, callable $handler): void
    {
        $pattern = preg_replace('#\{[a-zA-Z_][a-zA-Z0-9_]*}#', '([^/]+)', $path);

        $this->routes[] = [$method, '#^' . $pattern . '$#', $handler];
    }

    public function dispatch(Request $request): Response
    {
        foreach ($this->routes as [$method, $pattern, $handler]) {
            if ($method !== $request->method) {
                continue;
            }

            if (preg_match($pattern, $request->path, $matches)) {
                array_shift($matches);

                return $handler($request, ...$matches);
            }
        }

        return Response::json(['error' => 'Not found'], 404);
    }
}

This router is deliberately limited. If you need route groups, middleware, named routes, URL generation, content negotiation, and parameter binding, that is the point where a micro-framework starts earning its keep.

Repository

Keep storage behind a repository so the controller does not care whether data comes from JSON, MySQL, PostgreSQL, or an external API.

<?php

declare(strict_types=1);

final class UserRepository
{
    public function __construct(private string $path)
    {
    }

    public function all(): array
    {
        if (! is_file($this->path)) {
            return [];
        }

        $users = json_decode(file_get_contents($this->path) ?: '[]', true);

        return is_array($users) ? $users : [];
    }

    public function find(string $id): ?array
    {
        foreach ($this->all() as $user) {
            if ((string) ($user['id'] ?? '') === $id) {
                return $user;
            }
        }

        return null;
    }

    public function create(array $data): array
    {
        $users = $this->all();
        $user = [
            'id' => (string) (count($users) + 1),
            'name' => $data['name'],
            'email' => $data['email'],
        ];

        $users[] = $user;

        file_put_contents($this->path, json_encode($users, JSON_PRETTY_PRINT));

        return $user;
    }
}

[IMAGE: Supporting visual 1 for How to Build a REST API in PHP Without a Framework in 2020, showing How to Build a REST API in PHP Without a Framework in 2020 decisions, examples, and PHP, REST API, Native PHP. Alt: How to Build a REST API in PHP Without a Framework in 2020 how-to-build-rest-api-php-without-framework-2020 visual 1]

[IMAGE: Supporting visual 1 for How to Build a REST API in PHP Without a Framework in 2020, showing How to Build a REST API in PHP Without a Framework in 2020 decisions, examples, and PHP, REST API, Native PHP. Alt: How to Build a REST API in PHP Without a Framework in 2020 how-to-build-rest-api-php-without-framework-2020 visual 1]

JSON storage is fine for a tutorial. It is not safe for concurrent production writes unless you add locking, validation, backups, and error handling. Use a database when the data matters.

Controller

The controller should translate HTTP input into application operations and return HTTP responses.

<?php

declare(strict_types=1);

final class UserController
{
    public function __construct(private UserRepository $users)
    {
    }

    public function index(Request $request): Response
    {
        return Response::json(['data' => $this->users->all()]);
    }

    public function show(Request $request, string $id): Response
    {
        $user = $this->users->find($id);

        if ($user === null) {
            return Response::json(['error' => 'User not found'], 404);
        }

        return Response::json(['data' => $user]);
    }

    public function store(Request $request): Response
    {
        $errors = $this->validate($request->body);

        if ($errors !== []) {
            return Response::json(['errors' => $errors], 422);
        }

        return Response::json([
            'data' => $this->users->create($request->body),
        ], 201);
    }

    private function validate(array $data): array
    {
        $errors = [];

        if (trim((string) ($data['name'] ?? '')) === '') {
            $errors['name'] = 'Name is required.';
        }

        if (! filter_var($data['email'] ?? '', FILTER_VALIDATE_EMAIL)) {
            $errors['email'] = 'A valid email is required.';
        }

        return $errors;
    }
}

Notice the status codes:

  • 200 for successful reads.
  • 201 for successful creation.
  • 404 when a resource does not exist.
  • 422 when JSON is syntactically valid but the submitted data fails validation.

Testing with curl

Start PHP's built-in server from the project root:

php -S 127.0.0.1:8080 -t public

List users:

curl http://127.0.0.1:8080/users

Create a user:

curl -X POST http://127.0.0.1:8080/users \
  -H 'Content-Type: application/json' \
  -d '{"name":"Ada Lovelace","email":"ada@example.com"}'

Fetch one user:

curl http://127.0.0.1:8080/users/1

What to add before production

This is a good learning skeleton, not a finished production platform. Before using it for real clients, add:

  • Database storage through PDO.
  • Input size limits.
  • Request JSON parse errors.
  • Authentication and authorization.
  • CORS rules if browsers call the API.
  • Rate limiting at the web server or application layer.
  • Structured error responses.
  • Logs that do not leak sensitive payloads.
  • Tests for routing, validation, and persistence.
  • Deployment rules that keep src and storage private.

When to stop building by hand

A dependency-free API is useful while the behavior is small. Move to a framework when the infrastructure around the API starts becoming the main work.

The warning signs are clear: route middleware, JWT or session authentication, database migrations, dependency injection, request validation classes, pagination, OpenAPI docs, queues, caching, file uploads, or multiple developers touching the same codebase.

At that point, Laravel, Symfony, or a micro-framework is not overhead. It is a way to stop maintaining your own framework by accident.

FAQ

What is How to Build a REST API in PHP Without a Framework in 2020?

How to Build a REST API in PHP Without a Framework in 2020 is a practical apis topic that should be evaluated through implementation scope, production risk, testing, documentation, and long-term maintainability.

When should a team use How to Build a REST API in PHP Without a Framework in 2020?

Use How to Build a REST API in PHP Without a Framework in 2020 when it solves a real project constraint, improves clarity, or reduces operational risk. Avoid it when it only adds novelty or hides behavior from future maintainers.

What is the biggest risk with How to Build a REST API in PHP Without a Framework in 2020?

The biggest risk is copying a pattern without its context. Production systems need clear boundaries, rollback options, tests, and observability before a technique becomes dependable.

How do you test How to Build a REST API in PHP Without a Framework in 2020?

Test the smallest unit that owns the behavior, then add integration coverage for the path users or systems actually rely on. Include failure cases, configuration differences, and regression checks.

How does How to Build a REST API in PHP Without a Framework in 2020 affect SEO and AI search visibility?

It improves visibility when the article gives a direct answer, expert context, structured headings, internal links, trustworthy references, and FAQ content that matches the visible page.

Conclusion

How to Build a REST API in PHP Without a Framework in 2020 is worth doing when the implementation improves clarity, reliability, or delivery speed. It is not worth doing when it hides ownership, increases operational risk, or makes the system harder to explain.

Use the framework above as a review checklist. Then connect this topic to the rest of the project documentation so readers can move from concept to implementation without losing context.

Top