It's unreliable, unstable, poorly documented, and yet every manager wants to use it because hey Facebook are a big company their Api must be great right?
Jira's can be very unwieldy. It is a hard one to google answers for and the Python interface is practically undocumented. It's seems to be often out-performed by the site itself.
Ive been using sports API's for side projects this year and found google-fit api the worst. The problem is that it was conceptually different, based on a timeline, and lower level while the other API's were based on individual sessions
Hmmm... Anything enteprisey. I once had to interop with Viacess-Orca RiGHTv IPTV/DRM clusterfuck, and wouldn't recommend anyone to get remotely close. Not just to that, but to anything SOAP.
Then, maybe, PayPal's NVP APIs. Quite a mess (although, I guess, I can understand why it's that way), with docs not really covering the fine details, esp. all the possible failures.
An system used for IPTV services by one of ISPs (a large telco) I've worked for. Basically, a giant piece of Java EE that strives to make everyone's life harder. Consumers get all the niceties of DRM, service provides get fun time trying to tie it with their accounting systems (that's what I had to do) and trying to figure out when it breaks, etc.
Seconded. To be fair, though, it's often not the API itself but the mapping and strange restrictions tied into access to it. Also, the often missing documentation of what is mapped to where, and why. I'll never touch it again!
The old Microsoft Crypto API (the newer one is better, but still bad)
It's been a few years, but from memory:
IIRC you could e.g. install new keys, but not quite list them (somehow only almost), and you couldn't remove them again.
Amusingly you could also tell the API was developed by three different people, who preferred different API styles (I remember one was fond of callbacks, the others apparently not so much). Reading the documentation was pretty funny because you got pretty good at spotting which functions had been created by Alice, Bob or Charlie. That was the only thing that was fun about it :-)
I'm not a fan of Steam's API. Mainly, y issue is that it is very limited. I had to use Python and Beautiful Soup to extract the data out of webpages for a project recently
Not exactly the best way to control a network device. But it is what we have.
Plus, every machine tries to do something different with the non-standard stuff.
And different parts of the APIs (called MIBs) from the same vendor follow different reference conventions, so you end up asking a lot of (mostly useless) data to be able to change something from up to down.
Avoid it if you can and use something simpler, like sshing to the device.
WebRTC: There's simply too much to configure and the modularization is also exaggerated.
WinAPI: Because of compatibility some old API procedures with ugly designs have to remain, for example CallWndProc. Bonus: WinAPI is Pascal calling convention based (__stdcall vs __cdecl).
Unity Engine: Because pascal case sucks (I consider CamelCase for C# master race).
Webpack/Gulp: again the same clause of WebRTC but ‘parenthesized’/‘bracketized’
Most market exchanges, more specifically CBOE (Chicago Board Options Exchange). They use FIX Protocol for their API but they don't follow their own spec and so it is just guessing as what they actually want.
34 comments
[ 2.6 ms ] story [ 69.7 ms ] threadIt's unreliable, unstable, poorly documented, and yet every manager wants to use it because hey Facebook are a big company their Api must be great right?
Then, maybe, PayPal's NVP APIs. Quite a mess (although, I guess, I can understand why it's that way), with docs not really covering the fine details, esp. all the possible failures.
a what?
It's been a few years, but from memory:
IIRC you could e.g. install new keys, but not quite list them (somehow only almost), and you couldn't remove them again.
Amusingly you could also tell the API was developed by three different people, who preferred different API styles (I remember one was fond of callbacks, the others apparently not so much). Reading the documentation was pretty funny because you got pretty good at spotting which functions had been created by Alice, Bob or Charlie. That was the only thing that was fun about it :-)
Not exactly the best way to control a network device. But it is what we have.
Plus, every machine tries to do something different with the non-standard stuff. And different parts of the APIs (called MIBs) from the same vendor follow different reference conventions, so you end up asking a lot of (mostly useless) data to be able to change something from up to down.
Avoid it if you can and use something simpler, like sshing to the device.
Didn't know it could take so much code for polling simple data for IDs.
... because you're talking about that Wordperfect 5.0 with blue screen on a text terminal, right?
I knew you could do some mail merge stuff, but nothing more.
Thanks!
WinAPI: Because of compatibility some old API procedures with ugly designs have to remain, for example CallWndProc. Bonus: WinAPI is Pascal calling convention based (__stdcall vs __cdecl).
Unity Engine: Because pascal case sucks (I consider CamelCase for C# master race).
Webpack/Gulp: again the same clause of WebRTC but ‘parenthesized’/‘bracketized’
http://reaxml.realestate.com.au/docs/reaxml1-xml-format.html
Its an xml format for uploading property listings. Came with a dtd but was hard to really fathom out which combinations are valid.