您如何对网络服务计费？
在开发新的网络服务时，我无法找到很多有关公司如何为其网络服务计费的信息。
您是按请求计费还是仅按某些请求（即 GET 或 POST）计费？
-这些会在应用程序或服务器级别进行跟踪吗？
您按带宽计费吗？
-同样如何在每个用户的基础上进行跟踪
您是否收取订阅费用以获取访问权限？
- 这是假设他们仅在付款后才被授予 API 密钥。
上述或其他选项的组合？
感谢您的帮助。
In developing a new web service I haven't been able to find very much information on how companies bill for their web services.
Do you bill by request or only certain requests ie) GET or POST?
-would these be tracked at the application or server level?
Do you bill by bandwidth?
-again how would this be tracked on a per user basis
Do you charge a subscription to simply have access?
-this is assuming that they are only granted an api key after payment has been made.
A combination of the above or other options?
Thanks for your help.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
与市场经济中的所有事物一样，价格以及与实际付款（无论金额多少）相关的不便（或便利）和风险取决于您的服务或产品的独特性、酷感和价值。
因此，只能用非常笼统的术语，即以建议的形式来回答这个问题。您的实际发票模型可能基于以下一项或多项
一般来说，价格和会计方式对于双方，尤其是买方来说应该是公平的，并且通常越简单越好。价格不一定很低，只要您能够证明所提供的服务实际上是有价值的，并且您要么投资并承担风险来引入该服务，要么与运行该服务相关的持续费用是显而易见的。
As all things in a market economy, the price, but also the inconvenience (or convenience) and risk associated with the actual payment (irrespective of the amount) is a function of how unique and cool and valued your service or product is.
It is therefore impossible to answer the question but in very generic terms, i.e. in the form of suggestions. You actual invoicing model may base on one or several of the following
In general, the price and the modality of accounting should seem fair, to both parties, particularly to the buyer, and typically, the simpler the better. The price should not necessarily be low, provided you can make the case that the service provided is effectively valuable, and that you either invested and took risk to introduce the service, or the on-going expenses associated with running the service are evident.
我想这取决于服务的用途。一般来说，我认为当你提供一些内在价值时，你应该计费；如何确定计费标准是特定于领域的。所提供的服务可能有某些属性，可让您确定计费金额。
例如，假设您有一个执行计算的 Web 服务。您可能会决定，对于每次成功的计算，您将收取固定费用，例如
$0.01，但如果存在验证问题（例如无效请求），则让用户离开。或者，如果这些计算运行时间较长，您可能有一个基于某种 CPU 时间指标的收费模型。您关于订阅的观点很好，在这一领域您可能会从允许几种商业模式中受益；一种是为了满足每月可能执行大量请求的用户，在这种情况下，固定订阅可能有意义，另一种是为了满足提出一些临时请求的用户。当然，在后一种情况下，如果您仅仅吸引这些客户，那么您就不会获得良好的投资回报。某种中间立场，即您有少量订阅，但随后允许客户购买顶部的“块”或“捆绑”请求，而不会产生额外的处理成本，可能会起作用。
I guess It Depends™ on what the service does. Broadly, I'd say you should bill when you provide some intrinsic value; how you determine what that billing criteria is is quite domain-specific. There may be some property of the service provided which allows you to determine how much to bill.
For example, suppose you've a web service that performs a calculation. You might decide that for every successful computation you do, you're going to charge a fixed fee, say
$0.01, but let users off if there's a validation problem, such as an invalid request. Alternatively, if those computations are vaguely long-running, you might have a charging model that's based on some sort of CPU-time metric.Your point about subscriptions is a good one, and this is an area where you might potentially benefit from allowing a couple of commercial models; one to cater for the users who might perform a lot of requests per month, in which case a fixed subscription might make sense, and one to cater for users who make a few ad-hoc requests. In the latter case, of course, if you only attract those customers, then you're not going to make a good return on investment. Some kind of middle ground, whereby you have a small subscription, but then allow customers to buy a "block" or "bundle" of requests on top without incurring additional processing costs, might work.
我知道的大多数网络服务都对两件事收费：
我还没有真正见过或参与过任何按绩效付费或按点击/访问付费模式的项目，因为它们很难可靠地计费，也很难向客户负责，即使您使用分层或带状范围。你如何告诉你的客户他们使用了多少次点击，特别是在分布式系统中，具有冗余故障转移等。如果我必须为每次访问支付 0.01 美分，我想确切地知道它是如何衡量的，以及公司是什么是否有适当的方式来控制访问，以及他们的监控有多准确等等。
这并非不可能，而且绝对可以做到，并且在大批量场景中可能会很好地工作。
Most webservices I know of charge for two things:
I havent really seen or participated in any projects with pay-for-performance, or pay-per-hit/access models as they get very difficult to reliably bill for and very hard to account for to customers, even if you use tiered or banded ranges. How do you tell your customers how many hits they have used, especially in a distributed system, with redundant fail-over, etc. If I had to pay $0.01 cents per access I would want to know exactly how its measured, and what the company had in place to control access, and how accurate their monitoring was, etc.
Its not impossible, and definitely can be done, and may work well in large bulk scenarios.
我见过很多按时间计费的，比如按月或按年。有些允许您按月付款，有些则要求预先支付部分（或全部）费用。可以通过为 Web 服务颁发安全证书来限制访问，该安全证书会在客户的帐户过期时过期，或者可能通过让他们发送客户端 ID 并让服务器检查是否允许该客户端 ID 获得答案（但这对客户开放）。人们窃取了别人的客户 ID；))。
我想如果您有一项发送和接收大量数据的服务，那么按服务请求计费可能是有意义的，但计费可能会变得更加棘手。客户每天可能会提出几十个请求，还是只有几个请求？每笔交易要收取多少费用？ 100 美元？ 0.01 美元？这一切都取决于服务的性质。如果你想走这条路，你可能需要能够确保客户端只为成功应答的请求付费（即使我的客户端应用程序无法从你的服务器）。
Many of the ones I have seen bill by time, such as on a monthly or yearly basis. Some allow you to pay by the month, some require some (or all) of the fee up front. Access might be restricted by issuing a security certificate for the web service that expires when the customer's account expires, or possibly by having them send a client ID and letting the server check if that client ID is allowed to have an answer (but that's open to people stealing someone else's client ID ;) ).
I suppose if you have a service that sends and receives very large amounts of data, it might make sense to bill per service request, but the billing for that could get trickier. Are clients likely to make dozens of requests per day, or just a few? How much to bill per transaction? $100? $0.01? That all would depend on the nature of the service. If you want to go that route, you would probably need to be able to ensure that clients only get billed for requests that are successfully answered (I'd hate to get billed even though my client app failed to receive the entire web service message from your server).
根据请求或作为订阅，是的，带宽可以是用于设置费用的变量。取决于将客户紧密结合或让无数松散耦合的客户使用它的价值。这个问题没有适合所有甚至大多数情况的正确答案。
如果我看看我过去提供的服务，订阅模式将是最好的模式。有时，每个请求的 $ 刻度似乎是最好的方法，但我还从未以这种方式配置过服务。
Per request or as a subscription, and yes, bandwidth can be a variable that is used to set the fee. Depends of the value of binding the customer close or having a myriad of loosely coupled customers using it. There is no correct answer to the question that fits all or even most cases.
If I look at the services I have made in the past, the subscription model would be the best model to use. Sometime a tick of $ per request seems like the best approach but I have never had a service configured that way yet.
我同意 Rob 和 Des 的说法。要记住的一件事是，订阅是一个非常简单的概念，每个人都习惯并适应（如果你定价合适）。如果您想覆盖更广泛的受众，请查看支付提供商的做法 - 他们的支付方式略有不同，具体取决于您每年进行的交易数量。将会有固定的订阅加上每笔交易的费用，它们都随着交易的数量而变化。这是最灵活的，但这取决于它是否对您的业务有意义。
I agree with what has been said by Rob and Des. One thing to remember is that a subscription is a really simple concept that everyone is used to and comfortable with (if you price it right). If you want to cover a wide audience look at how the payment providers do - they have slightly different methods of payment depending on how many transactions you do per year. There'll be a fixed subscription plus a per-transaction charge and they both vary with the number of transactions. This is the most flexible, but it depends if it makes sense for your business.