我有一个Web应用程序使用AJAX从服务器抓取JSON数据。它要求用户首先使用其浏览器登录,以便可以设置cookie。只使用GET和POST动词,其中GET用于检索数据,POST用于修改数据的任何操作。
从我的理解,REST不同于上述方法,用户认证信息与每个请求一起发送,并且PUT和DELETE动词也被使用。
我的问题是,如果终点只是一个用户的浏览器,REST Web服务对RPC类方法有什么好处?我可以理解当客户端未知时如何REST是有益的,但是当我只使用jQuery ajax调用时,是否仍然值得一个类似RPC的方法的好处?
解决方法
REST和RPC之间的一个巨大差异是REST是所有关于资源,而RPC更多的是关于操作。例如,使用真正的RESTful服务,你永远不会调用像
http://domain.com/service/User/jason/add或
http://domain.com/service/User/addUser?username=jason.对于RESTful服务,你只能引用URL中的资源,然后使用HTTP动词和请求的主体定义对该资源做什么。因此,对http:/domain.com/service/jason的GET请求应该返回有关资源(jason用户)的信息。你可以得到更具体,说
http://domain.com/service/user/jason,但结果应该是一样的。如果您添加一个名为jason的用户,您将使用完全相同的URL
http://domain.com/service/user/jason,但您将使用PUT动词,并且请求的正文将包含其他数据。要删除jason资源,您将再次使用完全相同的URL(http://domain.com/service/user/jason)并使用DELETE动词。要更新,您将使用POST动词。
REST是伟大的面向公众的API,您打算供其他开发人员使用。它们可以被制成非常标准,使得它们不需要大量关于使用服务的预先存在的知识。没有WSDL调用等。由于无状态,它也可以使它们在部分网络故障期间更稳定。
从你所描述的,我不认为你需要一个真正的RESTful服务。但是,如果你需要一个更标准的API,你可能需要考虑。我为一个仅用于内部使用的项目制定了REST服务,但这是因为我打算从潜在的几十种其他服务中访问该服务,并且可能来自其他开发人员。所以即使开始时我只是使用它的几个项目,最终的目标需要一个更标准的接口。