导数: derivatives 二阶导数: second derivative N阶导数: Nth derivative 对某一特定的点求导数: derivative at a point 偏导数: partial derivative 隐函数求导: implicit derivative 二阶隐函数求导: second implicit derivative 曲线斜率: curved line slope 极值点: extreme point 极限: limits (函数的)收敛(性): convergence 泰勒展开式: Taylor series 洛必达法则: L'Hôpital's rule 积分: integral 不定积分: indefinite integral 定积分: definite integral 反常积分: improper integral 积分的原函数: antiderivative (anti-反导数, O(∩_∩)O哈哈~) 二重积分: double integral 三重积分: triple integral 多重积分: multi ...

0x00 C++ 内存管理机制 0x00 内存布局 如图： 从低地址到高地址（从下往上）依次为： Text Segment（代码段）: 英文也可以写为code segment，包含了程序的可执行代码，通常此段是可共享的，以便同样的可执行代码只需要在内存中存储一遍，同时此段是只读的，以防止程序分配内存时将其覆写。 Initialized Data Segment（初始化数据段）: 有时英文也简写为data segment，用来存放程序的全局变量以及静态变量， 此段可进一步被分为初始化只读区域（initialized read-only area）以及初始化可写区域（initialized read-write area），例如如下两个全局变量： 12const char * str = "Hello World"; // 将会存储在初始化只读区域char * str = "Hello World"; // 将会存储在初始化可写区域 Uninitialized Data Segment（未初始化数据段）: 又称为bss段，此段数据将 ...

Statelessness 依据REST架构，服务端不应当存储任何客户端session以及其他客户端状态信息。这个限制就叫做无状态（Statelessness）。从客户端发送到服务端的每一个请求必需包含服务端理解请求所需的全部信息，并且不能使用任何存储在服务端的上下文。session状态必需全部存储于客户端。客户端负责存储和维护所有的应用程序状态信息。 这同样意味着客户端需要向服务端发送所有状态信息，不管服务端是不是都用得上。同时不应当在服务端和session之间存在任何关联。 无状态意味着每个HTTP请求都是完全独立的。当客户端发送一个HTTP请求时，它应当包括服务端处理请求所需的所有的信息。服务端绝不依赖于任何之前的请求所包含的信息。如果（之前的请求所包含的）信息足够重要的话，客户端应当将其打包至当前请求中再发送一遍。 为了确保客户端可以使用这些无状态的API，服务端返回数据时，应当告知客户端需要创建哪些状态。 为了保持无状态，不要在服务端存储任何客户端的认证和授权信息，要在客户端发送的API请求中附带这些授权凭证。每一个请求必需保持独立并不受当前客户端之前会话的影响。 App ...

REST API Versioning 版本控制可帮助您在识别所需更改时快速迭代。 随着你的知识面以及系统的提升，API的修改是不可避免的。当它打破了现有客户端的整合时，管理这种变化带来的影响可能是一个挑战。 When to Version 当发生重大更改之后，API需要提升版本号。重大更改一般是指以下情况 返回数据格式的变化 返回值数据类型的变化（比如从整数变为浮点数） 从当前API中移除任一部分 重大更改后应当修改API的主要版本号或者内容响应类型 非重大更改，例如增加一个新的终结点或者新的响应参数，不应当修改主要的版本号。然而，当进行更改以支持客户可能遇到的一些问题时，比如收到缓存后的数据或者其他的一些API问题，跟踪这些次要版本的API可能会有很大帮助。 How to Version REST并没有提供任何特定的版本控制方法，但是通常情况下会从下面3个角度来进行版本控制： URI Versioning 在URI中直接进行版本控制是目前最常用的方法，但是其违反了URI必需用来定义唯一资源的准则。当版本更新时，这同样会打破客户端的集成。 例如： 12http://api.e ...

REST API Security Essentials 安全永远不是事后才考虑的。它必须是任何开发项目以及REST API的组成部分。有多种方法来保卫RESTful API，例如basic auth, OAuth等等。但是要记住一件事就是RESTful API必需是无状态的，所以请求的认证和授权必须不能依赖cookie或者session。相反，每个API请求必须带有一些授权信息，服务端每次收到请求后都要去验证这些信息。 REST Security Design Principles 这篇论文“The Protection of Information in Computer Systems” by Jerome Saltzer and Michael Schroeder提出了8条用于保持计算机系统内信息安全的原则，如下： **最小权限（Least Privilege）：**一个实体应当仅有其操作所需的最小权限。只有当实体需要某个权限的时候才授权给它，当其不需要某个权限的时候要即时撤销权限 安全设置缺省值（Fail-Safe Defaults）: 一个用户对系统内任意资源的默认访问 ...

Idempotent REST APIs 在REST API上下文中，当发送的多个请求产生的效果和一个请求相同时，这个REST API就是幂等的（idempotent）。 当你设计一个REST API的时候，你必需意识到使用API的人是可能会犯错误的。他们写出来的客户端代码，可能会将一个请求发送多遍，这些重复的请求可能是在无意间发出来的（例如，客户端程序错误），当然有时也是故意发送的（例如，网络超时）。你应当设计一个具有容错性的API使得当重复请求发生时并不会使系统变得不稳定。 一个幂等的HTTP方法是那种当被请求多次时并不会产生不同结果的HTTP方法。这与这个方法到底被请求了多少遍没有关系。结果应该是相同的。简要来说，这意味着请求成功执行的结果与执行次数无关。举个例子，在数学里，把0加到任意一个数字的操作都是幂等的。 如果你遵循REST准则来设计API，你将有如下的几个幂等的REST API， GET, PUT, DELETE, HEAD, OPTIONS以及TRACE。只有POST API不是幂等的。 POST不是幂等的 GET, PUT, DELETE, HEAD, OPT ...

HATEOAS Driven REST APIs HATEOAS (Hypermedia as the Engine of Application State 使用超媒体作为应用状态引擎) 是REST应用程序架构的约束之一，用来保证RESTful体系结构与其他网络应用体系结构之间的独特性。这个术语“hypermedia”指的是任何包含一个超链接或者其他媒体形式（诸如图像、电影或者文本）的内容。 这个体系结构允许你在响应体中使用超链接，以便客户端可以通过超链接动态定向到所需要的资源。这在概念上等价于web用户通过点击web页面上的超链接来到达其想要的页面或寻求期望的信息。 例如，下面的是对请求HTTP GET http://api.domain.com/management/departments/10的一个JSON响应体： 12345678910111213{ "departmentId": 10, "departmentName": "Administration", "location ...

REST – Content Negotiation 一般情况下，资源可以有多种表示，最主要的原因是因为它可能由不同的客户端请求不一样的表现层。客户端请求一个合适的资源表现层就被称为内容协商（content negotiation）。 HTTP规定了集中内容协商机制——当可以获取多种资源的表述层时，为给定的响应选择最佳的资源表述层的方法。 ——RFC 2616 Server-driven Vs Agent-driven Content Negotiation 如果是由服务端通过算法来为一个响应选取最佳资源表现层的话，那么这就被称为服务端驱动内容协商。如果由客户端或代理人来进行选取，则被称为代理人驱动内容协商。 事实上，你不会找到很多服务端驱动内容协商的例子，因为如果使用这种方法的话，你需要对客户端期望的内容形式做太多的假设。有关客户端上下文以及客户端如何处理资源表现层是（服务端）几乎不可能确定的。这种实现方法除了会让服务端变得复杂以外，同样也是没必要的。 所以大多数的REST API实现基于客户端驱动的内容协商。客户端驱动的内容协商依赖于HTTP请求头的使用或者资源的URI。 ...

REST Resource Representation Compression REST API可以通过XML, JSON, HTML甚至超文本等多种格式来返回一个资源的表述层。所有的返回数据格式均可以被压缩以节省网络带宽。不同的协议使用不同的技术来启用压缩并且告诉客户端其使用何种压缩方式，以便客户端可以在使用这些资源表述层之前解压它们。 压缩，或者加密，往往发生在表述层转移中，并且在客户端使用资源表述层的之前将其解压（或解密） HTTP是目前REST使用最广泛的协议，所以在这里将用压缩HTTP响应来举个例子。 Compression Related Request/Response Headers Accept-Encoding 当请求一个资源表述层的时候，随着客户端发出一个HTTP请求，Accept-Encoding 请求头就会指示客户端可以接受哪种压缩算法。 Accept-Encoding 两个标准值为compress和gzip。 一个带有accept-encoding请求头的示例请求如下： 1234GET /employees HTTP/1. ...

Caching REST API Response 缓存是服务端在请求-响应路径中用来存储一份经常访问的数据的副本的功能。当一个用户请求一个资源的表现层时，请求通过缓存或多级缓存（本地缓存、代理缓存、反向代理）走向托管资源的服务。如果任何一级缓存拥有请求路径的资源表现层的新鲜副本的话，那么这份副本将会用来响应这个请求。如果所有缓存都不能满足这个请求，这个请求将一路传送至服务层（源服务器）。 在HTTP请求头中，源服务器说明一个响应是不是可缓存的，如果是的话，由谁来缓存，缓存的有效期是多少。在响应路径中，缓存可以将响应信息做一个副本，当然前提是缓存数据的metadata允许他们这么做。 可以使用如下的方法来使用缓存优化网络来提高整体的服务质量 减少带宽 降低延迟 减轻服务器负载 隐藏网络失败 译者注： 此处的减少带宽指的是，减少数据传输量（带宽使用）以提升服务的质量。 具体做法可参考文章Bandwidth and Data Transfer 摘抄其中一段： How can I reduce my “bandwidth usage”? 我怎么样才能降低我的带宽使用呢？ You cer ...