构建没有身份验证要求的 API？
构建没有密钥/其他身份验证要求的 API 是一个坏主意吗？
优点：
- 实施起来更简单
- 使用起来更
简单 缺点：
- 它可能会被过度使用
- ......导致必须稍后添加密钥并惹恼用户
我不是在这里构建下一个 Facebook，只是一个简单的数据服务。我不期望必须支持大量用户，而且我的数据是静态的。
鉴于上述情况，在不需要密钥的情况下构建 API 是一种不好的做法吗？或者我会侥幸逃脱吗？
Is it a bad idea to build an API without a key / other authentication requirements?
Upsides:
- Simpler to implement
- Simpler to use
Downsides:
- Potential it might get overused
- ... leading to having to add a key later and annoy users
I'm not building the next Facebook here, just a simple data service. I don't expect to have to support tons of users, and my data's static.
Given the above, is it bad practice to build an API without requiring a key, or will I get away with it?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
通过 REST-API，您可以使用 HTTP 身份验证，无需密钥。
仅当您的网站上存在任何用户不应看到的内容时，您才需要对用户进行身份验证。
您可以在没有它的情况下开始，如果在某些时候您觉得需要保护您的站点（或单个资源）免受公众侵害，您只需在请求中不存在 Authenticate 标头时通过发送 401 状态代码来实现 HTTP 身份验证。 HTTP 客户端开箱即用地了解这一点，因此对您的用户来说没有任何变化。
实现方面的身份验证通常只是请求处理中的一个独立层或阶段，因此您不需要分解所有代码。
With REST-APIs you use HTTP authentication, there are no keys required.
You only need to authenticate your users if there is content on your site that should not be seen by any user.
You can start without it and if at some point you feel you need to protect your site (or individual resources) from the public, you simply implement HTTP Authentication by sending a 401 status codes if no Authenticate header is present in the request. HTTP clients understand that out of the box, so nothing changes for your users.
Implementation-wise authentication is often just an independent layer or phase in the request handling, so you won't need to rip apart all you code.