标签: restful-architecture

在我的RESTful API客户端中,可能会尝试发布已存在于数据库中的信息,这不是错误,而是客户端可以忽略的内容,可能会通知用户已存在的dublicate.

现在我在响应正文中返回409 Conflict和已存在的对象.我觉得这是不正确的,因为:

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

而且一般来说,409似乎与PUT更相关.

在这种情况下,正确的答案是什么？可能是303看到其他和位置标题？

我有一个NotificationsController,我只有行动clear.

我想通过POST/notifications/clear来访问此操作

所以我在路由器中写了这个:

  resources :notifications, :only => [] do
    collection do
      post :clear
    end
  end

有没有更清洁的方法来实现这一目标？我想

  scope :notifications do
    post :clear
  end

会这样做,但我有一个missing controller错误,因为 - 我认为 - 它寻找clear控制器.

我们目前正在构建RESTful API(.Net Core,IdentityServer 4,EF6).我们已经发布了它的MVP版本.

它还引用了WCF服务.此WCF服务协调对其他内部(旧系统)和其他集成组件的所有其他调用.

(可能是错误的)实现概述图如下:

我们坚持的主要事情之一是弄清楚如何使用Identity Server集成不同的身份验证和授权系统......

特别是服务电话的内部服务.我们是否使用相同的IdentityServer来执行多个功能？(公共消费者授权和认证以及内部服务到服务授权).

传统上,我们使用了不同的WCF安全配置(Transport,TransportWithMessageCredentials ......等),添加了Forms,AD,ADFS和Service Accounts.我们需要确保正在进行正确的调用以实现可重用的IdentiyServer实现.

简而言之,我们的挑战是如何执行内部服务授权？

1. 拥有一个处理面向公众的请求和内部(多跳)服务到服务授权的中央Identity Server实现是一种好习惯吗？
2. 您是否建议从处理面向公众的API请求的那些服务器中拆分并拥有单独的身份服务器以进行内部服务到服务授权？
3. 或者我们是否还要进一步拆分并为每个应用程序用例创建不同的身份服务器？

我正在构建一个PHP RESTful API,遵循本教程.以下函数应该在使用'put'方法时返回随请求一起发送的数据,每次都返回null:

file_get_contents('php://input').

我甚至已经下载并测试了教程中的完整代码示例,它仍然返回null.

我正在使用cURL和以下命令来测试'put'方法:

curl -i -X PUT -d '{"address":"Sunset Boulevard"}' http://localhost/clients/ryan.

我已经浪费了很多时间,仍然没有阅读json数据.我究竟做错了什么？

我正在尝试构建一个Web应用程序,它应该在客户端使用Laravel作为RESTful后端API和AngularJS.我在Stackoverflow上阅读了有关该问题的所有其他帖子,但没有人肯定回答我的疑虑,至少,我没有找到明确的源代码示例.

例如...

我应该开发两个完全不同的应用程序,一个使用Laravel的后端,另一个是纯客户端,使用AngularJS？但在这种情况下:如何通过单个域(或虚拟主机)处理它们？

或者我应该在Laravel中创建AngularJS模板,在"views"文件夹中并从中调用Laravel服务？我怀疑这是最好的方法:在这种情况下,后端并没有完全与前端实现分离.

另外,如何正确处理路由？我的意思是:我想管理AngularJS路线,如菜单/页面导航,只调用Laravel来检索数据并填充我的视图.按照这篇文章的建议移动"public"文件夹(Angular JS + Laravel 4:如何为生产模式编译？)可能有所帮助？

提前填写建议,例子......

我想知道是否有一些关于REST Web服务的根端点的最佳实践？我的意思是,它应该是关于API本身使用的简短文档吗？它应该是描述所有可用方法的XML文档吗？它应该只返回"未知方法"吗？

我正在考虑在多租户环境中以下两种方法来识别HTTP请求的租户 - 在URI中对租户进行硬编码:

/{tenantUuid}/foos/{id}

或者在自定义HTTP标头中传递租户,例如:

X-Auth-Token: 7d2f63fd-4dcc-4752-8e9b-1d08f989cc00"

(类似于:http://docs.openstack.org/api/quick-start/content/)

请注意,{id}它在所有租户中都是唯一的 - 因此/{tenantUuid}/foos/{id}仍将唯一标识foo资源.

我的问题是 - 在理论上使用自定义标题是否正确,或者是使用自定义标题不安宁.我也知道X-...标题已被弃用,但问题是忽略了这个事实.

谢谢.

我和其中一位同事一直在讨论这种方法

这是一个示例场景:

我正在尝试获取CustomerID为1234的所有订单.

考虑以下端点:

/客户/订单

使用GET请求,使用以下标头:

授权:基本QWxhZGRpbjpvcGVuIHNlc2FtZQ ==

使用Authorization标头,我们的身份验证机制为ID为1234的客户识别此请求,我们的服务返回所需的订单.

他试图说服我这是正确的,因为登录客户,只会请求他们的订单(在这种情况下,属于客户1234的订单) - 所以不需要在URL中传递ID.但是......对我来说,这不是RESTful(我可能错了)

在我看来,它应该是这样的:

/客户/ 1234 /订单

用标题(作为例子)

授权:基本QWxhZGRpbjpvcGVuIHNlc2FtZQ ==

使用Authorization标头,我们验证用户是否有权检索这些订单......如果是,则返回它们,否则返回401

我的问题是,哪种方法首选？

我当然可以看到第一种方式带来的好处,但是为了保持我们的api RESTful,我心里说第二种方式......

鉴于其他部门对我们的REST API的要求,他们POST不仅要使用CREATE,还要使用UPDATE或CREATE.我知道在RESTful API中PUT可以或应该使用它,但由于客户端必须更新用于构建URI的信息,我们不能使用它.它将改变URI并使其PUT不再是幂等的...(旧的URI在第一个之后不存在PUT).
tl; dr我们不能使用PUT

在HTTP/1.1规范中, POST定义为

POST方法用于请求源服务器接受请求中包含的实体作为Request-URI标识的资源的新下级

但是也

POST方法执行的操作可能不会生成可由URI标识的资源.

为了保持RESTful,我会将更新功能解释为旧元素的删除,然后是新元素的创建,这对于POST我会说是可接受的功能.

我们会#201在创建成功时返回,并#200在它只是更新时返回.

在我们的API中,"可能"在没有URI的情况下解决正确的元素(例如,用于更新它POST),因为所有构建主要关键部分的URI都在资源体中,因此API知道客户端想要访问哪个元素.

例

(这只是行为的一个例子POST.不是资源的数据结构.当然使用PUT是完全正确的/cars/)

POST /cars/ HTTP/1.1
<car>
    <id>7</id>
    <status>broken</status>
</car>

回应:#201
然后

POST /cars/ HTTP/1.1
<car>
    <id>7</id>
    <status>fine</status>
</car>

响应:#200
现在GET打开/cars/7将返回以下内容:

<car>
    <id>7</id>
    <status>fine</status>
</car>

PATCH方法应该返回响应主体中资源的所有字段吗？
或者它应该只返回更新的字段？

我正在读这个

例如,如果它仅返回更新的字段,则用户可以知道在服务器中更新了哪些字段,而用户更新了一些字段.

**Users resource representations**
name: string
age: number
createdon: date
modifiedon: date

PATCH /users/{userId}
Request body
{
  name: 'changedname',
}

Response body Case1
{
  name: 'changedname',
  age: 20,
  createdon: 2016-01-01,
  modifiedon: 2016-06-09
}

Response body Case2
{
  name: 'changedname',
  modifiedon: 2016-06-09
}