Fuck (some of) you backend developers who think regurgitating JSON makes for a good API.

"It's all in JSON. iOS can read JSON, right?"
A well-trained simian can read JSON, still doesn't mean it can do something with it. Your shitty API could be spitting out fucking ancient Egyptian for all I care, just make it be the same ancient Egyptian everywhere!

Don't create one endpoint that spits out the URL for the next endpoint (completely different domain, completely different path structure). Are you fucking kidding me?

As if that wasn't enough, endpoints receive data structured in one way, but return results in another!! "It's all JSON", but it's still dong.

How do I abstract that, you piece of shit? Now I have to write ever so slightly different code in multiple places instead of writing it only once.

How the fuck do I even model that in a database?

Have a crash course on implementing APIs on the client side and only come back when you're done.


  • 6
    Has nothing to do with json or backend development, just bad (or inexperienced) developers.
  • 0
    I know. Just had to put characters in my story.
  • 1
    You would have hated the first API I wrote when I started in my first company :D
  • 1
    @botti yeah, I'd probably hate you too back then LOL
  • 0
    @relentlessCoder no no

    In one endpoint a "Product" object is nested into another object and has three other nested objects
    In another endpoint, it has different properties and no child objects

    It's still all JSON
    But unusable
    Unless I model two Product classes
    But how how does the client app know which is the right one to use in which occasion?
  • 0
    @relentlessCoder They are not identical in the backend, but they still represent the same product. The product simply mutates during the checkout process.

    Still the client app should be agnostic about it. Once you introduce a type there, you'll have to implement business logic in the client app and that's bad. Very bad.
Add Comment