Mind Dump, Tech And Life Blog
written by Ivan Alenko
published under license Attribution-ShareAlike 4.0 International (CC BY-SA 4.0)copy! share!
posted at 15. Aug '19
last updated at 16. Aug '19

How Not to Create REST API (true story)

I currently work as a front-end developer and there is one special project. Project with horrible API. Horrible enough so I totally hate it and wish it died.

So, how to create horrible API? (I’m exaggerating a bit)

1. Ignore CRUD

CRUD (create, read, update, delete….and list) is for weak. Create and name an endpoint as whatever is currently needed. Logic and struture and rememberality is for weak.

Also provide only listing of data, not read/search by ID. We need to keep complexity on front-end at least O(n).





2. Fuck Stable Responses

As a backend developer is your duty to break JSON which is returned to front-end client randomly and only slightly, so nobody notices right away.

Versioning of API? Hell no. Trying to keep backwards compatibility? No, just rename that field and they surely will handle that.

3. Cooperation With Front-end Team Is for Children

Do not cooperate with peasants from front-end team. They are weak and as creating UI is easy, they don’t have anything to do. Therefore they can find out about changes once their end-to-end tests start to fail. Or if they don’t have a test for that, somebody will surely complain…to them.

4. Do Not Keep Documentation

Make jokes and silently refuse to provide reference of API to front-end developers. If you have something, keep it outdated of course. Keep at least three versions of outdated documentation on five places. Guessing with curl and looking into the back-end code or back-end tests is the only true way to see for front-end guys what an endpoint does. Sometimes they can ask me too.

They keep bothering me and ask for Swagger and examples. But…hell no. That would be too easy.

5. Front-end Team Should Do The Work

Front-end should keep with data changes and getting all data from various endpoints. As API gets older, only some data will be used from one endpoint, some from other.

Do not provide GraphQL. Guys from front-end need to fetch everything in multiple requests and of course transform data and try to have at least some stable data model.

6. Waste Time and Confuse

Write integration tests for back-end, but do not test data, only something…perhaps HTTP status codes. This way you can ensure your bugs will propagate to end-to-end tests in front-end and guys will have to spend couple of hours looking where the problem is. But at the end they’ll find out it’s one back-end microservice.


While I understand back-end team is very busy, but after one year I’m starting to get fucking angry. In the end I don’t care. I have shitload of empathy, but I need to care about myself too. I care about my work not being unnecessary hard and pointless. That is why I’m a software developer. I just want to live and develop as full as I can!

Add Comment