月度归档： 2020 年 5 月

常用的http状态码

一些常见的状态码为：
200 – 服务器成功返回网页 404 – 请求的网页不存在 503 – 服务不可用
1xx（临时响应）
表示临时响应并需要请求者继续执行操作的状态代码。

代码   说明
100   （继续） 请求者应当继续提出请求。 服务器返回此代码表示已收到请求的第一部分，正在等待其余部分。 
101   （切换协议） 请求者已要求服务器切换协议，服务器已确认并准备切换。

2xx （成功）
表示成功处理了请求的状态代码。

代码   说明
200   （成功）  服务器已成功处理了请求。 通常，这表示服务器提供了请求的网页。
201   （已创建）  请求成功并且服务器创建了新的资源。
202   （已接受）  服务器已接受请求，但尚未处理。
203   （非授权信息）  服务器已成功处理了请求，但返回的信息可能来自另一来源。
204   （无内容）  服务器成功处理了请求，但没有返回任何内容。
205   （重置内容） 服务器成功处理了请求，但没有返回任何内容。
206   （部分内容）  服务器成功处理了部分 GET 请求。

3xx （重定向）
表示要完成请求，需要进一步操作。 通常，这些状态代码用来重定向。

代码   说明
300   （多种选择）  针对请求，服务器可执行多种操作。 服务器可根据请求者 (user agent) 选择一项操作，或提供操作列表供请求者选择。
301   （永久移动）  请求的网页已永久移动到新位置。 服务器返回此响应（对 GET 或 HEAD 请求的响应）时，会自动将请求者转到新位置。
302   （临时移动）  服务器目前从不同位置的网页响应请求，但请求者应继续使用原有位置来进行以后的请求。
303   （查看其他位置） 请求者应当对不同的位置使用单独的 GET 请求来检索响应时，服务器返回此代码。
304   （未修改） 自从上次请求后，请求的网页未修改过。 服务器返回此响应时，不会返回网页内容。
305   （使用代理） 请求者只能使用代理访问请求的网页。 如果服务器返回此响应，还表示请求者应使用代理。
307   （临时重定向）  服务器目前从不同位置的网页响应请求，但请求者应继续使用原有位置来进行以后的请求。

4xx（请求错误）
这些状态代码表示请求可能出错，妨碍了服务器的处理。

代码   说明
400   （错误请求） 服务器不理解请求的语法。
401   （未授权） 请求要求身份验证。 对于需要登录的网页，服务器可能返回此响应。
403   （禁止） 服务器拒绝请求。
404   （未找到） 服务器找不到请求的网页。
405   （方法禁用） 禁用请求中指定的方法。
406   （不接受） 无法使用请求的内容特性响应请求的网页。
407   （需要代理授权） 此状态代码与 401（未授权）类似，但指定请求者应当授权使用代理。
408   （请求超时）  服务器等候请求时发生超时。
409   （冲突）  服务器在完成请求时发生冲突。 服务器必须在响应中包含有关冲突的信息。
410   （已删除）  如果请求的资源已永久删除，服务器就会返回此响应。
411   （需要有效长度） 服务器不接受不含有效内容长度标头字段的请求。
412   （未满足前提条件） 服务器未满足请求者在请求中设置的其中一个前提条件。
413   （请求实体过大） 服务器无法处理请求，因为请求实体过大，超出服务器的处理能力。
414   （请求的 URI 过长） 请求的 URI（通常为网址）过长，服务器无法处理。
415   （不支持的媒体类型） 请求的格式不受请求页面的支持。
416   （请求范围不符合要求） 如果页面无法提供请求的范围，则服务器会返回此状态代码。
417   （未满足期望值） 服务器未满足”期望”请求标头字段的要求。

5xx（服务器错误）
这些状态代码表示服务器在尝试处理请求时发生内部错误。 这些错误可能是服务器本身的错误，而不是请求出错。

代码   说明
500   （服务器内部错误）  服务器遇到错误，无法完成请求。
501   （尚未实施） 服务器不具备完成请求的功能。 例如，服务器无法识别请求方法时可能会返回此代码。
502   （错误网关） 服务器作为网关或代理，从上游服务器收到无效响应。
503   （服务不可用） 服务器目前无法使用（由于超载或停机维护）。 通常，这只是暂时状态。
504   （网关超时）  服务器作为网关或代理，但是没有及时从上游服务器收到请求。
505   （HTTP 版本不受支持） 服务器不支持请求中所用的 HTTP 协议版本。

RFC 6585 最近刚刚发布，该文档描述了 4 个新的 HTTP 状态码。

HTTP 协议还在变化？是的，HTTP 协议一直在演变，新的状态码对于开发 REST 服务或者说是基于 HTTP 的服务非常有用，下面我们为你详细介绍这四个新的状态码以及是否应该使用。

428 Precondition Required (要求先决条件)

先决条件是客户端发送 HTTP 请求时，如果想要请求能成功必须满足一些预设的条件。

一个好的例子就是 If-None-Match 头，经常在 GET 请求中使用，如果指定了 If-None-Match ，那么客户端只在响应中的 ETag 改变后才会重新接收回应。

先决条件的另外一个例子就是 If-Match 头，这个一般用在 PUT 请求上用于指示只更新没被改变的资源，这在多个客户端使用 HTTP 服务时用来防止彼此间不会覆盖相同内容。

当服务器端使用 428 Precondition Required 状态码时，表示客户端必须发送上述的请求头才能执行请求，这个方法为服务器提供一种有效的方法来阻止 ‘lost update’ 问题。

429 Too Many Requests (太多请求)

当你需要限制客户端请求某个服务数量时，该状态码就很有用，也就是请求速度限制。

在此之前，有一些类似的状态码，例如 ‘509 Bandwidth Limit Exceeded’. Twitter 使用 420 （这不是HTTP定义的状态码）

如果你希望限制客户端对服务的请求数，可使用 429 状态码，同时包含一个 Retry-After 响应头用于告诉客户端多长时间后可以再次请求服务。

431 Request Header Fields Too Large (请求头字段太大)

某些情况下，客户端发送 HTTP 请求头会变得很大，那么服务器可发送 431 Request Header Fields Too Large 来指明该问题。

我不太清楚为什么没有 430 状态码，而是直接从 429 跳到 431，我尝试搜索但没有结果。唯一的猜测是 430 Forbidden 跟 403 Forbidden 太像了，为了避免混淆才这么做的，天知道！

511 Network Authentication Required (要求网络认证)

对我来说这个状态码很有趣，如果你在开发一个 HTTP 服务器，你不一定需要处理该状态码，但如果你在编写 HTTP 客户端，那这个状态码就非常重要。

如果你频繁使用笔记本和智能手机，你可能会注意到大量的公用 WIFI 服务要求你必须接受一些协议或者必须登录后才能使用。

这是通过拦截HTTP流量，当用户试图访问网络返回一个重定向和登录，这很讨厌，但是实际情况就是这样的。

使用这些“拦截”客户端，会有一些讨厌的副作用。在 RFC 中有提到这两个的例子：

  • 如果你在登录WIFI前访问某个网站，网络设备将会拦截首个请求，这些设备往往也有自己的网站图标 ‘favicon.ico’。登录后您会发现，有一段时间内你访问的网站图标一直是WIFI登录网站的图标。
  • 如果客户端使用HTTP请求来查找文档（可能是JSON），网络将会响应一个登录页，这样你的客户端就会解析错误并导致客户端运行异常，在现实中这种问题非常常见。

因此 511 状态码的提出就是为了解决这个问题。

如果你正在编写 HTTP 的客户端，你最好还是检查 511 状态码以确认是否需要认证后才能访问。

100Continue继续。客户端应继续其请求
101Switching Protocols切换协议。服务器根据客户端的请求切换协议。只能切换到更高级的协议，例如，切换到HTTP的新版本协议
200OK请求成功。一般用于GET与POST请求
201Created已创建。成功请求并创建了新的资源
202Accepted已接受。已经接受请求，但未处理完成
203Non-Authoritative Information非授权信息。请求成功。但返回的meta信息不在原始的服务器，而是一个副本
204No Content无内容。服务器成功处理，但未返回内容。在未更新网页的情况下，可确保浏览器继续显示当前文档
205Reset Content重置内容。服务器处理成功，用户终端（例如：浏览器）应重置文档视图。可通过此返回码清除浏览器的表单域
206Partial Content部分内容。服务器成功处理了部分GET请求
300Multiple Choices多种选择。请求的资源可包括多个位置，相应可返回一个资源特征与地址的列表用于用户终端（例如：浏览器）选择
301Moved Permanently永久移动。请求的资源已被永久的移动到新URI，返回信息会包括新的URI，浏览器会自动定向到新URI。今后任何新的请求都应使用新的URI代替
302Found临时移动。与301类似。但资源只是临时被移动。客户端应继续使用原有URI
303See Other查看其它地址。与301类似。使用GET和POST请求查看
304Not Modified未修改。所请求的资源未修改，服务器返回此状态码时，不会返回任何资源。客户端通常会缓存访问过的资源，通过提供一个头信息指出客户端希望只返回在指定日期之后修改的资源
305Use Proxy使用代理。所请求的资源必须通过代理访问
306Unused已经被废弃的HTTP状态码
307Temporary Redirect临时重定向。与302类似。使用GET请求重定向
400Bad Request客户端请求的语法错误，服务器无法理解
401Unauthorized请求要求用户的身份认证
402Payment Required保留，将来使用
403Forbidden服务器理解请求客户端的请求，但是拒绝执行此请求
404Not Found服务器无法根据客户端的请求找到资源（网页）。通过此代码，网站设计人员可设置”您所请求的资源无法找到”的个性页面
405Method Not Allowed客户端请求中的方法被禁止
406Not Acceptable服务器无法根据客户端请求的内容特性完成请求
407Proxy Authentication Required请求要求代理的身份认证，与401类似，但请求者应当使用代理进行授权
408Request Time-out服务器等待客户端发送的请求时间过长，超时
409Conflict服务器完成客户端的 PUT 请求时可能返回此代码，服务器处理请求时发生了冲突
410Gone客户端请求的资源已经不存在。410不同于404，如果资源以前有现在被永久删除了可使用410代码，网站设计人员可通过301代码指定资源的新位置
411Length Required服务器无法处理客户端发送的不带Content-Length的请求信息
412Precondition Failed客户端请求信息的先决条件错误
413Request Entity Too Large由于请求的实体过大，服务器无法处理，因此拒绝请求。为防止客户端的连续请求，服务器可能会关闭连接。如果只是服务器暂时无法处理，则会包含一个Retry-After的响应信息
414Request-URI Too Large请求的URI过长（URI通常为网址），服务器无法处理
415Unsupported Media Type服务器无法处理请求附带的媒体格式
416Requested range not satisfiable客户端请求的范围无效
417Expectation Failed服务器无法满足Expect的请求头信息
500Internal Server Error服务器内部错误，无法完成请求
501Not Implemented服务器不支持请求的功能，无法完成请求
502Bad Gateway作为网关或者代理工作的服务器尝试执行请求时，从远程服务器接收到了一个无效的响应
503Service Unavailable由于超载或系统维护，服务器暂时的无法处理客户端的请求。延时的长度可包含在服务器的Retry-After头信息中
504Gateway Time-out充当网关或代理的服务器，未及时从远端服务器获取请求
505HTTP Version not supported服务器不支持请求的HTTP协议的版本，无法完成处理

软件设计六大原则

软件设计六大原则

1. 单一职责原则（Single Responsibility Principle – SRP）

原文：There should never be more than one reason for a class to change.

译文：永远不应该有多于一个原因来改变某个类。

理解：对于一个类而言，应该仅有一个引起它变化的原因。说白了就是，不同的类具备不同的职责，各施其责。这就好比一个团队，大家分工协作，互不影响，各做各的事情。

应用：当我们做系统设计时，如果发现有一个类拥有了两种的职责，那就问自己一个问题：可以将这个类分成两个类吗？如果真的有必要，那就分吧。千万不要让一个类干的事情太多！

2. 开放封闭原则（Open Closed Principle – OCP）

原文：Software entities like classes, modules and functions should be open for extension but closed for modifications.

译文：软件实体，如：类、模块与函数，对于扩展应该是开放的，但对于修改应该是封闭的。

理解：简言之，对扩展开放，对修改封闭。换句话说，可以去扩展类，但不要去修改类。开放封闭原则，是最为重要的设计原则，Liskov替换原则和合成/聚合复用原则为开放封闭原则的实现提供保证。

应用：当需求有改动，要修改代码了，此时您要做的是，尽量用继承或组合的方式来扩展类的功能，而不是直接修改类的代码。当然，如果能够确保对整体架构不会产生任何影响，那么也没必要搞得那么复杂了，直接改这个类吧。

3. 里氏替换原则（Liskov Substitution Principle – LSP）

原文：Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it.

译文：使用基类的指针或引用的函数，必须是在不知情的情况下，能够使用派生类的对象。

理解：父类能够替换子类，但子类不一定能替换父类。也就是说，在代码中可以将父类全部替换为子类，程序不会报错，也不会在运行时出现任何异常，但反过来却不一定成立。

应用：在继承类时，务必重写（Override）父类中所有的方法，尤其需要注意父类的 protected 方法（它们往往是让您重写的），子类尽量不要暴露自己的 public 方法供外界调用。

4. 最少知识原则（Least Knowledge Principle – LKP）

原文：Only talk to you immediate friends.

译文：只与你最直接的朋友交流。

理解：尽量减少对象之间的交互，从而减小类之间的耦合。简言之，一定要做到：低耦合，高内聚。

应用：在做系统设计时，不要让一个类依赖于太多的其他类，需尽量减小依赖关系，否则，您死都不知道自己怎么死的。

5. 接口隔离原则（Interface Segregation Principle – ISP）

原文：The dependency of one class to another one should depend on the smallest possible interface.

译文：一个类与另一个类之间的依赖性，应该依赖于尽可能小的接口。

理解：不要对外暴露没有实际意义的接口。也就是说，接口是给别人调用的，那就不要去为难别人了，尽可能保证接口的实用性吧。她好，我也好。

应用：当需要对外暴露接口时，需要再三斟酌，如果真的没有必要对外提供的，就删了吧。一旦您提供了，就意味着，您将来要多做一件事情，何苦要给自己找事做呢。

6. 依赖倒置原则（Dependence Inversion Principle – DIP）

原文：High level modules should not depends upon low level modules. Both should depend upon abstractions. Abstractions should not depend upon details. Details should depend upon abstractions.

译文：高层模块不应该依赖于低层模块，它们应该依赖于抽象。抽象不应该依赖于细节，细节应该依赖于抽象。

理解：应该面向接口编程，不应该面向实现类编程。面向实现类编程，相当于就是论事，那是正向依赖（正常人思维）；面向接口编程，相当于通过事物表象来看本质，那是反向依赖，即依赖倒置（程序员思维）。

应用：并不是说，所有的类都要有一个对应的接口，而是说，如果有接口，那就尽量使用接口来编程吧。

总结

将以上六大原则的英文首字母拼在一起就是 SOLID（稳定的），所以也称之为 SOLID 原则。只有满足了这六大原则，才能设计出稳定的软件架构！但它们毕竟只是原则，只是给我们的建议，有些时候我们还是要学会灵活应变，千万不要生搬硬套，否则只会把简单问题复杂化

补充设计原则

1. 组合/聚合复用原则（Composition/Aggregation Reuse Principle – CARP）

 当要扩展类的功能时，优先考虑使用组合，而不是继承。这条原则在 23 种经典设计模式中频繁使用，如：代理模式、装饰模式、适配器模式等。可见江湖地位非常之高！

2. 无环依赖原则（Acyclic Dependencies Principle – ADP）

当 A 模块依赖于 B 模块，B 模块依赖于 C 模块，C 依赖于 A 模块，此时将出现循环依赖。在设计中应该避免这个问题，可通过引入“中介者模式”解决该问题。

3. 共同封装原则（Common Closure Principle – CCP）

应该将易变的类放在同一个包里，将变化隔离出来。该原则是“开放-封闭原则”的延生。

4. 共同重用原则（Common Reuse Principle – CRP）

如果重用了包中的一个类，那么也就相当于重用了包中的所有类，我们要尽可能减小包的大小。

5. 好莱坞原则（Hollywood Principle – HP）

好莱坞明星的经纪人一般都很忙，他们不想被打扰，往往会说：Don’t call me, I’ll call you. 翻译为：不要联系我，我会联系你。对应于软件设计而言，最著名的就是“控制反转”（或称为“依赖注入”），我们不需要在代码中主动的创建对象，而是由容器帮我们来创建并管理这些对象。

其它设计原则

1. 不要重复你自己（Don’t repeat yourself – DRY）

不要让重复的代码到处都是，要让它们足够的重用，所以要尽可能地封装。

2. 保持它简单与傻瓜（Keep it simple and stupid – KISS）

不要让系统变得复杂，界面简洁，功能实用，操作方便，要让它足够的简单，足够的傻瓜。

3. 高内聚与低耦合（High Cohesion and Low Coupling – HCLC）

模块内部需要做到内聚度高，模块之间需要做到耦合度低。

4. 惯例优于配置（Convention over Configuration – COC）

尽量让惯例来减少配置，这样才能提高开发效率，尽量做到“零配置”。很多开发框架都是这样做的。

5. 命令查询分离（Command Query Separation – CQS）

在定义接口时，要做到哪些是命令，哪些是查询，要将它们分离，而不要揉到一起。

6. 关注点分离（Separation of Concerns – SOC）

将一个复杂的问题分离为多个简单的问题，然后逐个解决这些简单的问题，那么这个复杂的问题就解决了。难就难在如何进行分离。

7. 契约式设计（Design by Contract – DBC）

模块或系统之间的交互，都是基于契约（接口或抽象）的，而不要依赖于具体实现。该原则建议我们要面向契约编程。

8. 你不需要它（You aren’t gonna need it – YAGNI）

不要一开始就把系统设计得非常复杂，不要陷入“过度设计”的深渊。应该让系统足够的简单，而却又不失扩展性，这是其中的难点。

里氏替换原则

里氏代换原则

里氏代换原则由2008年图灵奖得主、美国第一位计算机科学女博士Barbara Liskov教授和卡内基·梅隆大学Jeannette Wing教授于1994年提出。

严格表述

其严格表述如下：如果对每一个类型为S的对象o1，都有类型为T的对象o2，使得以T定义的所有程序P在所有的对象o1代换o2时，程序P的行为没有变化，那么类型S是类型T的子类型。

通俗表述

这个定义比较拗口且难以理解，因此我们一般使用它的另一个通俗版定义：里氏代换原则(Liskov Substitution Principle, LSP)：所有引用基类（父类）的地方必须能透明地使用其子类的对象。

里氏代换原则告诉我们，在软件中将一个基类对象替换成它的子类对象，程序将不会产生任何错误和异常，反过来则不成立，如果一个软件实体使用的是一个子类对象的话，那么它不一定能够使用基类对象。例如：我喜欢动物，那我一定喜欢狗，因为狗是动物的子类；但是我喜欢狗，不能据此断定我喜欢动物，因为我并不喜欢老鼠，虽然它也是动物。

例如有两个类，一个类为BaseClass，另一个是SubClass类，并且SubClass类是BaseClass类的子类，那么一个方法如果可以接受一个BaseClass类型的基类对象base的话，如：method1(base)，那么它必然可以接受一个BaseClass类型的子类对象sub，method1(sub)能够正常运行。反过来的代换不成立，如一个方法method2接受BaseClass类型的子类对象sub为参数：method2(sub)，那么一般而言不可以有method2(base)，除非是重载方法。

里氏代换原则是实现开闭原则的重要方式之一，由于使用基类对象的地方都可以使用子类对象，因此在程序中尽量使用基类类型来对对象进行定义，而在运行时再确定其子类类型，用子类对象来替换父类对象。

注意的地方

在使用里氏代换原则时需要注意如下几个问题：

(1)子类的所有方法必须在父类中声明，或子类必须实现父类中声明的所有方法。根据里氏代换原则，为了保证系统的扩展性，在程序中通常使用父类来进行定义，如果一个方法只存在子类中，在父类中不提供相应的声明，则无法在以父类定义的对象中使用该方法。

(2) 我们在运用里氏代换原则时，尽量把父类设计为抽象类或者接口，让子类继承父类或实现父接口，并实现在父类中声明的方法，运行时，子类实例替换父类实例，我们可以很方便地扩展系统的功能，同时无须修改原有子类的代码，增加新的功能可以通过增加一个新的子类来实现。里氏代换原则是开闭原则的具体实现手段之一。

(3) Java语言中，在编译阶段，Java编译器会检查一个程序是否符合里氏代换原则，这是一个与实现无关的、纯语法意义上的检查，但Java编译器的检查是有局限的。