REST API设计原则

json提交

当Content-Type 为 application/json 的时候，HTTP POST请求数据必须是JSON的。

HTTP POST

header:
Content-Type: "application/json"

body:
{
"key1": value1,
"key2": value2
}

　

http传参

可以统一使用HTTP POST来传参。

前端封装的框架，必须支持 公共参数追加到URL，并且可以以JSON传参。
后端就可以依据以上的情况，灵活使用参数组织方式了，处理业务的代码专心接受参数，
拦截器直接通过URL获取公共参数和Token，来做一些版本控制，身份认证等功能。

https://www.cnblogs.com/hnxxcxg/p/16347353.html  go CRUD

go CRUD 基于 数据结构体（data-model）
提出来不是为了普及GO语法，是想说明，rest api的CRUD接口，应基于数据结构体（data-model）
也就是说rest CRUD 基于 数据结构体（data-model）

http get对应 查询? http POST对应 新增? http patch对应修改？http delete对应 删除？
这样 未尝不可，但不是必要。
比如有人统一使用http post对应各方法，这并不违反REST API设计原则
REST API=http(https) + json？
答案：否
除非不是自己写的   网上找的理论库
因为现在流行REST API，所以想讲清楚什么是REST API？
只能说http(https) + json是rest api其中之一种
RESTFUL是一种架构思想，而不是指某一种技术。REST数据序列的核心其实是MODEL。
跨平台和语言是REST API的明显特征
跨平台和语言的前提是有标准的data-model
标准的data-model 在ioT（万物互联），显得犹为重要，JSON,XML。。这种明文序列无疑可以充当此任
但明文序列的低效率（相比二进制序列）却无法满足大数据的要求
那么DELPHI基于神秘二进制搞的dataset.data, dataset.delta，如何融入ioT（云平台）？
首先回答是肯定的。
DELPHI基于神秘二进制搞的dataset.data, dataset.delta 可以通过中间某种“纽带”变为rest api。
业务逻辑仍可以用DELPHI基于神秘二进制搞的dataset.data, dataset.delta，需要向中心平台交汇的数据可以通过REST API。