Aquí tienes una comparación clara entre PHP/mod_harbour y el enfoque de REST API para generar HTML y manejar lógica en aplicaciones web:

---

---

📊 Comparativa: PHP / mod_harbour vs REST API

Aspecto	PHP	mod_harbour	REST API
Modelo de programación	Markup-first: se construye una página HTML y se inserta código dinámico donde se necesita.	PRG-first: se construye un programa que procesa datos y al final genera HTML como salida. fivetechsupport.com	Data-first: se construyen servicios que exponen datos en JSON/XML, y el frontend (HTML/JS) consume esos datos. AWS
Generación de HTML	Directa, incrustando lógica en la misma página.	El programa Harbour genera HTML como resultado final. mod-harbour.github.io	No genera HTML directamente; entrega datos que luego el frontend transforma en vistas.
Lenguaje base	PHP (popular, multiplataforma).	Harbour (lenguaje xBase, orientado a lógica empresarial).	Independiente: puede implementarse en cualquier lenguaje (Node.js, Python, Java, etc.).
Acoplamiento frontend-backend	Alto: HTML y lógica están mezclados.	Alto: el programa produce HTML completo.	Bajo: frontend y backend están separados, comunicándose vía API.
Escalabilidad	Adecuada para sitios pequeños/medianos.	Adecuada para aplicaciones que ya usan Harbour y quieren migrar a web.	Muy alta: ideal para arquitecturas modernas, microservicios y aplicaciones distribuidas.
Flexibilidad	Limitada por la mezcla de lógica y presentación.	Limitada al ecosistema Harbour.	Muy flexible: frontend puede ser web, móvil, IoT, etc.

---

---

🔑 Puntos clave

• PHP/mod_harbour son más directos para generar HTML desde el servidor, útiles cuando el objetivo es mostrar páginas dinámicas rápidamente.
• REST API es más moderno y desacoplado: el backend solo entrega datos, y el frontend decide cómo mostrarlos. Esto facilita escalar y mantener aplicaciones grandes.
• Si tu proyecto es pequeño y necesitas rapidez, PHP/mod_harbour son prácticos.
• Si buscas integración con múltiples clientes (web, móvil, servicios externos), REST API es la mejor opción.

Sí, tanto PHP como mod_harbour pueden usarse para implementar un REST API, aunque su enfoque natural es distinto. Te resumo cómo se vería cada caso y qué implicaciones tiene:

---

---

🚀 Usar PHP como REST API

• PHP tiene librerías y frameworks (Slim, Lumen, Laravel) que facilitan crear endpoints REST.
• Ejemplo sencillo en PHP:
  Code (php): Select all Collapse

  <?php
  header("Content-Type: application/json");
  
  $data = ["mensaje" => "Hola desde PHP REST API"];
  echo json_encode($data);
  ?>

• El cliente (frontend o app móvil) consumiría este JSON y lo transformaría en HTML o UI.

---

---

⚙️ Usar mod_harbour como REST API

• mod_harbour permite escribir programas en Harbour que corren dentro de Apache.
• En vez de generar directamente HTML, puedes hacer que el programa devuelva JSON:
  Code (harbour): Select all Collapse

  function Main()
     local hData := {=>}
     hData["mensaje"] := "Hola desde mod_harbour REST API"
     ? hb_jsonEncode( hData )
  return nil

• Así, el servidor entrega datos estructurados y el frontend decide cómo mostrarlos.

---

---

🔑 Diferencia clave

• PHP/mod_harbour tradicional → generan HTML directamente en el servidor.
• PHP/mod_harbour como REST API → generan JSON/XML, desacoplando la lógica del frontend.
• Esto te permite usar Harbour o PHP como backend moderno, integrable con apps web, móviles o microservicios.

---

---

📌 Conclusión

Si usas PHP o mod_harbour como REST API, básicamente los conviertes en proveedores de datos en lugar de generadores de páginas. Esto te da la misma ventaja que cualquier backend moderno: escalabilidad, separación de responsabilidades y posibilidad de reutilizar el mismo servicio en múltiples clientes.

Hello Jsonsson,

When moving from classic Harbour to the web, we were faced with the question of how to evolve our existing application without rewriting everything. For us, one requirement was clear from the beginning: our existing DBF structure and Harbour business logic had to remain in place. If we were going to rewrite everything in another language anyway, we might as well have switched completely to PHP or another backend.

So our goal was not to replace Harbour, but to make Harbour web-capable.

The first step turned out to be surprisingly simple: Harbour should receive JSON over HTTP and return JSON. Nothing more.

In practical terms, this means a small HTTP server (in our case C + Harbour) that accepts a request, processes the JSON body using hb_jsonDecode(), executes the existing business logic, and returns the result using hb_jsonEncode(). All DBF-based logic remains unchanged inside PRG files. No ORM layer, no migration to SQL, no mandatory framework.

The key mindset shift was not MVC or REST, but this:

Before: The PRG directly generated HTML.

Now: The PRG generates structured data (JSON). The frontend decides how that data is rendered.

This separation allows us to keep the existing Harbour/DBF world intact while still connecting modern web frontends.

In many discussions, people immediately talk about REST, resource orientation, or idempotency. These are important concepts, but they are not the first step. The first step is to think of Harbour as a data service. Once that works, the architecture can gradually be refined — for example, with cleaner endpoints, proper HTTP status codes, or resource-oriented URLs.

For us, this was not an academic architecture exercise, but a pragmatic solution: existing DBF data, existing PRG logic, and a new web interface. That is what makes this approach interesting for many Harbour developers — you do not have to relearn everything or rebuild your system from scratch. You only have to rethink the output layer.

Best regards, Otto

REST vs. RPC — Or Both? A Practical Perspective for Single Developers

REST

REST = Representational State Transfer

• “Representational” → a representation (for example, JSON)
• “State” → state
• “Transfer” → transfer

In simple terms, this means:

Transferring the state of a resource in a specific representation (for example, JSON over HTTP).

REST is not a protocol. It is an architectural style for designing web services.

RPC

RPC = Remote Procedure Call

• “Remote” → distant / over a network
• “Procedure” → procedure / function
• “Call” → invocation

It means:

A function is invoked over a network as if it were local.

So RPC is essentially:

A function call over a network.

JSON-RPC is a specific implementation of RPC that uses JSON as the data format.

Pragmatic API Design: Why a Hybrid REST/RPC Approach May Benefit Solo Developers

I asked AI:

But if we can do both, aren’t we actually at an advantage — especially from the perspective of a single developer?

Yes.
And clearly yes — especially from the perspective of a single developer.

But not for the reason many people initially assume.

🎯 The Real Advantage

If you can support both — REST-style and RPC-style — then you gain:

• Structure where it makes sense
• Flexibility where it is necessary

And that is extremely valuable for an individual developer.

🔎 Why Is This an Advantage for a Single Developer?

1️⃣ You don’t have to be dogmatic

You can do:

• GET /records/123 → clean REST
• POST /recalculateInvoice → clear RPC call

And both can coexist.

You don’t waste time forcing a complex business operation into an artificial “resource-oriented” shape just to satisfy a purist REST model.

2️⃣ You can develop pragmatically

As a solo developer, what matters most is:

• Speed
• Clarity
• Maintainability
• Control

Not:
“Is this 100% REST-pure?”

If something is logically a function, then it’s perfectly fine to treat it as one.

3️⃣ You can grow step by step

You can evolve in phases:

• Phase 1 → JSON in / JSON out
• Phase 2 → Make selected endpoints resource-oriented
• Phase 3 → Separate HTTP status codes more strictly

Without a big bang rewrite.

📊 Strict REST Dogmatism Would Have Downsides

If you try to make everything strictly REST:

• More URL design effort
• More structural planning
• More consistency overhead
• More cognitive load

That may make sense for a team of 10 developers.
For a single developer, it often becomes unnecessary overhead.

🔥 Your Hybrid Approach Is Realistic

You have:

• REST for simple, clearly defined resources
• RPC for complex business operations
• A proxy for infrastructure concerns
• A microservice for business logic

That’s not messy.
That’s pragmatic.

🎯 The Strategic Advantage

As a single developer, you have:

• Full control over all layers
• No coordination overhead
• No API committees
• No architecture politics

You can afford to be flexible.

🧠 The Only Real Downside

A hybrid model can become problematic if:

• Many external developers consume your API
• You publish and formally document it
• Versioning becomes critical

But for internal or controlled projects?
It’s not a problem.

📌 Honest Conclusion

Yes, you are at an advantage.

Not because you are “more modern.”
But because you consciously use architecture as a tool — not as an ideology.

🔎 What does REST-style mean?

REST-style means:

You think in resources (things), not in functions.

You manipulate those resources using HTTP methods.

Example (REST-style)

GET    /records/123
POST   /records
PUT    /records/123
DELETE /records/123

Here:

• /records/123 is a resource
• GET means read
• POST means create
• PUT means update
• DELETE means remove

You are not calling a function.
You are interacting with a thing.

REST is resource-oriented.

🔎 What does RPC-style mean?

RPC means:

You think in functions (actions), not in resources.

You call a named operation remotely.

Example (RPC-style)

POST /addRecord
POST /recalculateInvoice
POST /validateUser

The URL represents a procedure, not a resource.

You are saying:

Execute this function.

RPC is action-oriented.

📊 Simple Comparison

🧠 Concrete Example with the Same Goal

Imagine you want to get record 123.

REST-style

GET /records/123

Very natural:
“Give me record 123.”

RPC-style

POST /getRecord
{
  "id": 123
}

Also valid, just different mindset:
“Execute the function getRecord with id 123.”

🔥 Why Both Exist

REST is great when:

• You deal with clear entities (users, orders, products)
• You want predictable structure
• You expose public APIs

RPC is great when:

• You perform business operations
• You run complex logic
• The operation doesn’t map cleanly to a “thing”

Example:

POST /recalculateAnnualTax

That’s not really a resource.
That’s clearly a function.

🎯 In Your Case

You already use both:

REST-style:

GET /heartbeat
GET /getrecord

RPC-style:

POST /addrecord
POST /force401
POST /ssot_diagnostics

That’s why your architecture is hybrid.

🧩 The Key Difference in One Sentence

REST-style:

“Here is the thing.”

RPC-style:

“Run this logic.”

Asi lo hacemos con jakarta ee

   @GET
    @Path("getDataRespuestasCandidatosEmpleados") 
    @Produces({ MediaType.APPLICATION_JSON})
    public Response getData( @QueryParam("query") String query,
                             @QueryParam("page") String pageInt,
                             @QueryParam("size") String sizeInt,
                             @QueryParam("campoSort") String campoSort,
                             @QueryParam("tipoSort") String tipoSort   ) throws Exception {
        


    this.respuestasCandidatosEmpleadosMapper = new RespuestasCandidatosEmpleadosMapper(em); 
    int size = Integer.parseInt(sizeInt);
    int page =  Integer.parseInt(pageInt);
    int totalItems = 0;
    List<RespuestasCandidatosEmpleados> listRespuestasCandidatosEmpleados = this.ejecutaQuery( query,
    		                          page,
    		                          size,
    		                          campoSort,
    		                          tipoSort.equals("ASC") ) ;
    try {
        totalItems = super.getTotalItems();
    } catch (RuntimeException re) {
        totalItems = 0;
        throw re;
    }   
   
    List<RespuestasCandidatosEmpleadosDTO> respuestasCandidatosEmpleadosDTOs = new ArrayList<RespuestasCandidatosEmpleadosDTO>();
   
    respuestasCandidatosEmpleadosDTOs = this.respuestasCandidatosEmpleadosMapper.listRespuestasCandidatosEmpleadosToListRespuestasCandidatosEmpleadosDTO(listRespuestasCandidatosEmpleados);
   
    Map<String, Object> conexionMap =   new HashMap<String, Object>(); 
    conexionMap.put("datos",respuestasCandidatosEmpleadosDTOs); 
    conexionMap.put("totalRegistros", totalItems);
    conexionMap.put("token", "fake-jwt-token");

    String retorno = Utilidades.convierteJson2(conexionMap) ;
    return Response.ok().type(MediaType.APPLICATION_JSON).entity( retorno ).build();
}

We are not aware of any modern framework that natively works with DBF files. Most contemporary web frameworks assume a relational SQL database and are tightly integrated with ORM layers. For us, continuing to use our existing DBF-based business logic was a fundamental requirement. If we had to migrate the entire data layer anyway, we might as well have rewritten the system in a different stack.

From our experience, many established frameworks are primarily designed for larger teams and long-term enterprise environments. They provide strong conventions, dependency injection, ORM abstractions, layered architectures, and predefined lifecycles. This is extremely valuable in multi-developer projects where consistency and structure across teams are critical.

However, for a single-developer company, the trade-off looks different.

Frameworks typically provide:

• Consistency
• Team scalability
• Standardization
• Convention over configuration

A custom-built approach provides:

• Freedom
• Full control
• Direct proximity to business logic
• Less boilerplate
• No forced abstractions

For us, the deciding factor was not ideology (REST vs. RPC vs. framework purity), but practicality. We wanted to keep our DBF data model, preserve existing Harbour logic, and expose it over HTTP in a clean way.

In a small, controlled environment, architectural flexibility can be more valuable than strict adherence to framework conventions.

Otto.. Good morning..

Software development is designed to remain functional over time and across our generations... How can I make this viable, ensuring the client backup, technological and legal improvements, and at the same time, how to protect our heritage. The answer lies in the decision to continuously adjust our products, to the extent that: my development tool provider offers me guarantees regarding support, technological improvements, a large community, collaborations, etc..., therefore, I must make timely decisions, rewrite logic in another language, which may seem costly, but what is more costly than risking not migrating to modern technologies or languages? And as we have already experienced... THEY REPLACE US FOR BEING OBSOLETE (visually)... This topic is broad for debate and even if they are one-person companies, our services are used by hundreds of clients who cannot be left stranded…

My heirs and the same developers already demand to work with 'known' tools; they do not see it as a good investment to have to learn a language or tool that is not known in their social environments, universities, forums, communities, etc.

10 or 15 years ago it was unthinkable that AI could be part of our development team... It would be interesting to see the proportion of time we can gain by doing it 'by hand' or with the help of AI, in tasks of migrating or new developments with another language or other technologies... Example... it could go from 5 years to 3 or 2 years... ?

Now... when software development is an art, which is so gratifying to us, to see how I can create works of art, without the obstacle of my 'brush' being suitable for this canvas. What better way to retire than creating modern works of art...

We would have wanted the Fivewin community and the Harbour community… that Fivetech as the company that currently supports us… would take us to the web environment (frontEnd) with a framework on the level of (React, Vue, Angular), as it was at the time with a very strong solution, when it became necessary to migrate from a text environment to a graphical one… Now what we expect for the backEnd, a Harbour that has the support of the entire community, where clearly it has an easier path to reach the level of other products, but it must improve in terms of support

Jonsson, If the narrative about agentic coding and “anti-gravity productivity” really turns out to be true, then the question for the next generation will not primarily be:

“Who knows framework X?”

but rather:

“Who can design systems that meaningfully leverage AI agents?”

That is a different level of competence.

It shifts the focus from tool familiarity to architectural thinking.

Our Architectural Approach

We are not resisting modernization.
We are modernizing under control.

For the frontend, today’s web standards (HTML, CSS, JavaScript) are universally understood and increasingly supported by AI tools. Generating, maintaining, and evolving web interfaces is no longer the bottleneck it once was. A clean JSON API is sufficient to support any modern frontend stack.

For the backend, we believe a lightweight Harbour microservice layer is ideal.
It provides:

• Clear HTTP routing
• JSON input/output
• Explicit status handling
• Logging and traceability
• Full source ownership

On top of this microservice base, anyone can implement what they need — DBF, SQL, external APIs, or other services.

We are not building a monolith.
We are building infrastructure.

Additionally, we see value in PHP as a complementary layer. There are many ecosystem components that are already mature, stable, and widely available — authentication flows, payment gateways, PDF generation, email handling, etc. It makes sense to use what is already proven instead of reinventing it.

In summary, our structure looks like this:

1. Frontend → Web standards (HTML/JS), AI-assisted if needed
2. PHP → Ecosystem glue and third-party integration
3. Harbour Microservice → Core business logic and data layer

Each layer is replaceable.
Each layer has a clear responsibility.
Each layer can evolve independently.

This is not ideology.
It is architectural resilience.

The goal is not to defend a specific technology.
The goal is to maintain control, minimize unnecessary dependencies, and ensure that the system remains adaptable over time.

If one day we decide to change the storage engine, the API remains.
If we change the frontend framework, the backend remains.
If we integrate AI agents, the clean API structure supports it.

We focus on architecture over fashion.
Best regards,
Otto