RESTful

How a 25-year-old architectural standard solved the AI Agent problem before it even started.

Labels
AI(14) AJAX(112) App Studio(10) Apple(1) Application Builder(245) Application Factory(207) ASP.NET(95) ASP.NET 3.5(45) ASP.NET Code Generator(72) ASP.NET Membership(28) Azure(18) Barcode(2) Barcodes(3) BLOB(18) Business Rules(3) Business Rules/Logic(140) BYOD(13) Caching(2) Calendar(5) Charts(29) Cloud(14) Cloud On Time(2) Cloud On Time for Windows 7(2) Code Generator(54) Collaboration(11) command line(1) Conflict Detection(1) Content Management System(12) COT Tools for Excel(26) CRUD(1) Custom Actions(1) Data Aquarium Framework(122) Data Sheet(9) Data Sources(22) Database Lookups(50) Deployment(22) Designer(178) Device(1) Digital Workforce(3) DotNetNuke(12) EASE(20) Email(6) Features(101) Firebird(1) Form Builder(14) Globalization and Localization(6) HATEOAS(5) How To(1) Hypermedia(3) Inline Editing(1) Installation(5) JavaScript(20) Kiosk(1) Low Code(3) Mac(1) Many-To-Many(4) Maps(6) Master/Detail(36) Micro Ontology(5) Microservices(4) Mobile(63) Mode Builder(3) Model Builder(3) MySQL(10) Native Apps(5) News(18) OAuth(9) OAuth Scopes(1) OAuth2(13) Offline(20) Offline Apps(4) Offline Sync(5) Oracle(11) PKCE(2) Postgre SQL(1) PostgreSQL(2) PWA(2) QR codes(2) Rapid Application Development(5) Reading Pane(2) Release Notes(186) Reports(48) REST(29) RESTful(30) RESTful Workshop(14) RFID tags(1) SaaS(7) Security(81) SharePoint(12) SPA(5) SQL Anywhere(3) SQL Server(26) SSO(1) Stored Procedure(4) Teamwork(15) Tips and Tricks(87) Tools for Excel(3) Touch UI(93) Transactions(5) Tutorials(183) Universal Windows Platform(3) User Interface(337) Video Tutorial(37) Web 2.0(100) Web App Generator(101) Web Application Generator(607) Web Form Builder(40) Web.Config(9) Workflow(28)
Archive
Blog
RESTful
Tuesday, December 2, 2025PrintSubscribe
The Missing Link: Why HATEOAS is the Native Language of AI

For the last two years, the tech industry has burned billions of dollars trying to solve the "Agent Problem." How do we get AI to reliably interact with software?

We built massive vector databases. We trained 100-billion-parameter reasoning models. We invented complex protocols like MCP (Model Context Protocol).

But the answer wasn't in the future. It was in the past.

It turns out that Roy Fielding solved the Agent Problem in his doctoral dissertation in 2000. We just ignored him because we didn't have agents yet.

The "Level 3" Gap

In software architecture, we rely on the Richardson Maturity Model to grade our APIs.

  • Level 2 (The Industry Standard): We use HTTP verbs (GET, POST) and resources. This works great for human developers who can read documentation and hard-code the logic into a UI.
  • Level 3 (Hypermedia / HATEOAS): The API itself tells the client what it can do next.

For 25 years, the industry stopped at Level 2. "Why do I need the API to send me links?" a developer would ask. "I know where the buttons go."

But AI Agents are blind. They don't have the intuition of a developer. They need a map.

Validation from the Field

There is recent talk in the software architecture community that vindicates this "Level 3" approach. International speaker and software architect Michael Carducci recently delivered a session titled "Hypermedia APIs and the Future of AI Agentic Systems," where he articulates the precise architectural reality we have witnessed in our own labs.

Carducci argues that we don't need smarter models; we need "Self-Describing APIs." When an API includes the controls (Hypermedia) in the response, the AI agent no longer needs to guess, hallucinate, or rely on brittle documentation. It simply follows the path laid out by the server.

The Digital Co-Worker: Theory into Practice

Carducci’s talk represents the Theoretical Physics of Agentic AI. The Axiom Engine—embedded in every Code On Time application—is Applied Engineering.

When we generate a Digital Co-Worker, we are not building a chatbot with tools. We are building a Level 3 HATEOAS Browser powered by an LLM. This is made possible by a specific set of technologies we refer to as the Axiom Engine.

1. The Cortex: REST Level 3 & HATEOAS

The built-in engine automatically projects your application's User Interface logic into a RESTful Level 3 API. This is not a separate "AI API" that you have to maintain; it is a mirror of your live application.

Because it uses HATEOAS (Hypermedia as the Engine of Application State), the API response contains both the data and the valid transitions. When the Co-Worker processes an invoice, it reads the _links array in the JSON response. If the invoice is paid, the pay link physically disappears, and the archive link appears. The AI cannot click a link that isn't there.

2. The Pulse: Loopback & Heartbeat

Intelligence is useless without execution. The Axiom Engine includes a server-side Heartbeat that performs "Batch Leasing." It wakes up, checks for pending prompts, leases a block of work, and begins "Burst Iterating."

Crucially, every action is performed via an HTTP Loopback Request to the application itself. The State Machine executes these requests using the user's access_token, which is included and automatically refreshed via the refresh_token as needed. This architecture allows an agent to execute a prompt over the course of months. The server can restart, or the process can pause for weeks, but the agent's session remains valid and secure.

3. The Memory: Immutable Anchors & Dynamic State

Context is the most expensive resource in AI. To manage this, we use a collaborative memory model that balances flexibility with strict mission adherence:

  • The Anchors (Positions 0-1): The User's Original Prompt and the System Instruction are permanently pinned to the first two positions of the state array. They are never compressed. This ensures that even after 100 iterations, the agent never forgets its core persona or its ultimate goal.
  • The Dynamic Tail: For the subsequent history, the LLM decides the "next state to keep" in every iteration. It explicitly chooses what relevant information to carry forward.
  • Intelligent Compression: The State Machine automatically compresses this dynamic tail based on configuration to keep the token count low, but it leaves the Anchors untouched.
  • The Cycle: This allows the agent to move forward indefinitely using a hybrid context: the immutable mission (Anchors), the accumulated wisdom (Compressed Tail), and the current reality (HATEOAS Resource).

All prompt iterations are persisted in the app's CMS, enabling full auditability and traceability of the agent's "thought process."

4. The Continuum: Infinite Context & Real-Time Sync

Unique to the Axiom Engine is the ability to maintain an Infinite Meaningful Conversation that can span years.

  • Sticky Context: A new prompt in an existing chat always starts with the Last Resource. If you finished talking about an Invoice last Tuesday, and type "Approved" today, the agent knows exactly which invoice you mean.
  • JIT Refresh: The world changes while the agent sleeps. When a conversation resumes—whether after 5 minutes or 5 months—the State Machine automatically refreshes the "stale" resource. The agent always sees the live data (e.g., that the invoice was already paid by someone else), preventing "ghost" actions.
  • Omnichannel Threads: This continuity works across all channels.
    • App: Supports multiple distinct chat threads.
    • SMS: Acts as a continuous, potentially year-long conversation stream.
    • Email: Each thread becomes a secure, long-term chat session.
  • The "Menu" Fail-Safe: If the user changes the topic entirely (e.g., switching from Invoices to Sales), and the LLM cannot resolve the request against the current resource, it has a universal escape hatch: the "Menu" Link. This leads to the equivalent of the application's main navigation menu, complete with human-readable tooltips. The agent simply clicks "Home" and navigates to the new subject, just like a human user would.

5. The Badge: Identity & Security

In the Axiom Engine, Identity is paramount.

  • OAuth 2.0 Authorization Code & Device Flow: Whether via web or "dumb" channels like SMS, every interaction is authenticated.
  • Federated Identity Management: The engine integrates with corporate IdPs. The Digital Co-Worker has no separate identity; it is the user. It inherits the exact Row-Level Security (RLS) and Audit logs of the human it is assisting.

We Saved Millions by Looking Backward

While competitors are trying to build "Self-Driving Cars" by training better drivers (AI Models), we focused on building "Smart Roads" (Hypermedia Apps).

This architectural decision has saved us—and our clients—tens of thousands of dollars in R&D and implementation costs. We didn't need to invent a proprietary "Agent Protocol." We just needed to implement the standard that the web was built on.

The industry is currently scrambling to reinvent the wheel. Meanwhile, your database is ready to become an Agentic Operating System today. You just need to give it a voice.

... Hypermedia APIs and the Future of AI Agentic Systems - Michael Carducci
This video features software architect Michael Carducci explicitly validating the Level 3 HATEOAS architecture as the critical enabler for autonomous AI systems, mirroring the exact technical strategy of the Axiom Engine.
Tuesday, November 11, 2025PrintSubscribe
Digital Co-Worker or Genius?

For over a decade, Code On Time has been the fastest way to build secure, database-driven applications for humans. The industry calls this Rapid Application Development (RAD). But recently, we realized that the rigorous, metadata-driven architecture we built for humans is also the perfect foundation for something much more powerful.

Today, we are announcing a shift in our vision. We are not just building interfaces for people anymore. We are evolving from a RAD tool for web apps into a RAD for the Digital Workforce. The same blueprints that drive your user interface are now the key to unlocking the next generation of autonomous, secure Artificial Intelligence.

The Digital Co-Worker (The "Glass Box")

Imagine an app that looks like Chat GPT. This app executes every prompt as if it is operating the "invisible UI" of your own database. Just like the human user, it inspects the menu options, selects data items, presses buttons, and makes notes as it goes. Then it reports back by arranging the notes into an easy-to-understand summary.

This is possible because a developer has designed the app with a real UI for your database. Both the DigitalI "Co-Worker" and the human UI are built from the exact same "blueprints" (called data controllers). These blueprints define the data, actions, and business logic for your application. When a user logs in (using their organization's existing security), the AI "digital employee" inherits your exact identity, meaning it sees only what you see and can only perform the actions available to you.

The AI "navigates" a system that has already been "security-trimmed" by user roles and simple, declarative SQL-based rules. This means if you aren't allowed to see "Salary" data, the AI is never shown the "Salary" option - it doesn't exist for that session. A "heartbeat" process allows these tasks to run 24/7, and the AI's "notes" (its step-by-step log) create a perfect, unchangeable audit trail of every decision it has made.

The Genius (The "Black Box")

Imagine another app that also looks like Chat GPT. To understand your database, this app employs a powerful, sophisticated AI model as its "brain". It operates by first consulting a comprehensive "manifest" - a detailed catalog of every "tool" and data entity it can access. This allows the AI to have a full, upfront understanding of its capabilities, so when you submit a prompt, it can process this entire catalog to create a complete, multi-step plan in a single "one-shot" operation.

This architecture is often built as a flexible, component-based system, which involves deploying several specialized services: one for the chat UI, another for the AI's "brain" (the orchestrator), and a dedicated "server" for each tool. Security is an explicit and granular consideration, requiring careful, deliberate configuration. Each tool-server's permissions must be managed, and the AI "brain" is trusted to orchestrate these tools correctly. This design allows for fine-tuning access (like "read/write all customer data") but means that security and prompt-based access must be actively managed and secured.

This "one-shot" planning model has a clear cost structure: the primary charge is for the single, complex "planning" call to the sophisticated "brain" model, which is required for every prompt. The success of the entire operation relies on the quality of this initial plan. If the AI's plan contains an error (for example, using incorrect database filter syntax) the operation may not complete as intended, and the cost of the "planning" call is incurred. This model prioritizes a powerful, upfront planning phase and depends on the AI's reasoning to be correct the first time.

How to Choose: The Auditable Co-Worker or the "Black Box" Genius

Your choice between the "Digital Co-Worker" and the "Genius" architecture is a strategic decision about what you value most: trust and durability or raw, unconstrained reasoning. The "Digital Co-Worker," built on the CoT framework, is an "invisible UI" operator. Its primary strength is its security-by-design. Because it inherits the user's exact, security-trimmed permissions, it is impossible for it to access data or perform actions it isn't allowed to. It operates within a "fenced-in yard" defined by your business rules. This makes it the perfect, auditable solution for the real-world workflows that require a quick response or need to run reliably for days or even months.

The "Genius" model, built on LLM+MCP, is a "one-shot" planner. Its primary strength is its power to reason over a massive, pre-defined database "map". It's designed for highly complex, one-time questions where the "planning" is the hardest part. This power comes at the cost of security and predictability; you are trusting a "black box" with a full set of tools, and its complex plans can be brittle, expensive, and difficult to audit. This model is best suited for scenarios where the sheer "intelligence" of the answer is more important than the security and durability of the process.

For a business, the choice is clear. The "Digital Co-Worker" is a platform you can build your entire company on. This is where it has a huge advantage: it can operate with a smart model for deep reasoning, but it also works perfectly with a fast, lightweight, and cheap model for 99% of tasks. The "Genius" model, by contrast, requires the most expensive model just to parse its complex manifest. Furthermore, the "Genius" model requires a massive upfront investment, potentially costing hundreds of thousands of dollars in custom development, integration, and security engineering before the first prompt is ever entered. The "Digital Co-Worker" platform, with its "BYOK" model and 100 free digital co-workers, makes it a risk-free, frictionless way to adopt a true workforce multiplier.

The Digital Co-Worker is Not a Chatbot

It is easy to mistake the "Digital Co-Worker" for a chatbot because they both speak your language. However, the difference is fundamental. As industry experts note, standard chatbots are "all talk and no action." They are engines of prediction, trained to guess the next word in a sentence based on frozen knowledge from the past. They can summarize a meeting or write a poem, but they are fundamentally passive observers that cannot touch your business operations.

The Digital Co-Worker is different because it is agentic. It is defined not by what it says, but by its ability to take actions autonomously on a person's behalf. When you give a chatbot a task, it tells you how to do it. When you give a Digital Co-Worker a task, it does it. It acts as an "autonomous teammate," capable of breaking down a high-level goal (like "review all pending orders and expedite shipping for anything delayed by more than two days") into a series of concrete steps and executing them without needing you to hold its hand.

This distinction changes the return on investment entirely. A chatbot is a tool for drafting text; a Digital Co-Worker is a tool for finishing jobs. It doesn't just help you draft an email to a client; it finds the client in the database, checks their order status, drafts the response, and with your permission, sends it. It moves beyond conversation into orchestration, bridging the gap between your intent and the complex reality of your database transactions.

The Co-Worker's "Glass Box": A Look Inside the HATEOAS State Machine

The "AI Co-Worker" operates by acting as a "digital human," using the application's REST Level 3 (HATEOAS) API as its "invisible UI." The entire process is driven by a built-in State Machine (SM). When a prompt is submitted, the SM's "heartbeat" processor wakes up. Its only "worldview" is the HATEOAS API response. It uses a fast, lightweight LLM (like Gemini Flash) to read the _links (the "buttons") and hints (the "tooltips") to decide the next logical step. As it works, it "makes notes" in its state_array, which serves as both its "memory" and a perfect, unchangeable audit log. This is how it auto-corrects: if an API call fails, the API returns the error with the _schema, which is just the next "note" in the log, allowing the AI to build a correct query in the next iteration.

This "glass box" model is inherently secure. The HATEOAS API is not a static catalog; it is "security-trimmed" by the server before the AI ever sees it. The app's engine uses declarative rules (like SACR) to filter the data and remove links to any actions the user isn't allowed to perform. If you don't have permission to "Approve" an order, the Digital Co-Worker will not see an "approve" link. The guardrails are not a suggestion; they are an architectural-level boundary, making it impossible for the AI to go rogue.

This architecture also enables true, durable autonomy. The "heartbeat" that runs the SM is designed to handle tasks that last for months. A user can "pause" or "resume" an agent simply by issuing a new prompt, as the AI can see and follow the pause link on its own "task" resource. Because the AI can also discover links to create new prompts (e.g., rel: "create_new_prompt" in the menu), a "smart" agent can decompose a complex prompt ("review 500 contracts") into 500 "child" tasks, which the heartbeat then patiently executes in parallel.

Beyond the Database: The Universal Interface

The power of the Digital Co-Worker extends far beyond the SQL database. The same "blueprints" (data controllers) that define your customer tables can also define "API Entities" (virtual tables that connect to external systems like SharePoint, Google Drive, or third-party CRMs).

To the AI, these external sources look exactly like the rest of the "invisible UI." It doesn't need to learn a new API, manage complex keys, or navigate different security protocols. It simply follows a link to "Documents" or "Spreadsheets" in its menu, and the application's engine handles the complex connection logic behind the scenes, presenting the external data as just another set of rows and actions.

This solves the single hardest problem in enterprise AI: secure access to unstructured data. Just like with the database, the system applies declarative security rules to these external sources. If a user is only allowed to see SharePoint files they created, the Digital Co-Worker will only discover those specific files. It enables a secure, federated search and action capability (allowing the AI to "read" a contract PDF and "update" a database record in one smooth motion) without ever exposing the organization's entire document repository to a "black box."

The Future is Built-In: Rapid Agent Development

The age of the expensive, brittle "Genius" AI is ending. The age of the secure, durable "Digital Co-Worker" has arrived. We believe that building a Digital Workforce shouldn't require a team of data scientists and six months of integration; it should be a standard feature of your application platform.

In our upcoming releases, we are delivering the tools to make this a reality. By simply building your application as you always have, you will be simultaneously architecting the secure, HATEOAS-driven environment where your Digital Co-Workers will live and work, powered by the Axiom Engine. Your database is ready to talk. Stay tuned for our updated roadmap - the workforce is coming under the full control and permission of the human user.

Labels: AI, RESTful
Monday, August 7, 2023PrintSubscribe
Browser-Based Installer in App Studio

Code On Time release 8.9.30.0 moves the installation of the code generation library from the Windows-based executable to the browser-based App Studio. The studio homepage performs the check for updates when Code On Time starts on the developer’s workstation. The code generation library files are downloaded automatically. Developers are prompted to install the update when the new product releases become available.

Learn about the new Installer in the App Studio.
image1.png

App Studio home page will display a prompt when the new product update is available. Developers can opt to continue using the current version of Code On Time or proceed with the installation.

App Studio offers the new option to generate the HTML template for the active form. Select the “more” menu in the top toolbar of the App Studio and choose the Form Template command. You will see a prompt to save the HTML file with the corresponding form layout. The layout will be configured to render when the window matches the width of the selected device. Make sure to choose the right device and experiment with device orientation.

image2.png

The Form Template command will create the form layout for the active form or survey. The prompt to save the HTML file will appear when the command is selected while a form is the top-most view in the app.

The following features and enhancements are included in the release:

  • (App Studio) The 'Form Template' command in the studio context menu will create an HTML file with the template of the active form.
  • (Touch UI) The radio button list and checkbox list with horizontal scrolling and cascading dependency on another field will not cause the fields below to shift while the values are fetched in response to the changed parent field.
  • (App Gen) A tap on the product activation code will send the default browser to https://my.codeontime.com with "studio parameters". Developers must sign in with their credentials to activate the product.
  • (App Gen) Up to 10 attempts to access the started app are performed before the default browser is launched at the app URL. This eliminates the “site not found” error displayed by the browsers while the app is being configured for the first time to run with Microsoft IIS Express.
  • (App Gen) The news feed has been removed from the start page of the app generator. The newsfeed is now displayed in the App Studio application that will be launched when Code On Time is started on the workstation.
  • (App Gen) The news feed area provides the links to the v9 roadmap.
  • (App Gen) The installation of the code generation library is now performed by the App Studio application. The app generator will hide when the installation of the code generation library and product updates are performed. The app generator will reappear when the updates are completed.
  • (Touch UI) Content pages preserve the scroll top with the new $app.touch.contentScrollTip('save|restore') API.
  • (Touch UI) Notification toasts appear above the active progress screen.
  • (Touch UI) The width of the progress text depends on the view port of the device.
  • (RESTful) The binary parameter values can be specified in multipart/form-data payload in the custom actions of the RESTful API. The name of the parameter is specified as "parameters.PARAM_NAME". The value of the parameter is set to file://request/FILE_NAME by the RESTful API Engine where the FILE_NAME is the name of the file. Custom business rules can fetch the binary value from HttpContext.Current.Request.Files by using the value of the FILE_NAME as file index.
  • (RESTful) An improved detection of the invalid link name specified in the 'hypermedia' option.
  • (RESTful) The action ID specified in the path with the POST method will trigger the action identification on collections.
  • (RESTful) The arguments in the path are validated against the primary key fields if the target is the singleton object.
  • (Touch UI) The "cancel" icon on the form toolbar will call the _cancelCallback property of the dataview if specified. Otherwise the navigation will return one step back.
  • (App Gen) Library downloader included the builderVersion key into the studio.json exchange file. The builder version is used to install the code generation from App Studio.
  • (App Gen) Metadata builder now reports errors when the data provider is not able to return the requested information. Metadata builder queries the database to find information about data types, reserved words, tables, columns, relationships, etc. On rare occasions an exception may be raised if the database server is missing some configuration settings, which makes it impossible to fetch the metadata.
Our next goal is to deliver the hierarchy of the project settings directly in the live apps. The new Properties Window and Project Explorer will make it easy to configure the apps.
Continue to App Studio and SSO