- 必须符合Restful
统一返回格式，约定业务层错误编码，每个编码可以携带可选的错误信息。 - 命名必须规范、优雅
- 单一性
单一性是指接口要做的事情应该是一个单一的事情，如新增用户，用户登录。
关于单一性需要特表强调一下，单一性原则非常重要，很多时候系统出现问题，或者出现漏洞实施因为接口做了过多的业务处理。且良好的接口单一职责能够提高代码的复用。 举个例子：
某个应用程序需要提供一个新增用户的接口。按照正常的设计，这个接口应该按照restful规范将用户新增接口开放即可。
但是客户端有一个xml格式的文件，且文件内部数据不能完全匹配接口服务端接口对象，但是客户端为了省事希望用户新增接口能够支持识别xml格式数据。
所以服务端新增用户代码改成了解析xml数据然后创建用户。在此过程中服务端其实对xml格式的数据并不清楚，因为xml数据格式是客户端端定义的。
随着后续需求的改变，xml数据格式就可能产生变化。那么服务端接口就会一直跟着xml的数据格式修改。这样接口就会变得很不稳定，且由于服务端对xml数据并不是很清楚，很容易出现BUG。那么正确的做法是什么。
做任何事情都要回归的正确的逻辑上，不论是编写方案还是编写程序。都要有一个正确的逻辑支撑，不然就是任意乱为。按照接口单一职责，新增用户就应该简单的做用户创建工作，如果客户端想要以xml作为用户数据的载体并希望服务端提供数据解析的支撑。那么就应该新增一个用户导入的接口，并且双方定义好一个对双发都比较友好的数据格式。不然xml的解析过程就应该改在客户端。正确的逻辑就是如此。
- 数据的输入输出尽量少
接口是给系统之间的交互数据使用，不论是为了数据的安全性还是在接口调用时能够更加友好，接口数据输入应该尽可能的少，该默认的就默认。接口的输出数据也要竟可能的少，保证数据的安全性。
- 可扩展
接口扩展性，是指设计接口的时候多想想多种情况，多考虑各个方面，其实我觉得单独将扩展性放在这里也是不妥的，感觉说的跟单一性有点相反的意思，其实这个不是这个意思。
此处的扩展性是指我们的接口充分考虑客户端，想想他们是如何调用的，他要怎样使用我的代码，他会如何扩展我的代码，而不是考虑把客户端的业务处理写在服务端，而应该把更多的主动权交给客户程序员。
如果提高接口扩展性，其实正是和接口单一职责首位呼应的，比如新增日志接口，和新增错误日志接口，两种不同业务但是两个接口的输入数据一般是一样的。当时不能为此就可以编写一个接口实现两个业务，底层应该一样是两个接口，如果业务需要应该是新增一个接口按照逻辑复用新增日志和新增错误日志两个接口。
只有接口设计严格按照单一职责原则，接口的输入数据尽可能的少，才能提高接口复用，才能提高接口扩展性。再次强调接口的可扩展绝不是将客户端的业务处理写在服务端，而是把更多的主动权交给客户程序员，这样才能利用有限的接口实现更多的业务并且保证接口依然是稳定可靠的，不然接口开发就会陷入不停迭代的尴尬境地中
- 接口粒度要小
接口粒度尽量小，提高代码复用，其实适合接口单一职责原则相互呼应的。
- 必须有文档
良好的接口设计，离不开清晰的接口文档表述。文档表述一定要足够详细
- 客户端能处理的逻辑就不要给服务端处理，减少服务端压力
接口一般都是给客户端使用的，不论是BS（BS架构架构只是把客户端换成了浏览器而已）还是CS架构，服务端和客户端一般都是一对多的关系，所以一般在设计接口时，一般客户端能处理的逻辑都应该在客户端处理完。查看目前所有软件设计无不如此。
有时候大家对接口可能会有一定误解，比如我写了一个webservice给客户端调用。webservice不是经常会处理很多逻辑吗。同样我也写过类似的代码，但是请搞清楚，我们写编写这样的代码时基本上都是在做数据同步处理，客户端同样也是另外一个应用系统，此类场景更应该称为ETL过程，只是技术实现采用了webservice，但是并不属于接口开发范畴。
-
不要过度设计
-
缓存尽量不要穿透
-
思辨大于执行
很多人总是提倡先。但是接口设计一定是思辨大于执行。设计优先，辩证其次，最后才是执行。
最后总结：
不论是任何行业，服务端开发接口时，为了适配PC、小程序、APP、公众号时。服务端接口设计一定会严格参照并遵循以上原则， 不然服务端的开发程序员就需要按照不同的客户端开发好几套接口，如果一个产品的服务端的接口毫无设计原则且都开发好几套适配不同客户端，那么这个产品的接口维护可想而知，而且如果以后想要新增不同的客户端会很困难，那么这个产品的上限基本上到头了。
