RUEN
Package · sdk-s5w

S5W SDK

S5W SDK is the PHP client for S5W, a file store and CDN in one container. It turns the service’s HTTP API into ordinary method calls: you pass a path and get a File back, while the SDK decides whether to send it in one request or in chunks, retries the chunks that broke, and reports problems as exceptions of a specific type.

Package flytachi/winter-sdk-s5wPHP ≥ 8.4Server S5W, API v1

Coming to the SDK

Downloading files — files()->download() (streamed to disk) and files()->contents() (as a string in memory) — and temporary links — links(): issuing with an expiry and a download limit, listing, revoking one or all.

Until then use the API directly: delivery and temporary links. Every File already carries ready-made privateUrl and publicUrl addresses.

Why an SDK

You can talk to the S5W API directly — it is plain JSON over HTTP, described in Client API. But every project that does so ends up writing the same plumbing:

  • the key and headers on every request, and turning { code, message, errors } into an error;
  • choosing how to upload: up to 32 MiB in one multipart request, larger in chunks through /v1/uploads, with rules for chunk size, order and offset checks;
  • broken connections: find out whether a chunk landed, ask the server how much it holds, continue from the right place and never upload a file twice;
  • parsing answers into objects, dates into DateTimeImmutable, enum numbers into names.

The SDK does this once, the same way for everyone. Your code keeps only what you came to the store for.

What it looks like

php
use Flytachi\Winter\SDK\S5w\S5w;

$s5w = S5w::connect('https://s5.example.com', 's5w_9f3c…');

$file = $s5w->files()->upload('/tmp/report.pdf', folder: 'docs');

$file->id;           // "FXOkqegbdrNRWQgc" — how the file is addressed everywhere
$file->privateUrl;   // https://s5.example.com/p/FXOkqegbdrNRWQgc

The same upload() call handles a multi-gigabyte file too: the SDK sends it in chunks, survives a dropped connection and does not transfer content the bucket already holds. The whole scenario is in the quick start.

What it does

Feature Where
Checking the key and free space: check(), isValid() API reference
Folders: create, visibility, retention, cache policy Folders and files
Uploading from disk and from memory, image processing Uploading files
Large files: chunks, progress, resuming after a break Large files
Driving an upload step by step Step-by-step uploads
Listing files: search, folder filter, sorting, every page Folders and files
Renaming, moving, deleting Folders and files
Typed errors by response status Error handling
A Winter bean, several buckets, logging Winter integration

Principles

One client — one bucket. The bucket is decided by the key on the server, so you never specify it in the SDK and cannot get it wrong. Several buckets mean several clients. More in the mental model.

Objects instead of arrays. Every server answer is checked and turned into an immutable object with typed fields. If the server sends something unexpected, you get one clear error naming the field — not a TypeError somewhere deeper.

Exception type instead of parsing text. A server refusal becomes an exception chosen by status: NotFoundException, ConflictException, ValidationException and others. Branch on the class; keep the message for logs.

The key does not leak. It reaches neither logs nor a var_dump() of the configuration.

Requirements

PHP 8.4 and the curl extension. Details and Winter setup — on the Installation page.