ARTS-No.6

Algorithm

27. 移除元素

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
class Solution {
public int removeElement(int[] nums, int val) {
if (nums == null) {
return 0;
}

int insertIndex = 0;
for (int i = 0; i < nums.length; i++) {
if (nums[i] != val) {
nums[insertIndex] = nums[i];
insertIndex++;
}
}

return insertIndex;
}
}

执行用时: 0ms, 内存消耗: 35.3MB.

Review

What is REST — A Simple Explanation for Beginners, Part 2: REST Constraints

RESTful 接口需要满足如下六条约束:

统一接口

统一接口包含以下四个方面:

  1. 发送到服务器的请求必须包含资源标识;
  2. 服务器需要返回足够的信息, 以致于客户端可以操作对应的资源;
  3. 客户端的每一个请求需要提供包含服务器执行操作所需的全部信息; 服务器的每一个响应需要提供客户端需要的所有信息以便理解响应内容;
  4. 超媒体应作为应用程序状态引擎;

客户端 - 服务器分离

客户端和服务器是各自独立的, 它们之间的交互仅能通过客户端的请求和服务端的响应来实现. 服务端不会主动向客户端发送信息.

无状态的

无状态意味着服务端不会记忆调用 API 的用户的任何信息, 每一次独立的请求都包含了服务端执行对应操作需要的所有信息.

分层的系统

客户端和真正提供服务的服务端之间可能有很多类似安全层, 缓存层, 负载均衡层等中间服务, 这些中间层不应该影响客户端和服务器之间的请求和响应, 客户端也不会知道有多少分层.

可缓存的

服务端的响应需要标注自身是否可被缓存. 良好的缓存设计可以减少不必要的请求, 达到节约资源的目的.

按需代码 ( 可选 )

客户端可以向服务端请求能够执行的代码, 代码通常是脚本的形式.

这个约束不作为 Restful 接口的的必要条件.

参考文献

  • 【译】REST的6个约束 — 亚里士朱德
  • 梳理REST API的设计原则 — 动力节点官方账号

Tip

「神器系列」软件终结者,没有它不能做的:uTools

这是一款和 Listary 相似的工具. 可以用作效率启动和文件搜索, 有点在于 uTools 拥有自己的插件系统, 如果插件生态做好的话优势会很明显.

Share

这周接受了将近三个小时的保险推销, 成功从一个保险小小白变成了保险小白. 这里分享一下我了解到的保险基础知识.

保险保障的范围一般是包括三个方面: 身故, 健康和意外.

身故

保障身故的险种称为寿险, 保额取决于被保人所承担的家庭责任. 保额的确定需要考虑当下以及将来父母的赡养费, 子女的抚养费, 房贷和车贷等负担. 假如自己意外身故, 尽可能保证家人正常生活.

健康

保障健康的险种一般包括重疾险, 医疗险和社保.

社保

社保是现代人医疗的基础保障, 最大报销额度平均大概是 15 万元.

医疗险

医疗险是对社保的一个补充, 用来保障社保覆盖不到的范围. 年龄越大, 保费越高, 保期一般是一年, 有停售风险.

重疾险

重疾险用来保障重大疾病以及康复修养期间的收入损失, 目前国内重疾的治疗费用平均为 50 万元, 收入损失一般考虑 1 - 3 年的工作收入. 保额的规划原则大概 = (50 万) + (1 - 3 年工作收入) - (15 万社保报销额度).

意外

意外险用于保障各种意外情况, 比如车祸和意外伤残等.

最后补充一个原则: 保险的主要目的是规避风险, 不是理财. 不要被一些别有用心的分红险给忽悠了.

刚被洗脑, 在此记录. over!

Seven wechat
扫码关注, 一起进步.
0%