HoorRPG to REST: Exposing Legacy AS/400 Logic as Modern APIs
The most common misconception about AS/400 modernization is that it requires rewriting the business logic itself. In most engagements, the RPG or COBOL programs are not the problem — they're often the most battle-tested, correct part of the whole stack. The problem is that nothing outside the green screen can talk to them. Fixing that doesn't require a rewrite. It requires an API layer.
The goal isn't to replace forty years of business logic. It's to make it reachable.
Why wrap instead of rewrite
Rewriting a mature RPG program means re-implementing every edge case, every validation rule, and every quirk of behavior that downstream processes have come to depend on — usually without complete documentation of what those rules even are. Wrapping the existing program behind an API preserves all of that behavior exactly, while making it accessible to anything that can make an HTTP call.
The typical integration pattern
Most AS/400 API integrations follow the same shape: a lightweight service layer running alongside IBM i accepts a REST request, translates it into the parameters an existing RPG program or CL command expects, invokes it (often via a program call or a data queue), and translates the result back into JSON. The RPG program itself is usually untouched — it's simply given a new way to be called, in addition to however it's invoked today.
Where this gets complicated
Programs originally designed for interactive 5250 sessions sometimes assume a human is present to handle prompts, confirmations, or multi-step screens. Wrapping these requires either refactoring the program into a callable subroutine that separates business logic from screen I/O, or building an orchestration layer that can simulate the expected interaction sequence. This is usually the bulk of the engineering effort — not the API layer itself, but untangling logic that was never designed to run headless.
What you get on the other side
Once core programs are reachable over REST, everything downstream gets simpler. Supply chain platforms, CRM systems, and internal dashboards can query live data instead of waiting for overnight batch exports. New applications can be built against a stable API contract instead of against the AS/400 directly, insulating them from changes to the underlying system. And critically, this can all happen incrementally — one program, one endpoint at a time — without a single "big bang" cutover.
Getting started
The right starting point is usually the two or three integrations causing the most manual work today — the flat-file exports, the screen-scraping scripts, the nightly batch jobs everyone quietly dreads. Wrapping those first delivers a fast, visible win and establishes the pattern for everything that follows. Talk to Hoorbit about API-enabling your AS/400 core.