Software engineer, musician, and writer. Building products, creating music, and sharing knowledge.
HTTP status codes are one of the most powerful communication tools available in an API. They provide an immediate, standardized way to convey the outcome of a request without requiring the client to inspect the payload. Despite this, many APIs misuse or underuse status codes, reducing them to generic success
I do not know if I am getting too old or if it just took too long to hit me, but your career, and sometimes your life, often depends entirely on third parties. It does not matter how good you are at what you do. It does not matter how
Last year marked the final season of a Netflix series I loved: Stranger Things . The 80s nostalgia, the music, the kids on bicycles. It all mirrored my own experience growing up in the mid and late-90s. It hit me hard, but it also made me realize I missed something
Public service should be a vocation, a temporary chapter where you bring outside skills, professional independence, and an independent livelihood to the table. But across Latin America, and acutely in Venezuela, a broken system has twisted it into an emergency employment plan. It creates a dangerous class of people: "
Every day we are bombarded with petabytes of information. Not only on the internet and social media keeping up with the world news and latest trends and memes and, lately, we all must keep up with the constantly evolving GenAI world that has taken over the world. There's
If you haven't been following my blog and just stumbled upon this post, this is the 6th article on my series about designing REST APIs, you can read the rest here . If, on the other hand you've been following and you like what you've
When people talk about REST, they often focus on surface level characteristics: URLs that look clean, JSON payloads, and HTTP verbs used “correctly”. While these elements are visible and important, they are not what makes an API RESTful and it’s not what REST is all about.
A few years ago I wrote a blog post titled “My take on microservices”. I cannot believe it has been almost a decade, nine years to be precise, since I published it. It is still accessible on my old blog via this link if you want to read
This past week, as the mythical May 4th approached us, I was chatting about Star Wars with one of those lifelong friends you talk to from time to time but the bond feels as if we were still living next to each other. We were remembering how we used to
When a chapter finishes, another one starts. I'm here now to talk about the one I'm closing. Last Friday was my last day at BCG... When I joined BCG, it was out of boredom and an everlasting feeling that I was stuck, and I was. During
The two, often cited, most difficult things in Computer Science are cache invalidation and naming things . I'm afraid both are unavoidable when building web applications and APIs are also part of web applications. In this post we will focus on the later as resource names are not internal
As a Venezuelan living abroad, there are dates on the calendar that carry weight long after they pass. For many of us, April 11 is one of those dates. Whether you were impacted by what happened, lost someone or were injured in 2002, April 11th left deep scars in the
Resources do not come from databases, frameworks, or other existing ways of modeling data. They come from requirements . More specifically, they come from understanding what users want to do and what concepts they talk about when describing their needs and identifying the different roles. The best way, in my experience,
Abstract This document proposes REST++ , an evolution of the Representational State Transfer architectural style, designed to address practical shortcomings observed in large-scale API implementations. REST++ preserves the general philosophy of resource-oriented communication while relaxing several constraints that have proven difficult to apply consistently in modern distributed high-performing
One of the most significant mental shifts in API design is moving away from database-driven thinking. We often start by designing APIs around tables, schemas, or ORM models. While this approach may feel natural, it leads to brittle APIs that expose internal structure and limit evolution in the future.