问题描述
我想听听人们在为他们的Web应用程序构建RESTful（或准RESTful）API时采用了什么方法。
I'm interested in hearing what approaches people have taken when building a RESTful (or quasi-RESTful) API for their web applications.
一个实际示例：
假设您有一个基于浏览器的传统Web应用程序，该应用程序在所有形式上均使用CSRF保护。浏览器中显示的每种形式均包含带有CSRF保护令牌的隐藏输入。提交表单后，如果此输入与服务器端令牌的版本不匹配，则该表单被视为无效。
Say you have a traditional browser-based web application which uses CSRF protection on all forms. A hidden input with a CSRF protection token is included in each form presented in the browser. Upon submission of the form, if this input does not match the server-side version of token, the form is considered invalid.
现在，您要公开Web应用程序作为API（也许使用JSON而不是HTML）。传统上，在发布API时，我认为事务是单方面的（意味着API使用者将基于已发布的API来构建请求，而不是首先请求表单，然后使用返回的表单来构建请求）。
Now say you want to expose the web application as an API (perhaps using JSON instead of HTML). Traditionally when publishing an API, I've considered transactions to be unilateral (meaning the API consumer builds the request based on the published API instead of first requesting a form and then building a request using the returned form).
当出现诸如CSRF保护因素之类的东西时，单边方法就会失效。CSRF保护令牌需要包含在API使用者发送的任何POST / PUTS / DELETES中。
The "unilateral" approach breaks down when things like CSRF protection factor in. The CSRF protection token needs to be included in any POSTS/PUTS/DELETES sent by the API consumer.
我一直在尝试思考如何最好地解决这个问题。每次需要进行API调用时都请求表单似乎很尴尬（尤其是在处理异步操作时），但是我自己想到的所有其他替代方案似乎都无法解决CSRF保护（或至少在其中造成了麻烦） ），这是不可接受的。
I've been trying to think of how best to address this. Requesting a form each time an API call needs to be made seems very awkward (especially when dealing with asynchronous operations), but all other alternatives I've thought of on my own seem to defeat the CSRF protection (or at least punch holes in it), which is unacceptable.
你们中的任何人对此有见识吗？
Do any of you have insight into this?
谢谢。
（这并不是很重要，因为该问题在概念上和与平台无关），但是我正在处理传统的LAMP堆栈，并使用Symfony 1.4作为我的应用程序框架。目标是发布JSON格式的Web API，允许开发人员制作与现有Web应用程序兼容的移动/桌面应用程序。）
(Not that it should matter too much, as the issue is conceptual and platform agnostic, but I'm dealing with a traditional LAMP stack and use Symfony 1.4 as my application framework. My goal is to publish a JSON-format web API allowing developers to make mobile/desktop apps that play nice with an existing web application.)
推荐答案
REST与身份验证（即基本身份验证）配合得很好，因此，请尝试使用用户站点的用户名和特定于与该用户绑定的应用程序的密码-这种技术有时称为API密钥。 FriendFeed的API正在执行。
REST goes quite well with authentication (i.e. Basic Authentication), so try using username of your user site's and password specific to an application bound to that user -- technique sometimes called API keys. Something that FriendFeed's API is doing see the documentation.
很少注意：
- 使用摘要身份验证或SSL
- 每个应用程序都具有API密钥可能会有些麻烦，因此大多数站点对所有第三方应用程序都具有单个API密钥
- 可能值得一试
- use digest authentication or SSL
- having API key's per application can be a bit of an overhead, so most sites have single API key for all 3rd party applications
- OAuth might be worth checking out
这篇关于将CSRF保护与RESTful API相结合的可行技术有哪些？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！