Live data from Hacker News

The Worst API Ever Made?

mollyrocket.com

1–10 of 82 posts

Re: The Worst API Ever Made?

#2
"ALWAYS start by writing some code as if you were a user trying to do the thing that the API is supposed to do."

It still amazes me how many times junior devs ignore this. They will spend a lot of time walking through the UX scenarios, mocking it up, etc. But when designing the API layer, they just start creating end points instead of focusing on the "DX" scenarios (developer experience, not theirs, but devs using the API).

I remember reading Cwalina's "Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries" and really learning what that means. It is a book focused on .NET but I wish many of my colleagues in the open source world would get over that and just read it. It would change their view on API design. And that is just the first chapter.

Re: The Worst API Ever Made?

#3
"The API is simple because the problem it’s solving is trivial."

I beg to differ -- as ridiculous as the API interface may be, the problem it's solving is most certainly not even close to being trivial. High-performance logging for something as low-level as the thread scheduler is not something you can write in your sleep.

Re: The Worst API Ever Made?

#4

"The API is simple because the problem it’s solving is trivial." I beg to differ -- as ridiculous as the API interface may be, the problem it's solving is most certainly not even close to being trivial. High-performance logging for something as low-level as the thread scheduler is not something you can write in your sleep.

Well, the API in question (which I've used, and it was indeed an unpleasant experience) might not be solving something trivial, but it's certainly not well designed.

My all-time worse API is SetupAPI, which despite its name is how you get access to USB devices on Windows. It's . . . pretty miserable. Runner-up is the COM-based stuff that manages the Windows firewall, which is not well specified and has 'interesting' timing issues.

I have mercifully lost most of my memory of the Java stuff I was doing 15 years ago. That stuff made me hate life.

Re: The Worst API Ever Made?

#5

"ALWAYS start by writing some code as if you were a user trying to do the thing that the API is supposed to do." It still amazes me how many times junior devs ignore this. They will spend a lot of time walking through the UX scenarios, mocking it up, etc. But when designing the API layer, they just start creating end points instead of focusing on the "DX" scenarios (developer experience, not theirs, but devs using th…

The second edition of the Framework Design Guidelines book was written in 2008 and seems (from a 10 minute browse of the first chapter) to be pretty up to date still.

It's ISBN 9780321545671 if anyone's looking for it (it's on Safari Books Online, too)

Re: The Worst API Ever Made?

#7

"ALWAYS start by writing some code as if you were a user trying to do the thing that the API is supposed to do." It still amazes me how many times junior devs ignore this. They will spend a lot of time walking through the UX scenarios, mocking it up, etc. But when designing the API layer, they just start creating end points instead of focusing on the "DX" scenarios (developer experience, not theirs, but devs using th…

The second edition of the Framework Design Guidelines book was written in 2008 and seems (from a 10 minute browse of the first chapter) to be pretty up to date still. It's ISBN 9780321545671 if anyone's looking for it (it's on Safari Books Online, too)

First chapter is included in the free preview: http://www.amazon.com/Framework-Design-Guidelines-Convention...

Re: The Worst API Ever Made?

#9
I thought the standard way to use ETW is by generating code from a manifest file with Message Compiler. Presumably it takes care of all this boilerplate? You're right though, that's a weird API. It'd be interesting to learn the process behind its design.

Re: The Worst API Ever Made?

#10
post #4

"The API is simple because the problem it’s solving is trivial." I beg to differ -- as ridiculous as the API interface may be, the problem it's solving is most certainly not even close to being trivial. High-performance logging for something as low-level as the thread scheduler is not something you can write in your sleep.

Well, the API in question (which I've used, and it was indeed an unpleasant experience) might not be solving something trivial , but it's certainly not well designed. My all-time worse API is SetupAPI, which despite its name is how you get access to USB devices on Windows. It's . . . pretty miserable. Runner-up is the COM-based stuff that manages the Windows firewall, which is not well specified and has 'interesting'…

My award goes to Extended MAPI. It took me weeks of trial and error just to read and send email messages through an Exchange Server. I remember people were selling 3rd party wrappers for the API, because it was so horrible.
Post reply on HN