感谢邀请这里仅仅讨论的是传统的 http 协议接口，不考虑各种类库提供的面向对象接口
简单概括
简单接口示例
echo '{"code":1,"msg":"the API!"}';
相对复杂的一个接口示例
echo json_encode([
'data' => [
[
'name' => 'cat1' ,
'age' => 2 ,
] ,
[
'name' => 'cat2' ,
'age' => 5 ,
] ,
[
'name' => 'cat3' ,
'age' => 2 ,
] ,
] ,
'code' => 1 ,
'msg' => 'the API!' ,
]);请求一个 http 地址，返回一个 json 字符串，这就是接口
使用 xml，或者普通的字符串也算，但 json 是目前的主流做法
如果考虑到可维护性，拓展性，高并发等问题，那么逻辑会随之复杂起来，但是归根结底，接口就是这样
上面相对复杂的一个接口示例中有三个字段，data，msg，code，算是比较基础的最佳实践方案，实际过程可能更加复杂，返回的数据大概长这样
{
"data" : [
{
"name" : "cat1",
"age" : 2
},
{
"name" : "cat2",
"age" : 5
},
{
"name" : "cat3",
"age" : 2
}
],
"code" : 1,
"msg" : "success"
}code 通常表示接口返回的数据状态，比如 1 表示数据获取成功，0 表示数据获取失败(其原因有可能是服务器出现异常，比如数据库服务器出错，无法正常连接数据库，代码中触发了未知的bug等等)
data 通常传递具体的数据，如果是列表页的话，这个数据通常是个数组，数组的每个元素都是一个对象，对象中的键值对就是需要的数据，比如商城的商品列表页面，如果不是列表则通常可以使用一个对象表达，上面示例中即为一个数组
msg 返回指定的信息，比如无法正确返回数据的时候向前端提供一个信息让前端明白为什么数据没有正确返回以便做对应处理
需要注意的是，任何情况下，同一接口中，规范一旦确定，那么除非接口被关闭，不再提供 http 服务，否则在任何情况下都必须返回符合这个规范的数据，如果服务器其异常，无法返回正常数据，可通过 code 和 msg 字段来告知原因，让前端调用者自行判断处理
对其中的 data 字段，这个数组数据来源大致有以下几点：大部分情况下来自数据库(mysql，sql server ，SQLite，oracle，mongodb ...)里查询出来的结果，比如后台添加商品，前台展示商品列表
有些情况下可能是来自于服务器端的 http 请求库请求的其它接口的数据，比如在系统中需要调用第三方的数据接口的时候
更多的时候来自于缓存系统(memcached、redis、FastDB、SQLite、Berkeley DB、GigaBASE、H2 等)读取数据
其它...
json 和 xml 对比
json 之所以比起 xml 运用更加广泛，主要特点在于其结构化描述数据更加轻量，运用的字符数量更少，更加节省网络资源
传递同样的数据
json：
{"code":1,"msg":"the API!"}
XML：
1
the API!
json 格式表达的是键值对，而 xml 格式除了可以表达键值对，还有属性特征
所以严格来讲，xml 与 json 是无法绝对对等的转换的，但是可以自定义规范来使用 json 表示同样意义的 xml，即 xml 中的属性特征，在 json 中没有等对的表示方式
下面示例中 ui:group 标签中的 layout 属性，在 json 中，需要用类似 @attributes 的方式来描述，可以实现跟 xml 一样的数据传递，但必须明白本质不是对等的
XML:
Search
json:
{
"@attributes" : {
"layout" : "vertial"
},
"block" : [
{
"@attributes" : {
"width" : "200",
"layout" : "horizontal"
},
"input" : {
"@attributes" : {
"value" : "Search"
}
},
"button" : "Search"
},
{
"@attributes" : {
"width" : "400"
}
}
]
}
通用规范
字段的设计规范没有专门标准，通常确保在一个项目或者一个团队中保持一致即可
但仅此是远远不够的，在行业内为了有一套不同团队，不同项目都可互用的规范，就有写大厂编写了通用规范，如果都遵守的话就可以比较方便的互通，降低不同项目中的沟通成本xml 典范：SOAP (Simple Object Access Protocol，简单对象访问协议)如之前所提及，因为 xml 目前几乎已经被 json 所代替，所以这个协议也几乎已经成了传说，个人认为没有学习的必要
这是一套比较复杂的规范，带来的优异之处就是其规范内的表达能力十分出众
通俗的讲，现在想用 php，或者 go， 或者 java，或者 python 等等任何语言，去调用另一个使用 php，或者 go， 或者java，或者 python 等等另一个任何语言编写的函数，或者对象的方法，如何实现？没错，无论你使用什么语言，只要在编码中按这套规范来，那么就可以实现这个需求json 典范：jsonrpc (JSON-RPC，远程过程调用(RPC)传送协议)
此规范就是 json 版的 soap，但是不仅仅是更换数据传递的包装方式，其规范比起 soap 内容要简约的多，所以带来的好处就是使用起来十分灵活，数据传递过程更节省网络资源，推荐学习
除此之外还有个比较时髦的东西叫做 RESTful，具体查阅这里
说说缓存为什么需要缓存？
在讨论这个问题之前先要先明白一个事情，就是在获取到我们需要的数据时候，服务器的开销大小的问题
上面我们提到，数据大部分情况下来自于数据库，或者第三方接口返回的数据，听起来没问题，而比较遗憾的是这两种方式获取数据都会产生比较大的性能开销
在数据库中查询时数据库会操作硬盘，这对系统来说是极大的开销，尤其在联表查询的时候，开销几乎以几何级数增长
在请求第三方接口的时候会发送网络请求，如果对方的接口有频率限制，或者网络环境不稳定会直接导致接口的稳定性
当然在我们开发中不会有任何‘慢’或者 ‘卡’的感觉，毕竟对人来讲，0.01 秒和 0.00001 秒基本上是没有区别的，但是如果考虑到并发，把一个操作重复 1w，10w次的时候，这个开销就必须被考虑了，所以缓存就必须被考虑
之前所提及的缓存手段(memcached、redis、FastDB、SQLite、Berkeley DB、GigaBASE、H2等)它们都有一个共同特点，就是在其中读取数据的系统开销比起前面的数据库或者情况第三方库或者其他方式要小的多，通常的做法是数据直接保存在内存中，读取过程不需要操作硬盘，直接从内存读取，所以速度和开销都要优于之前的手段，鉴于此，在高并发系统中缓存必须被考虑何时需要缓存？
那么是否意味着所有接口都需要缓存？未必。通常最基本的原则就是变化不频繁的数据需要重点考虑，而变化频繁的数据则需要专门评估
通常最基础的做法是在接口的逻辑中，先读取缓存数据，如果未读取到缓存数据则请求数据库，如果数据请求成功，则先把数据缓存起来，再返回数据
下次此接口被请求的时候，将会先读取缓存，此时缓存中已经有上次被缓存的数据，则直接从缓存取出数据返回，避免了请求数据库，达到缓解数据库压力的目的
此逻辑带来的问题就是需要在数据库中数据被更新的时候让对应的缓存失效，如何把握时机让对应的缓存失效是个比较重要的学问，通常比较简单粗暴的做法是指定缓存到期时间，而在要求比较高的系统中，则需要专门的方式来处理，此处不展开讨论
原谅我的偷懒，此文值得参考常用的缓存工具有哪些？
常用的有 memcached、redis、FastDB、SQLite、Berkeley DB、GigaBASE、H2等
其中 memcached 是纯内存型缓存，无法持久化数据，能缓存的数据类型比较有限，其性能也最为卓越
redis 支持比较丰富的数据类型，数据可以持久化到硬盘，建议重点考虑
其它缓存软件没在实战中使用过不予置评
以上
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
