如何在API中定义金额 [英] How to define money amounts in an API
问题描述
我将创建一个包含金额的API。我想知道最佳做法是什么，或者有人在某些格式上有好不好的经验。
I'm going to create an API which contains money amounts. I was wondering what the best practices are, or whether someone has some good or bad experiences with certain formats.
- 我们应该传输基本单位还是次要单位？ （金额与amount_cents）
- 我们应该将数字表示为整数/小数还是字符串？
我已经看到以下两种可能性：
I've seen the following two possibilities:
- 将金额发送为类似字符串： 5.85（带有基本单位的字符串）
- 以次要单位发送金额：585（整数，以次要单位表示金额）
我要在这两个之间来回走动。因此，我出去检查了其他API的用途，并提出了以下列表：
I'm going back and forth between those two. So I went out to check what other APIs use and came up with the following list:
- 条纹：带次要单位的整数
- 大脑：基本单位的字符串
- Google电子钱包：基本单位的字符串
- Paypal：基本单位的字符串 li>
- Amazon Payments：具有基本单位的字符串
- 货币云：具有基本单位的字符串
- 2checkout：具有基本单位的字符串基本单位
- Adyen：具有次要单位的整数
- Dwolla：具有基本单位的十进制
- GotoBilling：很奇怪启发式！ 金额的格式可以带或不带小数。如果不给小数，则假定两（2）个小数位（1.00 = 100）。
- GoCardless：带有基本单位的字符串
- Intuit：请求中带有基本单位的小数，响应中带有基本单位的字符串
- Klarna：具有次要单位的整数
- MasterCard：具有次要单位的整数
- Paynova：具有基本单位的字符串
- Rogers Catalyst：具有基本单位的字符串
- WePay：具有基本单位的字符串
- Venmo：具有基本单位的十进制
- Stripe: integer with minor units
- Braintree: string with base units
- Google Wallet: string with base units
- Paypal: string with base units
- Amazon Payments: string with base units
- The Currency Cloud: string with base units
- 2checkout: string with base units
- Adyen: integer with minor units
- Dwolla: decimal with base units
- GotoBilling: weird heuristics! "Amount may be formatted with or without a decimal. If no decimal is given two (2) decimal places are assumed (1.00 = 100)"
- GoCardless: string with base units
- Intuit: decimal with base units in requests, string with base units in responses
- Klarna: integer with minor units
- MasterCard: integer with minor units
- Paynova: string with base units
- Rogers Catalyst: string with base units
- WePay: string with base units
- Venmo: decimal with base units
在18个采样的API中，有4个使用次要单位，13个使用基本单位，而1个使用难以理解的混合物。在13个使用基本单位的人中，有10个将其作为带引号的字符串进行传输，将3个作为无引号的小数进行传输（如果您查看Intuit，则实际上为2个半）。
So, out of 18 sampled APIs, 4 are using minor units, 13 are using base units and 1 is using a hard-to-comprehend mixture. And within the 13 who use base units, 10 are transmitting them as quoted strings, 3 as unquoted decimals (actually 2 and a half if you look at Intuit).
I不得不解析 8.20之类的字符串，个人会感到不舒服，因为如果您解析此字符串，则如果您错误地使用浮点数，则将变为 8.19999999 ...。因此，我倾向于仅发送整数。但是我认为这不是一个很好的论据，而且我发现一般来说API倾向于将基本单位作为字符串使用。
I personally feel uncomfortable having to parse a string like "8.20", because if you parse this it becomes "8.19999999..." if you make the mistake to use floats. So I'm leaning towards sending integers only. But I don't think this is a great argument, and I see that generally APIs tend to go with base units as strings.
您对/
推荐答案
整数会吃掉点，即少一个字节：D整数会有一个max_int，你有吗有钱的人会溢出吗？
Integers will eat the dot, that's one less byte :D Integers will have a max_int, do you have anyone rich enough that may overflow?
将货币字符串解析为float的人们将整数转换为浮动。
People that will parse a currency string as float will turn the int to float anyway.
如果发送二进制数据，则整数将比字符串小得多，并且不适合使用。如果仍然发送xml，则最好将其定义为字符串（文件可能在发送之前已经压缩了吗？），请尝试使其成为 currency类型，而不是将其列为完整字符串。
If you send binary data, integer will be much smaller than a string and the way to go. If you send xml anyway, you might as well define it a string (the file is probably compressed before sending right?), try to make it "currency" type as opposed to listing it as a full string though.
这篇关于如何在API中定义金额的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
