手机用户57280362794
首先新建一个项目，然后新建一个Controller类，如下：
然后类上面加上注解@RequestMapping，这个注解要带上一个路径，这个路径会成为接口的一部分，然后再加上@RestController，这个注解是说明接口返回的数据格式为json，因为现在一般都是json数据格式交互
接下来在类里面新建一个方法，如下：
![]()
这时候我们还需要在方法上面再加上一个注解@RequestMapping，或者@GetMapping等其他注解
![]()
现在基本一个接口就定义完了，我们在方法中加一点信息返回给调用方，如下：
![]()
接下来我们启动项目，如下，启动成功
![]()
最后我们打开浏览器，访问我们的api接口：
![]()
码技术秘圈
因为我是做Java开发的，所以就按照Java的开发流程说一下；首先一个好的API接口，设计是要下功夫的，细节就不在这里说了，这里还是主要说实现；如果开发环境具备，前后大概也就不到十分钟，就可以完成一个简单的API接口的开发（只是个demo）。
0、开发前准备：电脑上需要安装JDK、Maven和IDE。
1、新建一个基于Spring Boot的项目，为了快速完成，我选择登录到【
start.spring.io
】网站上，生成一个项目。通过【Search dependencies to add】可以选择需要引入的包，我这里只引入了Web，也就是Spring MVC；假如你需要通过Mybatis访问数据库，也可以在这里选择；然后点击生成项目。
2、将下载好的项目，解压后引入到你的IDE中，新建一个类：
com.wukong.apidemo.controller
.ApiController3、在这个类中增加一个方法，并主要使用@RestController、@RequestMapping、@ResponseBody两个标签，整个类大概是这个样子：
4、这时候最简单的一个API接口就完成了，我们可以启动项目后，访问对应的接口地址，得到接口的返回信息：
5、我们再对这个接口稍微加工一些，让swagger帮助我们生成一个接口文档：
5.1、在
pom.xml
中进入swagger需要的包：
5.2、对ApiController增加：@Api、@ApiOperation、@ApiImplicitParams等标签：
5.3、这时候启动项目后，访问：
http://10.141.48.41:8080/swagger-ui.html
5.4、这里留了一个小问题，swagger的配置少了一步，按照上面的做饭，访问swagger的页面是会报404的，大家可以尝试解决。
我将持续分享Java开发、架构设计、程序员职业发展等方面的见解，希望能得到你的关注。
会点代码的大叔
作为BAT的Java开发工程师，来分享下我在公司里写的项目（脱敏）中的封装api接口部分。
我们使用的是SSM框架，但是这里其实不论是SSM还是SSH，抑或是SPRING BOOT，接下来的介绍都是通用的，因为主要是通过介绍注解（annotation），而不是xml文件。
Controller.Class
首先，API接口需要出现在controller层，因此，在类名上方，需要至少两个注解，@controller，用于在项目启动的时候告诉spring，这个类是controller层的，需要加载好；@requestMapping，这个注解相当于指明了api的url中的一部分。
如果一个服务绑定的域名是
http://xx.yy.com
，然后requestMapping中的内容意味着，url为http://xx.yy.com/dispatch
/.... 格式的请求，会被转发到当前这个类中。
Controller.function
看完接下来我们看函数部分，这里首先也要加一个responseBody注解，这个注解的含义是将controller层中，函数的返回对象通过转换器，转换为指定的格式，写入到http response返回对象的body中去，也就是说下面这个函数返回的String，直接作为response的body内容返回给了用户。
接下来，依旧是requestMapping注解，相信大家也能了解了，复用上面的例子，当url为
http://xx.yy.zz/dispatch/validate
的时候，相当于调用了这个validateParams函数，并且这个请求request的body就会作为body参数，一并传入这个函数。
这里大家可以能注意到了，上面的函数的参数名中用的是requestBody，而下面用的是formParam，虽然二者都是post请求，但是参数接收方式却不一样。这就意味着，代码里指定了不同的接收方式，request的body里也必须用对应的方式才能将数据传递给函数。上图中body用raw形势的就可以，而下图则要求用application/x-www-form-urlencoded格式的body。
最后，上面介绍的都是post请求的api，下图介绍了GET请求的api如何写。可以看出，注解方面，requestMapping里指定requestMethod为GET即可。在函数的参数方面，需要用requestParma注解来接收，如下图。当你发送
http://xx.yy.com
/dispatch/getMyContract?username=xiaomin&password=123 这个请求的时候，就相当于调用了下面的getMyContract函数，并且传入的username参数为xiaomin，password参数为123.
我是苏苏思量，来自BAT的Java开发工程师，每日分享科技类见闻，欢迎关注我，与我共同进步。
一个存在感小透明
我们知道API其实就是应用程序编程接口，可以把它理解为是一种通道，用来和不同软件系统间进行通信，本质上它是预先定义的函数。API有很多种形式，最为常见的就是以HTTP协议来提供服务（如：RESTful），只要符合规范就可正常使用。现在各类企业在信息化这块都会用到第三方提供的API，也会提供API给第三方调用，因此设计API也是需要慎重的。
具体该如何开发设计一个良好的API接口呢？
明确功能
在设计之初就需要将API详细功能整理出来，按业务功能点或模块来划分，明确此API需要提供哪些功能。
代码逻辑清晰
保持代码整洁性，增加必要的注释，接口确保功能单一，如果一个接口需要复杂的业务逻辑，建议拆分成多个接口或者将功能独立封装成公共方法，避免接口里代码过多，不利于后期人员维护和后期迭代。
必要的安全校验机制
目前Web应用很容易遭遇数据窃取、篡改、非法提交、重复请求等安全问题，API的安全校验机制是必不可少的。常用解决方案就是采用数字签名形式，将每个HTTP请求都加上签名，服务器端校验签名合法性来保证请求是否合法。
日志记录
为便于及时定位问题，日志是必不可少的。
降低耦合度
一个良好的API应该是越简单越好，如果API间业务耦合度过高很容易因某块代码异常导致相关API的不可用，尽可能避免API间的复杂调用关系。
返回有意义的状态码
API返回数据中要携带状态码数据，比如200代表请求正常，500代表服务器内部错误等。返回通用的状态码有利于问题定位，比如可参考以下状态码：
开发文档
既然API是提供给第三方或内部使用的，那开发文档是必不可少的，否则他人不知道如何调用。一个良好的API开发文档应包含以下元素：
1、当前API架构模式讲解、开发工具及版本、系统依懒等环境信息；
2、当前API提供哪些功能；
3、API模块间的依懒关系；
4、调用规则、注意事项；
5、部署注意事项等。
一个好的API必然是易使用，易看懂，易扩展，难误用，安全性高，功能强大的API。要做到上面几点并不容易，但是我们应当遵从上述原则结合业务本身合理的划分设计API。
网络圈
API（Application Programming Interface,应用程序编程接口），目的是提供应用程序与开发人员基于某软件或硬件访问获取数据。
PHP简单示例：
假设接口访问地址 http://127.0.0.1/api.php，api.php文件内容是
访问接口 http://127.0.0.1/api.php
特别说明
上术示例只是最最基本的实现方式上的一个小示例！市面上再复杂规范的API，无非就是一个根据客户端的请求参数对数据的筛选。所以这里也给出一个比较规范的API设计思路使用标准的HTTP方法，规范路由请求。
无状态性，每个请求都是一个新的请求来对待。
支持多种资源表示方式 (xml, json等)。
数据格式规范化，做好数据的安全性。
我的IT与生活
api全称为application programming interface，应用程序接口，是软件系统中系统间交互的组件。特别是在现流行的前后端分离的架构中应用最广，还有移动互联网也是常用的架构。
那对于api接口如何做呢，以下我说说我的经验。
1.首先对系统做需求分析，整理出功能需求。
2.对系统做设计，同时进行数据库设计后再进行接口设计，因为如果都不清楚系统的架构，数据库设计，怎能接口设计好呢？
3.编写接口开发框架，以JAVA为例，现在一般以Restfull为开发标准，可选的框架有springmvc，dubbo，微服务框架等，可以找下相关资料如何搭建开发框架。
4.进行接口开发，对照接口设计文档，一个个编写，一般接口的程序分层为interface，实现层service，dao层，Vo模型，而对外开放的用springmvc来控制和编写。
5.接口写好后需要本地化测试，而自测有多种方式，比如junit，postman，还有线上api测试工具，或者集成swagger接口框架，我喜欢使用postman。
6.完成自测后就可发布到服务区提供出来联调测试了。
接口开发大致的流程就这样，当然很多细节没说，比接口规范，安全等，如想进一步了解可关注我，一起学习进步。
小小皮匠
引语：现在互联网那么热，你手里没几个APP都不好意思跟别人打招呼！但是，难道APP就是全能的神吗？答案是否定的，除了优雅的APP前端展示，其实核心还是服务器端。数据的保存、查询、消息的推送，无不是在服务器端完成的，默默地！那么，怎样提供一个好的服务端API接口就是一个至关重要的问题了！
也许你会说，现在APP这么泛滥，谁还不会写个服务端API接口程序啊？是的，也许，你是对的，但是本文想说明的和要讲的故事，是一个从零到一故事，是一个思想，是一个历程，一个可以推演的过程！
在给出答案之前，先抛几个问题，如果你自认为这些方面都做得很优秀，那么恭喜你，你已经是牛人了！请于文后留下你的箴言以供借鉴，多谢！如果你感觉还有待提高的，可以尝试在这里找找答案，不谢！（注：本人使用PHP语言进行开发，但这不重要）
采用什么样的服务器进行提供服务(也许不太准确)？如：soap server ? yar server ? restful ? 好吧，我相信你肯定是用的restful风格的，因为这个才是王道！
怎样确定访问来路是正常的，或者说你怎样管理访问权限？（附：怎样获取传递过来的参数）
有加密方式吗？https ? 是否有区分不同场合？
怎样解决编码问题？
怎样控制接口版本迭代问题？
上传文件怎样处理？
怎样防止注入？（如果你也没有用框架）
怎样提升访问速度？怎样提高并发？
好，看完问题，让我们继续故事！
前编：公司是一个小公司，刚成立不久，技术人员也很少，几乎是一个人负责一个项目，如web前端，web后端，安卓端、IOS端。很明显，我的任务是，服务器端接口的提供！（那里的我，经验也是可怜的）
1、采用什么样的服务器进行提供服务(也许不太准确)？如：soap server ? yar server ? restful ?
提供服务方式，之所以会想到用这几个东西提供服务，是因为，我用的就是PHP开发啊。PHP里就有这些东西，所以，很自然的嘛，soap,yar这两个东西在PHP与PHP程序之间的通信的确是不错的。但是，你要移动端对接，不止安卓，不止IOS。所以，只能国际化了呗！采用restful架构，其实说白了，也就是一个地址，就可以进行操作了，放心吧，大家都是这么干的，准没错！（附：请考虑提供接口只是进行数据的操作，倒底有没有必要去使用一个完整的MVC框架）
2、怎样确定访问来路是正常的，或者说你怎样管理访问权限？
访问权限，为什么会有这个问题呢？如果是自己的网站，那么，你所访问的地址，就是你自己提供的，根本不需要什么访问权限控制！但是，如果对外提供服务，那就得考虑了。来访的人不是内部的怎么办？他登录了没有？现在有多少人在访问这个服务？这些东西，都应该被一目了然的呈现出来。那么，怎样控制来访人员呢？方法1、在程序里写死几个密码一类的东西，让客户端访问时，带上此变量以验证；方法2、为每个客户端（我说的是安卓或ios等一套源代码）提供一个appId,appKey，访问时携带，实际上，很多大公司都是这么干的；方法3、使用Oauth等授权方式。很明显，方法2是最好的方式，有了个这个东西，你也可以很方便的进行访问的有效记录！（实践：建立权限表，建立访问日志表，如有必要，建立模块访问权限表，错误描述表）
3、有加密方式吗？
https ? 是否有区分不同场合？加密，一般提供接口我们都可以采用json方式（方便啊），那就是说，所有的访问，几乎都是采用明码传输，那么就必须有一定的假设信息被截获的防范措施（实际上，这个假设也很容易成立）！对于一般的信息，加一个普通的普通的签名即可，如：appId+appKey+访问参数+timestamp+随机字符n个 再 md5 得到签名，服务器端首先进行该签名验证，确认后，再进行后续操作！当然，对于支付一类的操作，这样的操作还是显得不够安全的，那就需要特殊对待，借助于https的加密，就安全多了！
4、怎样解决编码问题？
编码问题，也许许多人看来，这并不是问题。但是我想说的是，PHP写代码真的很方便很随意，md5,json_encode等都语言自带的函数，但是对于java和swift可能就没那么简单了，还得自己去找别人封装的东西，有时稍有不对就可能导致签名不对，所有访问都无效！(这里主要说的是包含中文的地方)；我们当时大家采用的都是UTF8的编辑器开发，所以并没有什么太大问题！
5、怎样控制接口版本迭代问题？
版本迭代，这是个问题！因为，如果整个网站都是你的，你想怎么改都可以，反正别人访问也就只有你网址这一个入口。但是移动APP不一样了，每个人都是独立的，他们各自的版本都是不一样的。如果共用一套接口的话，小的改动还好，向后兼容就行了，但是对于一些大方向的改动，这将是致命的，要么强行使用户不能使用以促使其更新，要么你继续写一长篇无用的不可维护的冗余代码！所以，做好版本控制是必须的，主要实现为：传入一个version参数，从而调用不同的内部接口地址，当然，你可以直接接口地址指向另一目录！这样，就有很多个版本接口共存了！如 /pro/api/v1.0/xxx, /pro/api/v2.0/xxx
6、上传文件怎样处理？
上传文件，这也是问题，因为，其他地方都是采用的文本内容传递至服务器，可以直接进行数据库保存操作，但是，对于上传文件则不一样。如果是网站，则一般只能使用Form表单进行提交，而且必须设置属性multipart/form-data,声明为文件类型。那也就是说，不能以普通的json格式提交了！解决方法有2个，方式1、先将文件以表单形式提交至服务器，服务器返回地址，再将地址组合进其他选项中，一起以json提交！方式2、整个内容以webForm表单形式提交，此类页面单独处理权限问题，并注意是否是伪造请求，可另加页面隐藏token验证！
7、怎样防止注入？（如果你也没有用框架）
问题7、防止注入，也许作为开发人员，说这个已经太low，但是我还是忍不住提了，因为，真的很重要，其实，接口要做的事情很简单，接受数据，保存数据，返回状态。所以，真心觉得，没必要去用一些很成熟的大型框架，太臃肿！那么注入问题，就只有你自己解决了。php 使用 mysql_real_escape_string 及 htmlspecialchar进行过滤，基本也就够了！
8、怎样提升访问速度？怎样提高并发？
接口的访问速度，这个是很重要的。你有没有看到哪个APP访问速度很慢，大家还愿意用他的？做到秒开才是王道，由于各种验证，各种日志记录，已经消耗了不少时间，所以更要注意效率问题。索引、缓存、负载均衡、分布式，用起来。。。 哈哈，太宽泛了
从最初什么都没有，到最后，一整套接口的完成，大概花了一个多月时间，感觉还是有很多不OK的地方，再后来准备做消息推送，做长连接，结果由于某些原因，项目被中断，也就不了了之了。
写一点当时的过程，就当是一点点的收获吧。还记得，当初开始做的时候，参考资料实在太少，以至于做很多东西，都没有信心，只是凭感觉！！希望这篇文章能帮到部分处于这个时期的人！
其实不管是做什么样的开发，都应该是从核心要解决的问题出发的，当你把问题都解决了之后，也许，一个好的设计好的架构就已经悄然呈现！这也许就是解决问题之美吧！
欢迎批评，欢迎指正，欢迎提问！
情感小小的世界
作为一名开发者，在此发表我的一些观点，一个好的Api一定是一个可读性比较高的Api项目。可以从以下几点入手
1、不论Api用何种语言编写，多少人编写，都需要达到每个接口的输出规则都是一致的。确定好开发前的开发规范，包括入参使用何种驼峰命名，返回的json数据又是以何种规则对外输出这些都需要在编码前考虑好。
2、Api需要对入参做必要验证。
3、需要提供统一的验证机制，在一定程度上防止遭遇恶意请求。
4、增加必要的日志记录，为以后的排查提供数据依据。
5、考虑Api的响应速度可以适当的引用缓存技术，比如Redis。
6、做好项目的文档记录。
以上就是我的一些建议，我是一名开发人员，喜欢我的欢迎关注🍀🍀🍀🍀🍀🍀🍀
陆垚知玛丽
现在的Web开发基本都是多端共用同一Api,也就是当前最流行主导的前后端完全分离的模式去开发Api接口。
而我们通常用的最正规标准的又是Restful Api。就是在定义接口的时候不像以前那样随心所欲的想怎么定义就怎么定义，基本都是按照固定模式，达到见名知意基本不需要看接口注释就知道怎么调用。
就比如，现在大家都默认约定俗成的获取统一用Get请求，新增用Post请求，修改用Patch请求，删除用Delete请求，这样对于接口使用者从接口的请求方式就立马知道什么情况调用哪个指定接口，很方便高效。
Java高级开发
API接口设计个人觉得需考虑其扩展性能特别是对外公共接口，否则多个业务需求类似会存在两套API的情况，比较浪费资源。其次api名称，请求参数，返回结果必须有确定含义，容易上手，返回结果一般我设计时分为2部分，系统层面信息，业务层面信息，系统层面例如api调用异常，一般用约定好的错误码标识，业务层面就很宽泛，例如银行业务联网核查，查不到用户信息，从系统层面这是OK的，业务层面肯定是不行的，不可能用户在银行有账户却没有用户信息，当然可能数据库在做迁移导致暂时访问为空，这种业务错误也可以通过状态码或者状态标识boolean值+错误信息返回给客户端，这样api出问题可以快速定位是系统问题还是业务问题
