前文《Kubernetes官网java客户端之三：内部利用》中，咱们开发了一个名为<font color=”blue”>OutsideclusterApplication</font>的SpringBoot利用，该利用并未部署在K8S环境，而是近程拜访K8S环境外部的API Server，整体构造如下：

最近有个我的项目须要对外提供一个接口，提供公网域名进行拜访，而且接口和交易订单无关，所以安全性很重要；这里整顿了一下罕用的一些安全措施以及具体如何去实现。

以下提到的<font color=”blue”>java客户端</font>都是指<font color=”red”>client-jar.jar</font>；

由文档驱动的API开发使开发团队在理论编写一行代码之前就能够思考从验收规范到UI和用户体验的所有内容，然而，它可能会减慢初始开发周期。在这些文档驱动的开发人员构建API之前，依赖于应用新设计的API的团队可能会碰壁。

API是应用程序的外围组成部分，API文档则具体记录如何应用应用程序，以及当应用程序呈现问题时，帮忙技术人员疾速定位问题。一份欠缺的API文档应思考到API的方方面面，甚至是API开发的交接工作。

接口全称是应用程序编程接口，是应用程序重要的组成部分。接口能够是一个性能，例如天气查问，短信群发等，接口也能够是一个模块，例如登录验证。接口通过发送申请参数至接口url，通过后盾代码解决后，返回所需的后果。

API文档是我的项目开发必备的文档之一，且随着我的项目一直的API化，API文档也越发重要。因为API文档不仅蕴含API根本信息，还蕴含API示例等，并且测试人员也须要应用API文档对API进行测试，所以传统的Office文档曾经逐步不能满足咱们的需要，抉择一个弱小的API管理工具，是我的项目开发与前期保护的要害。

在Eolinker中，有三个中央能够导入Swagger 1、在我的项目列表导入，因为设计了绑定SwaggerID，导入后的api是有SwaggerID的，后续进行同步没有问题。无论是增量，全量，仅增加API都只有一个，而且按Swagger最新的数据来更新；

我花了几天工夫到处百度，谷歌，技术博客 和 论坛查资料，先后调研了如下文档生成工具：一、gitbook开发语言：javascript用户：50万+示例地址：[链接]

软件工程的两种办法下，由后端决定接口都是不对的。第一种软件工程的办法：瀑布模型，自顶而下，逐渐细化。接口会变，然而接口要提前设计。接口不是后端开发实现之后才“天然”产生的，那不是天然，而是无序。前后端拆散的开发，应该是面向“API”的开发。API的设计并不能由前端或后端一方决定或主导，而是须要一个前后端都…