From Schema to Live API in 5 Minutes with Resources.do

In modern software development, the loop is familiar: define a data model, build the backend logic, write the API endpoints, create the documentation, and then repeat for the next data model. This process, while foundational, is filled with repetitive boilerplate code for creating, reading, updating, and deleting (CRUD) data. It's time-consuming, error-prone, and distracts developers from building features that deliver unique business value.

What if you could skip the boilerplate entirely? What if you could define your structured data and have a secure, scalable, and fully documented REST API instantly appear?

Welcome to Resources.do. We empower you to treat your core business objects as code. This step-by-step tutorial will show you how to go from a simple data schema to a live, production-ready API in less than five minutes.

The Goal: A 'Customer' Data Model

Every business has customers. Let's start by defining what a Customer object looks like. We need to store their name, email, company, and status. A customer can also have multiple orders. The final data object we want to manage should look something like this:

{
  "id": "cus_1a2b3c4d5e",
  "name": "ACME Corporation",
  "email": "contact@acme.com",
  "company": "ACME Inc.",
  "status": "active",
  "createdAt": "2023-10-27T10:00:00Z",
  "orders": [
    {
      "id": "ord_6f7g8h9i0j",
      "amount": 499.99,
      "status": "shipped",
      "createdAt": "2023-10-28T14:30:00Z"
    }
  ]
}

Traditionally, this definition would live in a design document or a wiki, waiting for a backend engineer to translate it into database tables, models, controllers, and routes. Let's do it the Resources.do way.

Step 1: Define Your 'Resource'

In Resources.do, a data model like Customer is called a Resource. A Resource is the blueprint—the single source of truth—for a structured data object. You can define it using a simple, intuitive interface or directly as code.

Here's how we define our Customer Resource:

• Resource Name: Customer
• Fields:
  • name: Text (Required)
  • email: Email (Required, Unique)
  • company: Text
  • status: Select from active, inactive, trial

This simple definition provides everything the system needs: field names, data types, and validation rules (e.g., email must be a valid email format and unique across all customers).

Step 2: Save and Watch the Magic Happen

Once you save your Customer Resource definition, Resources.do instantly gets to work. There is no "deploy" button or compilation step. In the background, we automatically provision:

• A secure data store for your Customer objects.
• A versioned, RESTful API endpoint.
• Auto-generated API documentation.

Your API is now live. Seriously, that's it. Your endpoint is immediately available at a predictable URL, like https://api.resources.do/v1/customers.

Step 3: Interact With Your Live API

Now that your API exists, you can immediately perform all CRUD operations. Let's use cURL to test it out.

Create a New Customer (POST)

Send a POST request with your data to the /customers endpoint.

curl -X POST https://api.resources.do/v1/customers \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Global Tech Inc.",
    "email": "hello@globaltech.com",
    "company": "Global Tech",
    "status": "active"
  }'

The API will return the newly created object, complete with a unique id and createdAt timestamp.

Retrieve All Customers (GET)

Send a GET request to see a list of all your customers.

curl -X GET https://api.resources.do/v1/customers \
  -H "Authorization: Bearer YOUR_API_KEY"

Update a Customer (PUT)

Need to change a customer's status? Just PUT the new data to their specific URL using their id.

curl -X PUT https://api.resources.do/v1/customers/cus_1a2b3c4d5e \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "status": "inactive"
  }'

Bonus Step: Establishing Relationships

Our initial model mentioned that a Customer can have Orders. With Resources.do, linking data is just as easy.

1. Create an Order Resource: Define another Resource named Order with fields like amount (Number) and status (Select from processing, shipped, cancelled).
2. Define the Relationship: In your Customer Resource settings, add a hasMany relationship to the Order Resource.

Instantly, your API becomes even more powerful. You can now fetch all orders associated with a specific customer through a nested endpoint:

curl -X GET https://api.resources.do/v1/customers/cus_1a2b3c4d5e/orders \
  -H "Authorization: Bearer YOUR_API_KEY"

This single relationship definition saves hours of coding custom controller logic and complex database joins.

Why This is a Game-Changer: The Power of Business-as-Code

By defining your data models in a centralized, code-driven platform, you unlock enormous benefits:

• Unified Source of Truth: No more confusion between what's in the code, the database, and the documentation. The Resource definition is the truth.
• Incredible Speed: Go from idea to a working API in minutes, not days. Empower your frontend and mobile teams to work in parallel without waiting for the backend.
• Built-in Consistency: Validation rules and data types are enforced at the API level, ensuring data integrity across your entire ecosystem.
• Focus on What Matters: Stop rewriting the same CRUD logic. Focus your engineering talent on building the unique business logic that differentiates your product.

Ready to stop building boilerplate and start building your business?

Sign up for Resources.do today and turn your structured data into live APIs instantly.