我有一个我已经构建的RESTFul服务器API.它的某些部分不控制资源,我无法将相关的URL + HTTP方法映射到服务器上执行的操作.
例如,我可以备份服务器上的每个资源POST /backup,但我不确定这是否是最合适的映射.单个资源怎么样?我应该使用:POST /backup/id或通过将id声明为我发送的变量来指定它:POST /backup <id>
请给我一些关于如何最恰当地构建这个的提示,以便我的API易于掌握.
这取决于您每次调用时是否在数据库上创建新的备份对象,或者如果您有许多仅包含最后一个值的备份对象(例如,不同文件的备份).
POST /backups 用于创建新对象,如果始终创建新备份,则使用正确答案.
PUT /backups/id 如果要更新同一对象中的备份数据.

我相信POST /backup(备份所有资源)和POST /backup <id>(备份单个资源)将最适合您.
CRUD MAPPING:像Ray说的那样,备份不能很好地映射到CRUD; 您希望服务器上的操作资源执行该功能.MarkMassé撰写了关于REST API设计的O'Reilly书籍,他建议在这种情况下在服务器上使用动作资源(参见Action原型的幻灯片20).
URI DESIGNATION:操作资源应该是URI的最后一段,没有子资源.当您在下面看到最适合哪种HTTP方法的原因时,这将是有意义的.
HTTP方法:备份不应该是幂等操作,因此您希望HTTP方法不是幂等的.那POST.不仅是PUT是幂等的,你指定的URI就是放置你发送的资源的地方.如果你想要安宁,你不想这样做.POST的一部分目的及其非幂等性被指定为
提供数据块,例如提交表单的结果,到数据处理过程
这就是你想要的.
REST: 要成为一个分层系统,服务器(通过其动作资源(备份方法))应指定其输出应该去的位置; 客户不应该掌握这种逻辑.
因此,通过这种方式,您的备份操作资源可以自由决定您要将备份放在何处(可能是商店资源(/backups);请参阅幻灯片19)以及是否要覆盖以前的备份或是否要实现某种形式的版本控制(REST设计不考虑的东西).所以基本上你是在正确的轨道上!