使用网络的第一步是将数据发送到服务器应用程序。 而且，如果可以将一小行的解析过程委托给框架，那么下载文件呢？
让我们以PHP为例，尽管该描述适用于99％的其他语言和技术。 假设我们希望允许用户将图片上传到站点，为此我们制作了一个带有类型为file的字段的表单，并且...从表面上看，一切都很简单，表单和代码中的几个字节已更改，但是现在您可以使用文件而不是表单中的文本了！ 但是，并不是所有的事情都那么简单，您的文件必须首先在/ tmp /中放置在某个位置，直到请求完全到达为止，您的脚本根本无法控制，您对此也无能为力。 例如，用户上传的是exe文件，而不是图片，但是只有在最终完成下载后，您才能找到它。 因此，攻击者可能会在一段时间内锤击您的磁盘子系统的频道和时间，假装加载有用的文件，而您甚至根本不知道。 如果缓存服务器位于应用程序服务器的前面，则情况甚至更糟：例如，nginx创建临时文件，即 首先，来自用户的请求将放置在磁盘上，完成后，将重新读取该文件并将其快速提供给应用程序服务器（在我们的示例中为php），然后将其再次保存到磁盘。 即使用户只需要显示消息“您忘记了输入验证码”，磁盘的总使用率却达到三倍。
我并不是在说用这种方法无法完成更多有趣的事情。 像“文件上传进度栏”这样的简单功能将不可用。 有关更复杂的示例：Youtube显示仍在加载但未完全加载的电影中的帧。 在下载整个电影（例如2 GB）之前，您将无法获得任何控制（甚至没有通知！）。 您甚至都不知道有人吃掉了1.5 GB的磁盘，但是随后关闭了浏览器或单击浏览器中的“刷新”按钮，而无需等待任何操作。
当然，曲折程度各不相同，可以解决典型任务，例如作为Web服务器模块实现的“通过json接收请求统计信息”，但是您必须自己做这些事情，并且/或者因此必须附加到环境中，应用程序不再是独立的。并依赖于特定的应用程序及其库。
快取
缓存至关重要。 缓存技术使您可以加快站点的响应速度并减少站点的负载，从而无需对许多请求执行相同的操作。 例如，有多少个不做2 + 2，总有4个，但是计算2 + 2占用服务器资源，则在第一个访问者到达时，一次计算此值，然后在某处写入，以便将该其他用户分配出去，这样会更有利可图。结果。
不要将此缓存与HTTP标头混淆，它们仅对特定的客户端有效（在原始客户端中也对中间代理有效），而在服务器上的缓存旨在为许多用户提供相同的内容。
遗憾的是，对中间服务器进行缓存是无利可图的，如果在页面上进行最细微的更新，则必须从头开始创建页面，并且在现代现实中，当页面上有很多动态元素时，实际上每个页面都是唯一的，而另一方面，请求格式为GET / somepage.html？someshit = 12345将突破高速缓存，并且将形成一个甚至不考虑此参数的新页面，但是创建该页面会产生成本，攻击者可以再次使用它。 因此，很少有人使用中间缓存服务器，并且已经很难依靠它们。
它仍然可以缓存应用程序内部的所有内容，几乎每个框架都提供自己的拐杖，以及像各种便条纸和现成的东西这样的现成拐杖。 通常，新手开发人员在发现生成页面时，可以在沸腾的水中写东西，因为您可以向memcached发出500个请求，并且没有任何用处（不同于每个人都喜欢的mysql）。 结果，所有代码都被包装器覆盖，这些包装器首先在memcashd中检查请求的结果，然后将结果爬到mysql中。 我不认为必须手动控制缓存，但是完全手动控制会导致可能的错误，在这里您可以简单地忘记打开缓存，根据平均律，这将是至关重要的地方。
介面
该网站应具有什么界面？ 只是不要说绿色。
以前，通常，网站的展示是单一且不可分割的。 但是，在大型门户网站上，有“打印版本”，甚至是“ wap版本”按钮，后来被“ PDA版本”代替-PDA版本已经是纯HTML，只是更简单。 尽管取决于位置，但如果您使用Twitter，则这是它的唯一可读版本。 时间流逝，不仅需要编辑打印机和电话的站点，还需要编辑所有支持HTML5的iPad和冰箱的站点。 自然，这一切都吸引了开发人员，因为他们实际上必须每个站点都制作10个版本，并且他们决定做一些通用的事情。 该网站的一种API。
什么是API-我不知道。 老实说，我不知道。 通常，当您在服务器上吐出一条带有urlencoded字符串的东西时，这种情况很糟糕，作为回报，您会得到一段json / xml /纯文本，这是多么幸运。 当然，没有标准，甚至是原始数据类型都不能是任何东西，空结果也可以是任何东西，从null到“”（空引号），甚至没有结果。 如果作者读到诸如REST之类的字眼并急于实现它，那是很好的，但是在其他背景下，这毫无意义。 功能也不清楚，如果通过请求HTML页面我们可以一次获得所有信息（最新新闻，评论，顶等），那么在使用API的情况下，我们需要进行多少次请求-只有该API的作者知道，这很可能可以收到评论，但喜欢他们-不。 实际上，API是一种将客户端和服务器开发分为完全不同的开发团队的方法，这些团队之间的交互很差。 也没有人谈论此API的有用性。
通常，访问API需要一定的密钥。 通常可以免费获得密钥。 为什么不得到这样的钥匙？ 问题在于，这导致我们对请求进行显式记帐，对内部进行一些记帐。 谁知道作者何时想通过所有这些货币获利？ 一段时间后，有可能会禁用或严重限制免费密钥，从而提供使用收费的收费方式。 有时通常会暂停所有密钥的发行，并停止服务，即使是在商业上也是如此。 那么，为什么要使用API？ 与忍受这样的耻辱相比，对我来说，拉长页面并用常客来解析它要容易得多。 因此，我几乎从不使用您的这些API，尤其是因为我将不处理它们的功能。