Live data from Hacker News

API Practices If You Hate Your Customers

queue.acm.org

41–50 of 258 posts

Re: API Practices If You Hate Your Customers

#41
post #39
post #24

Earlier quoted context omitted.

I really don't like your story. The junior is clearly behaving immaturely and inappropriately by CCing others and not using an appropriate tone, but your response is to... retaliate by doing the exact same thing to him? What lesson is the junior supposed to learn here? That acting that way is A-OK as long as you have seniority and are factually correct? At least the junior has the "excuse" of being a junior, but real…

>Surely there must have been a better way for you to handle this situation. The junior was in the wrong, so I think you'd agree that a correction is in order. Replying-all is one way to do such a correction. The alternative would be to force him to issue a retraction himself.

There's no need to shame people who are wrong.

Re: API Practices If You Hate Your Customers

#42
post #32

I was totally expecting to see something about using a protocol in an unexpected way, because "the protocol is not good enough". I had to work with an API where the company decided everything should return http code 200 (well, at least all 4XX errors), and give the error code in the JSON response, mixing existing 4XX errors and their own errors. When pointed out, the support answer was "we chose to give meaningful er…

This isn't the ArcGIS Server API is it?

Re: API Practices If You Hate Your Customers

#43
post #8
post #3

This article is junk. There are many reasons for not offering an API to customers. I run a small b2b app between two completely non-technical businesses. There is absolutely no need for me to have an API available to them, they’ve never asked for it and have no desire or ability to consume it. Believe it or not, there is also an expense to offering an API! An API is a product offering like anything else, and products…

I didn't downvote you but I do strongly disagree with pretty much everything you've said. > There is absolutely no need for me to have an API available to them, they’ve never asked for it and have no desire or ability to consume it. Whenever I've used "small b2b apps," especially between non-technical businesses, if you don't have it I'm not asking for it. I know how hard it is to be a solo founder or part of a very…

I get what you’re saying but I think you’re not being pragmatic enough (and perhaps being a bit developer-centric, ignoring that there are millions of people out there who run businesses that have 0 need for offering a consumable API).

You’re asking for access to the heart and soul of a company and demanding to pay the same price as a customer who asks for much less. I’m having a hard time understanding why I should pursue you as a customer when I can get the same money out of someone who is way less demanding.

Re: API Practices If You Hate Your Customers

#44
post #2

I was expecting to see two of my pet hates - returning a null array to represent no items, and returning a single object without an array to represent one item. I also once worked with an API where you had to send the data in POST format - abc=123&def=456. After much pressure from their customers, they finally relented and added an XML version of their API... where your request could look like this: abc=123&def=456 .…

There's often a semantic difference between null and empty. Like, if I'm checking the result of a batch processing job, I want to know if the job finished & resulted in an empty set, or there is simply no result yet. It's "the thing you're looking for doesn't exist" vs. "the thing you're looking for exists, but is empty."

That's fair to say I guess - but it should be accompanied by some other property to indicate a condition like that.

The API I'm thinking of though was effectively a wrapper around a database query which retrieved items.

That's what gets me about that decision you see. When you get nothing from a database, you get an empty set. The runtime was some version of .NET Framework, which by default would write an empty set as an empty array. So it wasn't even an accident - someone actually had to add extra logic to make it return null.

Re: API Practices If You Hate Your Customers

#45
post #20
post #3

This article is junk. There are many reasons for not offering an API to customers. I run a small b2b app between two completely non-technical businesses. There is absolutely no need for me to have an API available to them, they’ve never asked for it and have no desire or ability to consume it. Believe it or not, there is also an expense to offering an API! An API is a product offering like anything else, and products…

I would argue the primary benefit of having an API even if not made public is that it will encourage better architecture , design, and development making the product more maintainable over the long run. It also means you can scale if you ever do need to add a customer that wants to make use of an API. Saying not to do an API because customers don't want it is similar to not using source control because you're the onl…

An architecture is good if it is serving your business’ needs. My company makes $13 billion a year off of garbage architecture. If we completely re-engineered it to be perfect, we’d probably still make the same amount of money, it would just cost us hundreds of millions of dollars to do it (actually, we tried and wasted about $300mil).

Re: API Practices If You Hate Your Customers

#46
> An operation is idempotent if performing it multiple times yields the same result as performing it exactly once.

And then he casually offers an API that does different things on first and second call as the "good" example. If you have a "create a virtual machine" API it better create a fucking virtual machine. If I call the damn thing twice, I expect to have two VMs. If there is some sort of unique argument like create a named VM, I would expect API to throw an error if the name is already taken, no to just return like everything is normal.

And this guy is being all snarky about API design?

Re: API Practices If You Hate Your Customers

#48
post #24

Earlier quoted context omitted.

> returning a null array to represent no items, and returning a single object without an array to represent one item. This just reminded me of a long ago incident at a former employer. I worked in back-office at a hedge fund and was responsible for maintaining several APIs & services written in C++. The APIs were pretty straight forward query for object(s), get back a vector of objects. If nothing was found, you'd ge…

I really don't like your story. The junior is clearly behaving immaturely and inappropriately by CCing others and not using an appropriate tone, but your response is to... retaliate by doing the exact same thing to him? What lesson is the junior supposed to learn here? That acting that way is A-OK as long as you have seniority and are factually correct? At least the junior has the "excuse" of being a junior, but real…

It depends on the company. Often the best thing to do is fire back without escalating. With someone like that junior sending an email like that without first talking to someone is a good way to get fired or put on a PIP depending on how long they’d been with the company.

Re: API Practices If You Hate Your Customers

#49

I only ever use internal APIs at work. I've never used anyone's external APIs and am wondering if there's a whole tech ecosystem I'm missing out on. What are some commercial use cases you all have had?

A great source to learn from is ProgrammableWeb: https://www.programmableweb.com/

But in general, a lot of things on the web that you would expect. Using Stripe, Paypal, Ebay, Amazon, Google Maps, etc have APIs into their services.

Re: API Practices If You Hate Your Customers

#50
post #38
post #32

I was totally expecting to see something about using a protocol in an unexpected way, because "the protocol is not good enough". I had to work with an API where the company decided everything should return http code 200 (well, at least all 4XX errors), and give the error code in the JSON response, mixing existing 4XX errors and their own errors. When pointed out, the support answer was "we chose to give meaningful er…

Ha, I love it when people make dumb excuses for awful decisions like that. /s I much prefer colleagues who can say, woah that was dumb thanks for informing me of a better way. Making excuses doesn't help anyone unless one has a valid logical reason they did a certain thing, otherwise I DONT WANNA HEAR IT.

The people who write the API and the people who are tasked to provide support for it are usually not the same. If these are APIs between internal business units, my condolences, no excuse.
Post reply on HN