Object Storage APIs

In this chapter

We'll go hands-on with the real object storage API — plain HTTP operations (PUT, GET, DELETE, HEAD, LIST), addressed by bucket and key — and find the one honest limit worth planning for: a single PUT request can't reasonably hold an unlimited amount of data.

7–9 min

The Problem in Real Life

GreenMart's engineering team is ready to actually move the first product images. "So what does the code even look like?" Mike asks. "Is this a totally different way of talking to storage?"

Sarah shakes her head. "It's genuinely simpler than you'd expect. Underneath, it's just real HTTP requests."

What does actually reading and writing an object look like, in real code?

Mike

A Real File Handle vs. A Real HTTP Request

Just real HTTP, addressed by bucket and key

PUT to store, GET to fetch, DELETE to remove — no special file handle, just ordinary HTTP requests the team already knows.

A real, honest limit on a single PUT

Sending a whole object as one request body has a practical ceiling — large files need a genuinely different approach.

An object storage API is, almost universally, a real, ordinary HTTP interface — the same protocol GreenMart's own storefront already speaks to browsers. There's no special, real file handle to open; every operation is a real, complete HTTP request, addressed by bucket and key.

PUT — storing a whole object, in one real request. Writing an object means sending a real HTTP PUT request to a URL built from the bucket and key, with the object's actual content as the request body. There's no real "open, write some bytes, close" sequence the way a file system offers (Act 3) — the entire object is sent, and stored, as one complete, real operation.
GET — fetching a whole object, by its real key. Reading an object means a real HTTP GET request to that same bucket-and-key URL, which returns the object's full real content in the response body, along with its real metadata as response headers — content type, size, and any custom tags GreenMart attached when it was written.
DELETE, HEAD, and LIST — the other real, essential operations. DELETE removes an object by key. HEAD fetches just an object's real metadata — size, content type, last-modified — without paying the real cost of downloading its full content, useful for a quick real existence or freshness check. LIST returns the real keys present in a bucket, optionally filtered by a shared prefix — the real mechanism behind a console displaying keys as if they were "folders," precisely the trick the last chapter named.
Real, honest limits worth knowing up front. Because a PUT sends an entire object as one real HTTP request body, there's a genuine, practical ceiling on how large a single PUT can reasonably or even successfully be — large files, video, big database exports, need a different real approach entirely. That real approach — multipart uploads — is exactly the next chapter's own subject.

Table — The Core Object Storage HTTP Operations

Operation	Real HTTP Method	What It Does
Store an object	PUT	Sends the full object content as the request body, addressed by bucket + key
Fetch an object	GET	Returns the full object content plus its real metadata as response headers
Remove an object	DELETE	Removes the object at that bucket + key
Check metadata only	HEAD	Returns metadata (size, type, last-modified) without downloading content
List objects	LIST (GET on the bucket)	Returns keys present in a bucket, optionally filtered by a shared prefix

GreenMart now has the real, practical shape of the API its own engineering team will actually write against — genuinely ordinary HTTP, addressed by bucket and key, with one real, honest catch worth planning for before the first large product image or export gets uploaded.

Key Takeaway

Object storage's real API is almost always plain HTTP — PUT to store a whole object, GET to fetch one, DELETE to remove one, HEAD for metadata alone, LIST for the keys in a bucket — genuinely simple, with one honest limit: a single PUT can't reasonably hold an unlimited amount of data.

Why This Matters

GreenMart's own engineering team can integrate object storage into the storefront using tools it already understands deeply — real HTTP requests — rather than learning an entirely new, unfamiliar interface, which meaningfully lowers the real cost of the migration this Act has been building toward.

GreenMart now has the real, practical API — PUT, GET, DELETE, HEAD, LIST — everything needed for ordinary objects. The next chapter covers what happens when an object is too large for one ordinary PUT: multipart uploads.