清理URL与查询字符串 - 来自我的iOS客户端的Web服务请求

Question

我一直在寻找一个明确的答案或解释,但找不到彻底的答案或解释.

我正在构建移动应用程序,它主要基于我后端的数据.我可以使用纯粹的restful请求或带有查询字符串的请求将我的大部分请求构建到我的服务器(基于php).

2个问题:

我们说我有一个朋友班.我想得到或设置Dani的朋友.

休息时我会这样做:

http://www.example.com/Dani/friends - GET (to get all his friends)
http://www.example.com/Dani/friends - POST (to create a new friend for Dani)

使用查询字符串:

Http://www.example.com/ user=Dani & action=get_friends (GET method I assume?)
http://www.example.com/ user=Dani & action=add_friend (POST method I assume?)

所以,对于第一个例子,我们有缓存,加上一个常量非常易读的URL.

在第二个,我们没有真正的缓存(即使有,你不知何故必须告诉你的代理刷新朋友列表的缓存,在一个调用第二个URL添加朋友后),因为那些是2不同的URI.在休息时,它是通过定义http方法自动完成的(post/put使资源"脏")

我在这儿吗？

我想知道什么是最好的选择:缓存方式,安全性,单点入口(在PHP代码中),简化实现(在客户端和服务器中)等等......

2.我如何构建一个网址才能找到某些朋友的照片？ (让我们说某个地方的那些.)

我想到了:

http://www.example.com/Dani/friends?long=1&lat=2&field=photos

这是对的,还是有更好的方法？

Answer 1

URL构建
要记住REST URL构造的最重要的事情之一是每个URL应该标识单个资源.通常,这意味着URL通常分为几部分:

1. 顶级对象列表:/users和/photos
2. 顶级对象实例:/users/1/Dani和/photos/4356
3. 实例级列表:
   • /users/1/Dani/friends - Dani的朋友们
   • /users/1/Dani/photos - Dani的照片

资源交互
通过"HTTP谓词"或实际调用每个URL 的" HTTP方法 " 来处理与这些资源的交互(即创建,读取,更新,删除).这样做的好处是每个资源(或"东西")只需要知道如何做4种不同的事情,这意味着你有一个更简单的应用程序.

您的应用程序也更加结构化和划分,使其更容易测试,并允许您更容易地更新和更改它,因为事情更松散耦合.

一旦您在单个资源和单个URL之间没有明确的1-1连接,就不再拥有RESTful URL.一旦开始将类似内容action放入查询字符串中,您实际上是在进行远程过程调用(RPC)而不是REST.流经中心点的一切都将事物耦合在一起,而不是它们需要的东西,这使得你的建筑变得僵硬,难以改变,而且很难测试.

搜索
技巧是,对于任何类型的"列表"类型资源,您可以将该列表作为某种查询的结果.没有什么可以说列表总是必须相同.使用起来没有意义,http://www.example.com/Dani/friends?long=1&lat=2&field=photos因为这会让你回到Dani的朋友的照片列表,这些照片离Dani用户相当远.

由于您正在寻找照片,我们已经有一个标识"照片列表"资源的网址,这是我们应该使用的网址,但只是为了获取具有特定属性的照片.

因此,对于您查找属于某个用户(可能是Dani的朋友之一)的所有照片的示例,您可能会执行以下操作:

GET /photos?owner=[userId]

你也许只能在一些纬度/经度坐标的1公里范围内查找照片:

GET /photos?owner=[userId]&radius=1&lat=[someLat]&long=[someLong]

或者,如果你看得更广泛一些,也许你想要那个区域所有 Dani朋友的照片:

GET /photos?ownerFriendOf=[Dani's userId]&radius=1&lat=[someLat]&long=[someLong]

在所有这些情况下,您将根据要发送到照片列表的查询字符串搜索照片列表./photos

缓存
缓存只是一个"额外的奖励".理论上,几乎任何请求都可以缓存,但您现在不需要担心.但是,一般情况下,如果您坚持使用REST架构,那么一旦时机成熟,您将会很好.

安全
HTTP有许多处理安全性的内置方法,其中任何一种都可以工作,具体取决于您需要应用程序的安全性.基本和摘要安全性适用于应用程序到应用程序的通信,因为它们与请求一起发送其身份验证令牌(即用户名和密码).但是,对于涉及用户的安全流,您可能希望使用会话机制并使用HTTP Cookie标头来跟踪会话.

但是,在所有情况下,只要用户名/密码从客户端移动到服务器,就应该通过安全的SSL(https)连接来防止恶意者嗅探它.对于特别敏感的应用程序,所有交互可以通过SSL连接,而对于其他应用程序,只有登录序列可能是.然而,一般而言,更安全更好.

实现简单性
在安全方面,大多数Web框架都有内置方法,可以处理我刚才提到的所有安全方法.您可能想知道是否需要使用Web框架,虽然不是严格要求,但它会大大减少您必须完成的工作量,同时它会减少错误的数量,因为大多数错误"繁重的工作"由框架处理,并经过了很好的测试.

如今,许多框架都内置了对处理RESTful请求的支持,您可以快速启动并运行.基于RPC的支持通常支持较少,因为它没有像REST那样明确定义的应用程序体系结构,但几乎任何框架都可以实现.

但是,从长远来看,通过使用RESTful架构,您可能会获得更多的收益.