我将为一个Web应用程序构建API,对于良好的实践方法,我很感兴趣。
我已经计划使其分版本(版本1只能控制系统的某些方面,版本2可以控制更多,但这可能需要改变身份验证方式,与版本1不兼容),并且身份验证将与人们用于登录的标准用户名/密码不同(如果有人使用恶意工具,它不会让他们完全冒充用户,而只能进行API允许的操作)。
是否还有其他想法或者你曾经使用过特别好的API网站的例子?
我将为一个Web应用程序构建API,对于良好的实践方法,我很感兴趣。
我已经计划使其分版本(版本1只能控制系统的某些方面,版本2可以控制更多,但这可能需要改变身份验证方式,与版本1不兼容),并且身份验证将与人们用于登录的标准用户名/密码不同(如果有人使用恶意工具,它不会让他们完全冒充用户,而只能进行API允许的操作)。
是否还有其他想法或者你曾经使用过特别好的API网站的例子?
阅读《RESTful Web Services》这本书,它可以为您提供如何实际使用REST的良好概述,并使您足够快地掌握技巧,以便立即开始工作并具有一定的信心。这比仅查看现有API更有用,因为它还讨论了设计选择和权衡。
1)将版本号直接烘焙到URL中,而不是将其作为参数传递,这样每次版本升级都可以完全自由地更改API命名空间的组织结构。
2)尽可能使您的URL重写规则(如果有)简单/精简,同时使您的URL尽可能美观(但不要过度)。
3)始终寻找最佳的HTTP状态码来为每个响应进行分类(例如,不要忘记202和207)。
4)实现强制参数验证逻辑和信息丰富的错误消息。
5)在适当的情况下使用HTTP请求标头代替参数(例如,使用Accept允许客户端指定所需的响应数据格式)。
6)以这样一种方式组织您的“名词”,使得不同客户端受众使用的URL在您的URL树的“根”附近分离(如果需要,这使得更容易强制执行不同的身份验证机制或甚至将URL树的不同部分映射到不同的服务器)。
7)如果您正在为常规Web页面提供与API相同的域,并使用相同的身份验证凭据,请在API请求中要求X-Requested-With标头,以避免XSRF漏洞。
使用REST。
了解API的标准,或者从受欢迎的API中借鉴想法。
在验证用户时要小心。
一开始非常简单。
构建一个使用您的API的站点(即使它没有用处)来检查事情是否正常。也许您可以构建一个移动版本的站点或者强制自己深入使用API的某些功能。