当前位置:  开发笔记 > 运维 > 正文

RESTful幂等

如何解决《RESTful幂等》经验,为你挑选了0个好方法。

我正在使用ROA(面向资源的架构)设计RESTful Web服务.

我正在尝试找出一种有效的方法来保证在服务器指定资源密钥的情况下创建新资源的PUT请求的幂等性.

根据我的理解,传统方法是创建一种类型的事务资源,例如/ CREATE_PERSON.用于创建新人员资源的客户端 - 服务器交互将分为两部分:

步骤1:获取用于创建新PERSON资源的唯一事务ID :::

**Client request:**
POST /CREATE_PERSON

**Server response:**
200 OK
transaction-id:"as8yfasiob"

第2步:使用事务ID :::在保证唯一的请求中创建新的人员资源

**Client request**
PUT /CREATE_PERSON/{transaction_id}
first_name="Big bubba"

**Server response**
201 Created             // (If the request is a duplicate, it would send this
PersonKey="398u4nsdf"   // same response without creating a new resource.  It
                        // would perhaps send an error response if the was used
                        // on a transaction id non-duplicate request, but I have
                        // control over the client, so I can guarantee that this
                        // won't happen)

我在这种方法中看到的问题是它需要向服务器发送两个请求才能进行创建新PERSON资源的单个操作.这会产生性能问题,从而增加用户等待客户端完成其请求的机会.

我一直试图找出消除第一步的想法,例如预先发送每个请求的事务ID,但我的大多数想法都有其他问题或涉及牺牲应用程序的无状态.

有没有办法做到这一点?

编辑::::::

我们最终得到的解决方案是客户端获取UUID并将其与请求一起发送.UUID是占用16字节(2 ^ 128)空间的非常大的数字.与具有编程思维的人可能直观地思考的相反,随机生成UUID并假设它是唯一值是公认的惯例.这是因为可能值的数量太大以至于随机产生两个相同数量的几率足够低以至于几乎不可能.

需要注意的是,我们让客户从服务器请求UUID(GET uuid/).这是因为我们无法保证我们的客户端正在运行的环境.如果出现问题,例如在客户端上播种随机数生成器,那么很可能是UUID冲突.

推荐阅读
喜生-Da
这个屌丝很懒,什么也没留下!
DevBox开发工具箱 | 专业的在线开发工具网站    京公网安备 11010802040832号  |  京ICP备19059560号-6
Copyright © 1998 - 2020 DevBox.CN. All Rights Reserved devBox.cn 开发工具箱 版权所有