前言
在以前,一个网站的完成总是“all in one”,页面,数据,渲染全部在服务端完成,这样做的最大的弊端是后期维护,扩展极其痛苦,开发人员必须同时具备前后端知识。于是慢慢的后来兴起了前后端分离的思想:
后端负责数据编造,而前端则负责数据渲染,前端静态页面调用指定api获取到有固定格式的数据,再将数据展示出来,这样呈现给用户的就是一个”动态“的过程,而关于api这部分的设计则成了一个问题。如何设计出一个便于理解,容易使用的api则成了一个问题。
而所谓的restful就是用来规范我们的api的一种约束。

介绍
rest是REpresentational State Transfer三个单词的缩写,由Roy Fielding于2000年论文中提出,它代表着分布式服务的架构风格。而如果想你的api被称为restful api,只要遵循其规定的约束即可。

rest设计原则
客户端-服务器:通过将用户UI与数据存储分开,我们可以简化服务器组件来提高跨多个平台的用户界面的可移植性并提高可伸缩性。 它可以比表现成前后端分离的思想。
无状态:从客户端到服务器的每个请求都必须包含理解请求所需的所有信息,并且不能利用服务器上任何存储的上下文。 这表示你应该尽可能的避免使用session,由客户端自己标识会话状态。(token)
规范接口:REST接口约束定义:资源识别; 请求动作; 响应信息; 它表示通过uri标出你要操作的资源,通过请求动作(http method)标识要执行的操作,通过返回的状态码来表示这次请求的执行结果。
可缓存: 缓存约束要求将对请求的响应中的数据隐式或显式标记为可缓存或不可缓存。如果响应是可缓存的,则客户端缓存有权重用该响应数据以用于以后的等效请求。 它表示get请求响应头中应该表示有是否可缓存的头(Cache-Control)
其中1,2,3约束最为重要,其中1容易理解。接下来我们就谈谈无状态和规范接口的原则。
uri规范
资源的描述构成了uri,它一般有以下约束:

使用名词。如 user, student, class
http://api.example.com/class-management/students
http://api.example.com/device-management/managed-devices/{device-id}
http://api.example.com/user-management/users/
http://api.example.com/user-management/users/{id}

http method对应不同的请求动作(数据库或者业务逻辑)
GET:查询操作:
HTTP GET /devices?startIndex=0&size=20
HTTP GET /configurations?startIndex=0&size=20
HTTP GET /devices/{id}/configurations
HTTP GET /devices/{id}
POST:新增操作:
HTTP POST /device
PUT 更新操作(代表更新一个实体的所有属性)
HTTP PUT /devices/{id}
PATCH 部分更新(代表更新一个尸体的部分属性)由于有的浏览器兼容性问题,一般推荐使用put
HTTP PATCH /devices/{id}
DELETE 删除操作
HTTP DELETE /devices/{id}

使用连字符( - )而不是(_)来提高URI的可读性
http://api.example.com/inventory-management/managed-entities/{id}/install-script-location //更易读
http://api.example.com/inventory_management/managed_entities/{id}/install_script_location //更容易出错

在URI中使用小写字母
http://api.example.org/my-folder/my-doc

不要使用文件扩展名 文件扩展名看起来很糟糕,不会增加任何优势。删除它们也会减少URI的长度。没理由保留它们。
http://api.example.com/device-management/managed-devices.xml / 不要使用它 /
http://api.example.com/device-management/managed-devices / 这是正确的URI /

使用查询组件过滤URI集合
很多时候,我们会遇到需要根据某些特定资源属性对需要排序,过滤或限制的资源集合的要求。为此,请不要创建新的API - 而是在资源集合API中启用排序,过滤和分页功能,并将输入参数作为查询参数传递。例如
http://api.example.com/device-management/managed-devices
http://api.example.com/device-management/managed-devices?region=USA
http://api.example.com/device-management/managed-devices?region=USA&brand=XYZ
http://api.example.com/device-management/managed-devices?region=USA&brand=XYZ&sort=installation-date

不要在末尾使用/
作为URI路径中的最后一个字符,正斜杠(/)不会添加语义值,并可能导致混淆。最好完全放弃它们。

使用http状态码定义api执行结果
1xx:信息
通信传输协议级信息。

2xx:成功
表示客户端的请求已成功接受。

3xx:重定向
表示客户端必须执行一些其他操作才能完成其请求。

4xx:客户端错误
此类错误状态代码指向客户端。

5xx:服务器错误
服务器负责这些错误状态代码。
另外完整的更为详细的状态码此处不做赘述。一般简化版本的api会使用200,400,500,其中400代表客户端调用有误,将错误信息放入response:

{
"error": "username.or.password.error"
}
api版本定义
当我们需要对现有的api接口升级的时候,因为该api接口已经投入使用,所以新添加的业务可能无法保证兼容原来的逻辑,这个时候就需要新的接口,而这个接口一般表示对原来的接口的升级(不同版本),那版本怎么定义呢?
URI版本控制(推荐)
http://api.example.com/v1
http://apiv1.example.com
使用自定义请求标头进行版本控制
Accept-version:v1
Accept-version:v2
使用Accept header 进行版本控制
Accept:application / vnd.example.v1 + json
Accept:application / vnd.example + json; version = 1.0
无状态
使REST API无状态有一些非常显着的优点:

无状态通过将API部署到多个服务器,有助于将API扩展到数百万并发用户。任何服务器都可以处理任何请求,因为没有与会话相关的依赖。(集群)
无状态使得REST API不那么复杂 - 可以删除所有服务器端状态同步逻辑。(删除session,清理多余空间)
无状态API也很容易缓存。特定软件可以通过查看该一个请求来决定是否缓存HTTP请求的结果。从先前的请求中获得的状态可能会影响这个请求的可缓存性,这并不存在任何不确定性。它提高了应用程序的性能。
服务器永远不会忘记每个客户端身份”,因为客户端会在每个请求中发送所有必要的信息。(携带token)
那么无状态又要怎么实现呢?前面我们已经说了,服务端不应该再保存session会话,这个工作全部交由http请求去标识,而最常见的做法则是使用token。生成token可以考虑使用jwt,oauth。

作者:jsbintask
链接:https://www.jianshu.com/p/a35bad7dbc54
来源:简书
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。

在使用Git的过程中,我们喜欢有的文件比如日志,临时文件,编译的中间文件等不要提交到代码仓库,这时就要设置相应的忽略规则,来忽略这些文件的提交。

规则 作用
/mtk 过滤整个文件夹
*.zip 过滤所有.zip文件
/mtk/do.c 过滤某个具体文件
!/mtk/one.txt 追踪(不过滤)某个具体文件
注意:如果你创建.gitignore文件之前就push了某一文件,那么即使你在.gitignore文件中写入过滤该文件的规则,该规则也不会起作用,git仍然会对该文件进行版本管理。

配置语法
以斜杠“/”开头表示目录;
以星号“*”通配多个字符;
以问号“?”通配单个字符
以方括号“[]”包含单个字符的匹配列表;
以叹号“!”表示不忽略(跟踪)匹配到的文件或目录。
注意: git 对于 .gitignore配置文件是按行从上到下进行规则匹配的

Git 忽略文件提交的方法
有三种方法可以实现忽略Git中不想提交的文件。

在Git项目中定义 .gitignore 文件
这种方式通过在项目的某个文件夹下定义 .gitignore 文件,在该文件中定义相应的忽略规则,来管理当前文件夹下的文件的Git提交行为。

.gitignore 文件是可以提交到共有仓库中,这就为该项目下的所有开发者都共享一套定义好的忽略规则。

在 .gitingore 文件中,遵循相应的语法,在每一行指定一个忽略规则。如:

*.log
*.temp
/vendor

在Git项目的设置中指定排除文件
这种方式只是临时指定该项目的行为,需要编辑当前项目下的 .git/info/exclude 文件,然后将需要忽略提交的文件写入其中。

需要注意的是,这种方式指定的忽略文件的根目录是项目根目录。

定义Git全局的 .gitignore 文件
除了可以在项目中定义 .gitignore 文件外,还可以设置全局的 git .gitignore 文件来管理所有Git项目的行为。这种方式在不同的项目开发者之间是不共享的,是属于项目之上Git应用级别的行为。

这种方式也需要创建相应的 .gitignore 文件,可以放在任意位置。然后在使用以下命令配置Git:

git config --global core.excludesfile ~/.gitignore

Git 忽略规则
详细的忽略规则可以参考官方英文文档

Git 忽略规则优先级
在 .gitingore 文件中,每一行指定一个忽略规则,Git 检查忽略规则的时候有多个来源,它的优先级如下(由高到低):

从命令行中读取可用的忽略规则
当前目录定义的规则
父级目录定义的规则,依次地推
$GIT_DIR/info/exclude 文件中定义的规则
core.excludesfile中定义的全局规则
Git 忽略规则匹配语法
在 .gitignore 文件中,每一行的忽略规则的语法如下:

空格不匹配任意文件,可作为分隔符,可用反斜杠转义

开头的模式标识注释,可以使用反斜杠进行转义

! 开头的模式标识否定,该文件将会再次被包含,如果排除了该文件的父级目录,则使用 ! 也不会再次被包含。可以使用反斜杠进行转义
/ 结束的模式只匹配文件夹以及在该文件夹路径下的内容,但是不匹配该文件
/ 开始的模式匹配项目跟目录
如果一个模式不包含斜杠,则它匹配相对于当前 .gitignore 文件路径的内容,如果该模式不在 .gitignore 文件中,则相对于项目根目录
**匹配多级目录,可在开始,中间,结束
?通用匹配单个字符
[]通用匹配单个字符列表
常用匹配示例:
bin/: 忽略当前路径下的bin文件夹,该文件夹下的所有内容都会被忽略,不忽略 bin 文件
/bin: 忽略根目录下的bin文件
/*.c: 忽略 cat.c,不忽略 build/cat.c
debug/*.obj: 忽略 debug/io.obj,不忽略 debug/common/io.obj 和 tools/debug/io.obj
**/foo: 忽略/foo, a/foo, a/b/foo等
a/**/b: 忽略a/b, a/x/b, a/x/y/b等
!/bin/run.sh: 不忽略 bin 目录下的 run.sh 文件
*.log: 忽略所有 .log 文件
config.php: 忽略当前路径的 config.php 文件
.gitignore规则不生效
.gitignore只能忽略那些原来没有被track的文件,如果某些文件已经被纳入了版本管理中,则修改.gitignore是无效的。

解决方法就是先把本地缓存删除(改变成未track状态),然后再提交:

git rm -r --cached .
git add .
git commit -m 'update .gitignore'

问题描述:
          git add:添加至暂存区,但并未提交至服务器。git add . 是表示把当前目录下的所有更新添加至暂存区。有时在终端操作这个会提示:

warning: LF will be replaced by CRLF in ball_pool/assets/Main.js.
The file will have its original line endings in your working directory
原因:
         这是因为文件中换行符的差别导致的。这个提示的意思是说:会把windows格式(CRLF(也就是回车换行))转换成Unix格式(LF),这些是转换文件格式的警告,不影响使用。

git默认支持LF。windows commit代码时git会把CRLF转LF,update代码时LF换CRLF。

解决方法:
注:  . 为文件路径名

git rm -r --cached .
git config core.autocrlf false
git add .
git commit -m ''

1.下载安装

https://git-scm.com/downloads
https://npm.taobao.org/mirrors/git-for-windows/

2.设置用户名和邮箱

 git config --global user.name "用户名"
 git config --global user.email "邮箱"
 git config --list

3.创建文件夹与初始化git

mkdir blog
cd blog
git init

4.向仓库添加文件,添加到暂时存区,提交到仓库

touch test.php   git clone 远程仓库地址
git log
git status
git add test.php
git commit -m 'add test.php'
git push
git pull