Custom APIs on One Standard: Validation, Standard Errors, Fast Fixes

Every service its own rules

0:00 Custom APIs, part two. Your own code, kept on one standard whoever writes it, and a bug found, fixed and live again in seconds. In most teams, every service invents its own error format, and every client learns each one. Validation is forgotten, or copied by hand into each endpoint. Field names are guessed, and a typo is found in production. A one line fix waits for a build and a deploy.

0:27 And an AI assistant copies whatever pattern it finds. API Maker gives every API one answer format, checks each request before your code runs, types every table, and makes a save live for the very next call. Five parts. The standard answer. Validation without code. The errors you throw. Typed tables in the editor. And a real bug, fixed in seconds.

The standard answer

0:55 Every API of API Maker answers in one envelope : the generated APIs of your tables, the system APIs, and your custom APIs. On success, success is true, statusCode repeats the HTTP status, and data holds what your code returned. On failure, errors is a list. Each entry has a code and a message, and for bad data, the field and the rule that failed. The code of the first error is the HTTP status.

1:25 A client writes its error handling once, for every API you will ever add. Here is the API of this video. The mobile app of Calm Home asks for the price of a cart before checkout. Nisha opens Custom API, and clicks Add New. Basic Info holds the settings, written in TypeScript : the name, Cart Quote, its path, its method, and token access. Then two standards : a schema for the request body, and the list of messages this API may throw.

1:57 The Code tab holds one function, main. It reads the products of the cart from MongoDB, and the coupon from MariaDB, with g.sys.db. When a coupon is unknown or expired, it throws a standard error : a code and a message. Save, and the API is live. It sits under the checkout folder, with a Body chip : a schema guards its body.

Validation without code

2:23 That body schema is written in the language of your table schemas. Every field has a type. Validations refuse bad values : required, email, minimum, maximum. Conversions clean values first : trim, lower case, upper case. And an array of objects is written like the variants of a MongoDB product. One language to learn, for tables and for APIs. Now Test API opens API Testing on Cart Quote. Nisha sends a bad cart : an e-mail with no domain, a quantity of zero, and a misspelled key.

2:59 API Maker answers 400, with every problem at once : a key the schema does not know, an e-mail that is not valid, and the minimum of items.quantity. Not one line of the code ran. Messy input is cleaned before your code sees it. Spaces and capitals in the e-mail, a SKU in lower case, a coupon with spaces. The code got a clean e-mail, an upper case SKU, and the coupon WELCOME5 : a subtotal of 121.80, five percent off, 9.90 for shipping, 125.61 in all.

3:37 No parsing, no trimming, no checks in main.

The errors you throw

3:41 Business rules live in your code, and so do their errors. The coupon SPRING15 ended in March. The code throws, and API Maker writes the answer : 404, in the same envelope, with the message from the error list. Any other thrown value becomes a 500 with its stack, so even an error nobody planned keeps the shape. The standard is the same in every language API Maker runs. TypeScript throws an array.

4:09 Python raises g.Errors. PHP, C sharp, Java and Kotlin throw AmErrors. Go and Rust return a failure. A Python version of the coupon check answers 404, in the same envelope. And when Python itself fails, the stack names main.py, the line number, and the line of code. The messages of the error list are also the ones you can translate. They appear in i18N Management, in the sample of every new translation.

4:42 A caller who sends the header x-am-internationalization, with fr, gets the French message, from the same code.

Typed tables

4:50 API Maker writes your types for you. Generated Interfaces shows db-interfaces.ts : an interface for every table with a schema, here the products of MongoDB, with their nested specs and variants. A map ties each instance, database and table to its interface : twenty three tables, in six databases. types.ts declares g itself, every call and its options. Both download in one click, and the same files are in your Git repository.

5:24 In the editor, these types are live. The call names mongodb, catalog and products, so the rows are typed : after product dot, the columns of the table appear, with their types. Misspell price, and the editor underlines it before anything runs. Property prise does not exist on IProducts. Did you mean price? An AI assistant gets the same signal, from the same types. Names written as text are checked too, when the code runs.

5:53 If the code asks MongoDB for SKU in capitals, a database would quietly find nothing. API Maker refuses the query : there is no property SKU in the schema of products. The wrong name is reported, not hidden in an empty result.

A real bug

6:11 Now a real bug. The app still holds a cart with CH-LGT-009, a lamp that left the catalogue. The answer is 500 : cannot read properties of undefined, reading price. The stack lists only your code : MainSandbox.ts, line 14. And the Code tab underlines that line in red. What the code printed is one click away. Console Logs View shows the line of this call : one of two products found.

6:42 So one SKU is missing, and the code never checked. The fix is one line. If there is no product, throw a standard 404 that names the SKU. Command E sends the request with the code on screen, before it is saved : 404, product CH-LGT-009 is not sold any more. Callers still get the saved code meanwhile. Command S saves it. Changes saved. Saving is deploying. The very next call from outside gets the fixed answer.

7:15 The API lives in the database of API Maker. A save tells every server of the cluster, through Redis, to drop its copy, so each one runs the new code on its next request. No build, no image, no restart.

Why AI-written code stays on the standard

7:31 This is why code written by an AI assistant stays on the standard. The request schema runs before any code, so a forgotten check cannot let bad input in. Typed tables flag a wrong name while the code is written. There is one way to fail, so every error reaches the client in one shape. And a fix is tried on real data, then saved, in seconds. The assistant and the developer work on the same rails.

Best practices

7:59 A few habits keep it that way. Give every body and every query a schema. Throw a code and a message, with the right status. List the messages you throw in errorList, so each one can be translated. Write instance, database and table as text in each call, so rows stay typed. And to check a payload without calling the API, use is valid data for custom API.

Recap

8:25 To sum up. One envelope, for every API. Schemas that validate and clean each request. Standard errors, in every language. Typed tables, from Generated Interfaces. And a fix, live in seconds. Next, the hidden gems of custom APIs, from file uploads to caching. API Maker. Build faster, spend smarter, deliver better.