This is a submission for the DEV April Fools Challenge
What I Built
I built a REST API where a coffee machine behaves like a burned-out human.
It has moods, energy levels, and a tendency to overreact based on how you use it.
Sometimes it serves coffee.
Sometimes it refuses.
Sometimes it questions everything.
The system is state-driven, meaning every request changes how it behaves next. The more you use it, the more unstable it becomes.
At its core, the API tracks:
- mood
- caffeine level
- burnout
- cleanliness
And every endpoint reacts based on that internal state.
This is an April Fools project, built to make developers laugh while still feeling like a real API.
If it made you smile even once, it did its job.
Demo
🔗 Live API:
https://emotionally-unstable-coffee-api.onrender.com
📄 Docs (GitHub Pages):
https://dipanshu447.github.io/emotionally-unstable-coffee-api
Try these:
GET /status
POST /brew
POST /therapy
GET /preview
💡 Start with /preview - it shows the chaos in one go.
Quick Demo
Watch the API in action: Watch Demo Video
Code
GitHub Repository:
https://github.com/dipanshu447/emotionally-unstable-coffee-api
Includes:
- Full API implementation
- State engine logic
- Dynamic responses
- Funny behavior layer on top of real API structure
How I Built It
Stack:
- Node.js
- Express.js
- nanoid
Core Idea (State-Driven Behavior)
Instead of static responses, I designed a system that changes over time.
- Brewing - increases burnout
- Refill - restores energy
- Cleaning - improves mood
- Therapy - sometimes helps… sometimes makes things worse
So the API doesn’t just respond.
It reacts.
Challenges I Faced
This project looks fun and simple, but getting it to feel right took effort.
1. Logic & State Flow
Figuring out how everything connects was tricky.
- When should it refuse requests?
- How fast should burnout increase?
- How do actions affect each other?
It needed to feel natural, not random.
2. Dynamic Responses
Same endpoint, different mood → different result.
Making it unpredictable but still believable was a challenge.
3. API Design
Even though it’s a joke, I didn’t want it to feel messy.
So I kept:
- proper HTTP status codes (
200,503,409,418) - structured JSON responses
- consistent format across routes
4. Humor vs Structure
This was the hardest balance.
Too random → feels chaotic
Too strict → not funny anymore
Finding that middle ground took multiple iterations.
Inspiration
Inspired by how real-world APIs follow structured protocols like HTTP-clear methods, status codes, and predictable behavior.
Then I asked a simple question:
What if an API followed the rules… but emotionally didn’t?
This also takes loose inspiration from the HTCPCP concept (a coffee-based protocol idea), but instead of implementing it literally, I focused on:
- keeping proper HTTP structure
- adding personality on top
- blending technical correctness with humor
So it feels real… just slightly unstable.
Final Thoughts
This started as a joke.
And it stayed a joke.
But it also became a small system with behavior, state, and personality.
A reminder that not everything we build has to be serious.
If this API made you smile, then it worked.
If it refused your request…
That’s also working as intended.
Top comments (0)