我有一个名为'facts'的资源集合的URI,以及该集合中每个'fact'资源的URI。

我相信,应该使用GET请求创建新“事实”的表单,但我无法确定应该使用哪个URI。

对集合URI的GET应返回“事实”资源URI的列表。 每个'事实'URI应该返回其内容作为对GET的响应。 当然,实际的'事实'创建将是POST(或PUT,具体取决于具体情况)。

我看到一些选项,但似乎没有一个令人满意:

  1. 添加“事实”URI将引用的“事实形式”URI。 对此URI的GET提供HTML表单。 仅仅为了描述资源而拥有另一个资源似乎是错误的。
  2. 对'fact'URI进行的POST而不在头文件中包含任何表单数据将返回该表单。 然后在用户填写表单后,它将使用表单数据POST,并创建新的“fact”资源。 这似乎是一种更糟糕的方法。
  3. 不要通过电汇发送表格,而是将其作为API的一部分包含在内。 这似乎是RESTful,因为REST API应该描述媒体类型,并且可以从“事实”类型的描述中创建表单。 实施起来很奇怪。 也许REST服务与常规网站是分开的,因此实际的HTML表单请求与REST API不同。
  4. 包含HTML表单作为“事实”URI响应的一部分。

为了澄清,我正在尝试遵循Roy Fielding所规定的真正的REST架构,而不是半生不熟的RPC冒充REST。

编辑:我开始认为#3正在发挥作用。

edit2:我认为解决方案是以CRUD方式定期进行非REST HTML导航,然后前端根据需要进行AJAX REST调用(或者后端对其REST API进行内部调用)。

我需要正确执行此服务的REST部分的原因是我希望以后允许其他非HTML客户端与其进行交互。

#1楼 票数:2

在我看来,唯一干净的RESTful答案是1和3。

在我看来,资源的描述是它自己的资源。 问题是您是否希望通过应用程序的API访问此资源,或者您是否希望将其作为API本身的一部分。

对于1,似乎RESTful使URI像这样:

获取/事实 - >所有事实GET / facts / 1 - >返回事实1(显然id可能是一个单词或其他东西)GET / facts / create - >返回一个适合创建事实的表单POST / fact - >添加事实

#2楼 票数:-1

我觉得你有点过分复杂了。 Web浏览器不是一个完美的REST客户端,因此您无法拥有完美的RESTful解决方案。 在完美的世界中,您根本不需要表单,因为Web浏览器会知道您的媒体类型并构建表单本身。

同时,我建议你只使用大多数REST框架在资源上调用额外的“视图”来返回一个表单:
例如/your/collectionresource?view=form ,或/your/collectionresource;form

  ask by aehlke translate from so

未解决问题?本站智能推荐:

2回复

RESTful体系结构认证/授权策略

我正在使用Angularjs和Node.js(特别是hapijs)创建应用程序。 我正在尝试为RESTful类型的体系结构确定一种好的身份验证和授权策略。 我花了很多时间在网上阅读有关此内容的信息,并想出了一个图表,说明我打算为我的应用程序做什么。 我想知道此模型中是否有明显明显的漏洞
1回复

在RESTful服务中使用http状态代码

我正在寻找一个很好的有意义的讨论,为什么人们认为RESTful Web服务劫持HTTP响应代码并在给定API的上下文中为它们赋予意义是一个好主意。 我的直觉反对它:它认为HTTP在这里充当传输层协议,为什么我会将我的API概念泄漏到传输层? 是的,我理解HTTP是27层图中的应用层,但分层是
5回复

为什么RESTful应用程序更容易扩展

我一直认为选择RESTful架构的一个原因是(其中包括)具有高负载的Web应用程序的更好的可伸缩性。 这是为什么? 我能想到的一个原因是,由于每个客户端定义的资源相同,缓存变得更容易。 在第一个请求之后,后续请求从memcached实例提供,该实例也可以水平扩展。 但是你不能用传统方
3回复

你能构建一个RESTful业务逻辑层吗?

我为我的架构的数据访问层(DAL)构建了一个RESTful服务: 但是,对于业务逻辑层(BLL),使用第二个非RESTful服务: 这个BLL服务不是直接调用DAL服务,而是直接与数据库对话。 你会如何改进这种架构? BLL服务应该调用DAL服务吗? 我应该放弃DAL服务
1回复

将HATEOAS用于RPC样式的命令是否是RESTful

在 REST 中,资源由它们的 URI 标识,并且允许的操作仅限于可用的 HTTP 动词。 RESTfull API 是一个统一的接口,通过 HTTP 为资源提供基本的 CRUD 操作。 最后,REST 架构规定资源应包含客户端的超链接以进一步遍历 API。 这称为 HATEOAS(超文本作为应用
2回复

RESTful体系结构,Spring与JavaEE

我正试图就我正在构建的一些新项目的体系结构解决方案做出决定。 这些项目需要是多平台的,移动的,平板电脑,台式机等。因此,为后端/服务器选择RESTful api(json)的原因。 我从事Java EE已有很长的时间了,因此在Spring和Java EE 6上已经过期,但是两者看起来都非
1回复

将目标RESTful设计用于公共Web服务/API是否总是与之相关?[关闭]

毫无疑问,RESTful是流行语,在许多情况下,它似乎是一个砍刀设计模式。 努力将其应用到我自己的Web API(现有的和即将发布的)上,我终于想知道它是否与我的工作有关(如果我们忘记了它存在于某些RFC中的事实,我们会尝试做出响应;)。 首先,我主要处理的是至少确定3个参数(最多可能是
1回复

通过JavaJAX-RSREST服务使用JS发送HTML

我正在编写一个提供2种东西的REST服务: 1.数据信息(从数据库中读取) 2.网络应用程序(即网页) 因此,目前我只有一个索引页,并且我在REST请求中返回了该html文件。 我的Service类如下所示: 现在在HTML文件中,我尝试包括一些与HTML文件放在同一文件夹中的