我有一个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服务，但这是因为我打算从潜在的几十种其他服务中访问该服务，并且可能来自其他开发人员。所以即使开始时我只是使用它的几个项目，最终的目标需要一个更标准的接口。