ios - 干净的URL与查询的字符串-来 self 的iOS客户端的Web服务请求

Question

我一直在寻找明确的答案或解释，但找不到详尽的答案或解释。

我正在构建移动应用程序，该应用程序主要基于后端的数据。
我可以使用纯静态请求或带有查询字符串的请求来构造对服务器(基于php)的大多数请求。

2个问题:

1.假设我有一个 friend 类。我想认识或设置丹妮的 friend 。

休息时我会做:

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添加 friend 后，即使您有某种方式，您也必须告诉您的代理刷新好友列表的缓存)，因为它们是2不同的URI。在其余的情况下，它是通过定义http方法自动完成的(post/put使资源“变脏”)

我在这里吗？

我想知道什么是最好的选择:
高速缓存，安全性，单入口点(在php代码中)，simper实现(在客户端和服务器中)等等。

2.我将如何构造一个仅查找某些 friend 照片的URL？ (比方说某个位置的人。)

我想到了:

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

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

Answer 1

URL构建
关于REST URL构造要记住的最关键的事情之一是每个URL应该标识一个资源。通常，这意味着URL通常分为以下几部分:

顶级对象列表:/users和/photos

顶级对象实例:/users/1/Dani和/photos/4356

实例级别列表:

/users/1/Dani/friends-Dani的 friend

/users/1/Dani/photos-Dani的照片

资源交互
与这些资源进行交互(即创建，读取，更新，删除)是通过实际使用每个URL的“HTTP谓词”或“ HTTP Methods”进行的。这样做的好处是，您拥有的每个资源(或“事物”)只需要知道如何做4种不同的事情，这意味着您将拥有一个更加简单的应用程序。

您的应用程序也更加结构化和分区化，从而更易于测试，并允许您更轻松地对其进行更新和更改，因为事情之间的联系更加松散。

一旦在单个资源和单个URL之间没有清晰的1-1连接，就不再具有RESTful URL。一旦开始将诸如 action之类的内容放入查询字符串，则实际上是在进行远程过程调用(RPC)，而不是REST。流过中心点的所有事物都将事物组合在一起，超出了它们的实际需要，这使您的体系结构僵化，难以更改且非常难以测试。

搜索
诀窍在于，对于任何类型的“列表”类型资源，您都可以使该列表成为某种查询的结果。没有什么可以说列表总是必须相同的。使用 http://www.example.com/Dani/friends?long=1&lat=2&field=photos并没有任何意义，因为这将为您返回Dani的 friend 的照片列表，而这些照片与用户Dani相距甚远。

由于您正在寻找照片，并且我们已经有了一个标识“照片列表”资源的URL，这就是我们应该使用的URL，只是为了获得具有某些属性的照片。

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

GET /photos?owner=[userId]

并且您可能只寻找距离经纬度1公里以内拍摄的照片:

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

或者，如果您的视野更广一些，也许您想要该地区所有Dani friend 的照片:

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

在所有这些情况下，您都是根据要发送到照片列表的查询字符串(位于 /photos)搜索照片列表。

缓存
缓存只是“额外的好处”。从理论上讲，几乎所有请求都可以缓存，但是您现在不必担心。但是，总的来说，如果您坚持使用REST架构，那么在时机成熟时会没事的。

安全
HTTP有许多内置的安全性处理方式，其中任何一种都可以使用，具体取决于您的应用程序的安全性。基本安全性和摘要安全性对于应用程序到应用程序的通信非常有效，因为它们将身份验证 token (即用户名和密码)与请求一起发送。但是，对于涉及用户的安全性流程，您可能希望使用Session机制并使用HTTP Cookie header 来跟踪 session 。

但是，在所有情况下，无论何时用户名/密码从客户端移至服务器，都应通过安全的SSL(https)连接，以防止恶意行为者监听它。对于特别敏感的应用程序，所有交互都可以通过SSL连接进行，对于其他应用程序，只能进行登录顺序。但是，总的来说，更安全总比不安全要好。

实现简单
在安全性方面，大多数Web框架都有内置的方法，可以处理我刚才提到的所有安全性方法。您可能想知道是否需要使用Web框架，尽管它不是严格要求的，但它将大大减少您必须做的工作量，同时也将减少错误的数量，因为大多数框架处理了“繁重的工作”，并进行了很好的测试。

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

从长远来看，通过使用RESTful架构，您可能会付出更多的努力。