Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

No Abstractions: our API design principle

increase.com

Post reply on HN
Print view View original

21–30 of 141 posts

Re: No Abstractions: our API design principle

#21

Post by freedomben »

lolpanda wrote: post #18

for any APIs related to money, should the currency be in strings as opposed to in floats? This will prevent accidental float arithmetic in the code. I always find it tricky to work with currency in javascript.

Yes, never use floats for currency. I typically use integers and for USD for example, measure in "cents" rather than dollar. I try to avoid the fallacy of appeal to authority, but this is what Stripe does. You can also use the Decimal type in javascript and convert to/from strings to cross API boundaries.

Re: No Abstractions: our API design principle

#22

Post by benhoyt »

lolpanda wrote: post #18

for any APIs related to money, should the currency be in strings as opposed to in floats? This will prevent accidental float arithmetic in the code. I always find it tricky to work with currency in javascript.

From their docs [1] it looks like they do everything using integers: the amounts are integers in the "minor unit" of currency, for example cents if the currency is dollars. So 1000 means $10.00. In languages like JavaScript where everything is a float64, you can still accurately represent integers up to 2^53, which would be $90 trillion.

[1] https://increase.com/documentation/api#transactions

Re: No Abstractions: our API design principle

#23

Post by nijave »

trevor-e wrote: post #20
lolpanda wrote: post #18

for any APIs related to money, should the currency be in strings as opposed to in floats? This will prevent accidental float arithmetic in the code. I always find it tricky to work with currency in javascript.

I've always seen currencies multiplied by 100 to remove the need for floating point.

Yeah, this seems like a common pattern. Not sure about currency with arbitrary place values though (like Bitcoin)

Re: No Abstractions: our API design principle

#25

Post by nijave »

koreth1 wrote: post #14
jackflintermann wrote: post #11

Earlier quoted context omitted.

Yes, exactly, the important thing to us is that our users don't need to build an additional mental model between us and the networks we sit atop. If you know the network, we want you to be able to intuit how our API works. There's a very real difference (arguably the fundamental value-add of our company) in the transport layer, though. The actual mechanics of integrating with, say, FedACH, are a bit long to get into…

That's an excellent point too. Some payment systems have abysmal technology. The product I worked on was focused on international payments and in a couple cases, the "API" was literally, "Upload a CSV file via FTP, and at some later point, another CSV file might appear on the FTP server with some of the payment results, but if it doesn't, call us because we probably just forgot to upload it."

Batch jobs and (S)FTP. In a bit of a weird twist, back when I worked at Chase, they were innovating on the ancient technology but it was things like "better batch job management/orchestration" and SFTP proxy to route between different servers and centralize key management

Re: No Abstractions: our API design principle

#26

Post by endofreach »

lolpanda wrote: post #18

for any APIs related to money, should the currency be in strings as opposed to in floats? This will prevent accidental float arithmetic in the code. I always find it tricky to work with currency in javascript.

You should never use floats for dinero. And it has nothing to do with JS, though i find it funny that you mention JS.

Re: No Abstractions: our API design principle

#27

Post by deathanatos »

nijave wrote: post #23
trevor-e wrote: post #20

Earlier quoted context omitted.

I've always seen currencies multiplied by 100 to remove the need for floating point.

Yeah, this seems like a common pattern. Not sure about currency with arbitrary place values though (like Bitcoin)

I'm not sure what you mean by "arbitrary place values" with Bitcoin; if you are implying it's infinitely divisible, it isn't. You'd do the same trick with Bitcoin: represent it as an integer¹. The value 1 is 1 sat, or 0.00000001 BTC.

¹(where you need to; otherwise, I'd use some fixed point type if my language supports it)

Re: No Abstractions: our API design principle

#28

Post by jackflintermann »

jiggawatts wrote: post #19
conroy wrote: post #9

Earlier quoted context omitted.

In this case, a HTTP API is the abstraction. Integrating with ACH and other payment rails requires a lengthy integration process. Sometime you have to send binary files using FTP!

The article says “no abstractions”, but HTTP is often exactly that: an abstraction over lower-level protocols.

I guess the phrase "no abstractions" is specifically valuable to us when designing our REST API resources - our whole stack is certainly an abstraction of sorts, but we don't want to add yet another abstraction in that specific layer.

Re: No Abstractions: our API design principle

#29

Post by cratermoon »

lolpanda wrote: post #18

for any APIs related to money, should the currency be in strings as opposed to in floats? This will prevent accidental float arithmetic in the code. I always find it tricky to work with currency in javascript.

neither. Use rational or some other better type.

Re: No Abstractions: our API design principle

#30

Post by [deleted] »

endofreach wrote: post #26
lolpanda wrote: post #18

for any APIs related to money, should the currency be in strings as opposed to in floats? This will prevent accidental float arithmetic in the code. I always find it tricky to work with currency in javascript.

You should never use floats for dinero. And it has nothing to do with JS, though i find it funny that you mention JS.

[deleted]
Post reply on HN