API Practices If You Hate Your Customers • Hacker News Board

Re: API Practices If You Hate Your Customers

#51

Post by tlb » Wed, Dec 11, 2019, 11:01 PM UTC

MadWombat wrote: post #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 cr…

The idempotent operation is usually "Ensure that a VM exists with this name and spec".

An advantage of this style is that if the client dies or times out during the (long) operation, it can retry and get the same answer instantly.

Re: API Practices If You Hate Your Customers

#52

Post by e9 » Wed, Dec 11, 2019, 11:05 PM UTC

Fradow wrote: 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…

It depends. I've seen bigco use this technique and their reason was that they wanted to separate problems with API and request from actual issue with their servers/platform. So if you get 200 it means they received request successfully but if there is issue with request they'll include error in response with 200. If it's anything else then there is a networking or delivery problem. It's not standard way to handle things but can be useful at times.

Re: API Practices If You Hate Your Customers

#53

Post by jan6 » Wed, Dec 11, 2019, 11:06 PM UTC

saagarjha wrote: post #41

gruez wrote: post #39

Earlier quoted context omitted.

>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.

not unless they're being dicks about it, like in this example ;)

Re: API Practices If You Hate Your Customers

#54

Post by paulddraper » Wed, Dec 11, 2019, 11:07 PM UTC

tbirdz wrote: post #24

hermitdev wrote: post #18

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…

Live by the sword, die by the sword.

Re: API Practices If You Hate Your Customers

#55

Post by anoncake » Wed, Dec 11, 2019, 11:07 PM UTC

e9 wrote: post #52

Fradow wrote: 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…

It depends. I've seen bigco use this technique and their reason was that they wanted to separate problems with API and request from actual issue with their servers/platform. So if you get 200 it means they received request successfully but if there is issue with request they'll include error in response with 200. If it's anything else then there is a networking or delivery problem. It's not standard way to handle thi…

How is this better than using different status codes depending on the type of problem?

Re: API Practices If You Hate Your Customers

#56

Post by jschwartzi » Wed, Dec 11, 2019, 11:08 PM UTC

jbob2000 wrote: post #43

pc86 wrote: post #8

Earlier quoted context omitted.

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…

Actually if I want to do way more then I’m generally okay paying more for it. Nobody is asking you to do it for free but automation is something I look for frequently when a tool is core to my work. It’s why I avoid most GUI tools and systems unless the GUI is more than text fields and buttons. It’s simply too much work to repeatedly follow a script for a system like that when I have a very clear use pattern for it.

Re: API Practices If You Hate Your Customers

#57

Post by paulddraper » Wed, Dec 11, 2019, 11:08 PM UTC

tomaszs wrote: post #26

Personally i think API should be obligatory. Every company should provide it with respect for private data. Additionaly if a company does not have it, it should be prohibited to block automatic measures to process the system and data. There should be a pricing model to cover basic expenses made by the API usage. Maybe you wonder why on earth it should be legally allowed to process automatically system data? We have a…

LinkedIn would like to have a word with you.

Re: API Practices If You Hate Your Customers

#58

Post by paulddraper » Wed, Dec 11, 2019, 11:09 PM UTC

Glyptodon wrote: post #19

I thought the chosen example for idempotent requests was a bit funny as I don't think POST is necessarily idempotent and depending on your specific use case making it so may or may not be easy.

POST is explicitly not idempotent.

Re: API Practices If You Hate Your Customers

#59

Post by aldoushuxley001 » Wed, Dec 11, 2019, 11:10 PM UTC

hpoe wrote: post #20

jbob2000 wrote: 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…

Is having an unnecessary API really better architecture though? It adds quite a bit of complexity and there are other ways to address separation of concerns.

Re: API Practices If You Hate Your Customers

#60

Post by Ididntdothis » Wed, Dec 11, 2019, 11:11 PM UTC

tbirdz wrote: post #24

hermitdev wrote: post #18

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…

I had a similar situation where a certain person would blame my API for all of his problems in a very public manner. First few times I responded quietly pointing out the mistakes but then I started responding publicly pointing out that the person should first learn the programming language before blaming others with examples from previous interactions. The behavior stopped immediately. Sometimes you have to bully the bully and make clear that being new is not an excuse for bad behavior.