问题标签 [restful-architecture]

我正在创建一个 RESTful Web 服务，其中一些资源是计算或处理功能。例如，用户可以通过 API 通过提交图像并接收缩放或转换后的图像来缩放和转换图像。

根据RESTful Web Services Cookbook第 2.5 节，我应该使用 GET：

对于输入简单的情况（例如点的经纬度坐标），这一点很清楚。但是，对于较大的输入（例如图像），我是否应该遵循相同的建议？据我所知，不可能将这么多数据作为查询参数发送。

在 RESTful 应用程序中，两个请求之间没有维护状态。每个请求都被视为一个全新的请求，即使它是由同一用户发送的。即没有会话。

在这种情况下，REST 应用程序如何处理用户登录信息？

1. 是不是，在成功登录后，服务器会生成一个安全令牌并将其发送给客户端，然后客户端会为之后的每个请求将其发回？
2. 如果上述情况属实，那么安全令牌存储在服务器的什么位置？数据库？（记住：没有会话）。

我有一个名为 Entries 的资源，它具有与资源一起使用的所有正常默认 RESTful 路由。我想保留所有路由，因为它们除了我希望将show操作重新路由到我的文章控制器（Articles#show）。这是我的路由文件中的当前（但不工作）代码：

关于如何解决这个问题的任何想法？我想将 Entries 资源中的所有其他路由保持原样。

我刚刚开始阅读有关实现 RESTful Web 服务和创建 RESTful api 的内容。我已经了解了 REST 的基本概念，但我一直在摸索如何安全地实现它？

例如，我的 webapp 有一个用户登录过程。成功登录后，我还应该在RESTful请求中传递什么来在服务器上进行身份验证？？？我能想到的是以下过程：

• 用户登录（将用户名/密码发布到 API）
• API 使用用户密钥进行响应
• 用户密钥存储在本地
• 在提出任何进一步的请求时，我在请求中包含此密钥进行身份验证

但这里似乎userkey是我发送到 API 的状态，但 REST 恰好是无状态的。GET在发送请求的情况下，这也不太安全。

OAUTH 能解决我的困境吗？还是其他方式？有人可以指导我吗...

谢谢

作为最佳实践，我们公司使用合同优先方法创建 Web 服务。

WSDL 是在考虑实现之前定义的。

是否可以使用 REST 使用这种方法？我正在考虑使用 XSD，但是调用通常不是 XML！那么如何以机器可解释的方式指定合约呢？

我已经在 Spring MVC 3.0 中实现了一个应用程序。现在我想将此应用程序转换为一个安静的应用程序，这样业务逻辑保留在一个应用程序中，而 Web 层保留在另一个应用程序中。

现在使用 Rest 来实现这一点，我的 web 层将充当一个 rest 客户端，它将访问业务逻辑实现相关应用程序公开的服务

我感到困惑的一点是我应该如何为此实现登录。

我是否应该在休息后请求中将登录凭据从 Web 应用程序发送到服务应用程序，然后维护将充当 jsessionid 的 ID，以授权我的进一步请求

或者我应该对每个请求进行身份验证和授权

或者 Spring 是否已经提出了任何设计模式来实现这种需求。

任何有这方面知识的人都可以帮助我。

我正在尝试将 AppEngine 用作一种 RESTful Web 服务。该服务应该进行简单的查找和放置，Datastore因此Objectify似乎很适合覆盖该部分。Datastore'. I'm using如果Redstone XMLRPC` 中没有该部分的数据，它还会对其他服务进行一些查找。

现在，我有几个关于如何根据 AppEngine 的配额设计服务部分的问题（我想大多数情况下应该考虑效率，但 AppEngine 的计费让更多人考虑效率）。

1. 首先让我们考虑我使用简单的Servlets. 在这种情况下，我看到两个选项。要么我创建多个 servlet，每个 servlet 提供不同的服务，并将 Json 传递给它们，要么我使用单个（或更少数量的）服务并根据 Json 传递的参数确定要执行的操作。任何一种设计都会对小时数等有任何意义AppEngine吗？

2. 如果我使用 RESTful 框架（例如Restlet或RestEasy与准系统方法相反），成本有何不同？

这个问题是对以下内容的跟进：使用 Google AppEngine 创建 Java Web 服务

在我的 RESTful API 客户端可能会尝试发布已经在数据库中的信息，这不是错误，而是客户端可以忽略的东西，可能会通知用户已经存在的重复项。

现在我在响应正文中返回 409 Conflict 和已经存在的对象。我觉得这是不正确的，因为：

由于与资源的当前状态冲突，无法完成请求。仅在预期用户可能能够解决冲突并重新提交请求的情况下才允许使用此代码。响应正文应该包含足够的信息让用户识别冲突的来源。理想情况下，响应实体将包含足够的信息供用户或用户代理解决问题；但是，这可能是不可能的，也不是必需的。 通过restpatterns.org

总的来说，409 似乎与 PUT 更相关。

在这种情况下，正确的反应是什么？会不会是 303 See Other and Location 标头？

我只是在 Rails 中编写我的第一个应用程序，我想知道是否有最佳实践来执行以下操作：

我有一个由脚手架创建的客户模型并将其抽起来。客户必须显示在谷歌地图中，​​因此如果转到 /customers/23，则会显示客户信息。另外，我在此页面中有一个链接，可以在地图中显示用户（带有通过 ajax 出现的查询 ui 对话框）。我的问题是，这如何适合模型的正常 crud 结构。我是否应该创建一个名为“show_map”的操作并在资源路由之外为其提供额外的路由？你如何处理这种事情？