api接口类型有哪些_API设计的基本要求

api接口类型有哪些_API设计的基本要求

API的四种类型

远程过程调用（RPC）：通过作用在共享数据缓存器上的过程（或任务）实现程序间的通信。

文件传输：文件传输通过发送格式化文件实现应用程序间数据共享。

有时公司会将 API 作为其公共开放系统。也就是说，公司制定自己的系统接口标准，当需要执行系统整合、自定义和程序应用等操作时，公司所有成员都可以通过该接口标准调用源代码，该接口标准被称之为开放式 API。

API设计

背景

在给SupportedFu设计API的时候，我试图以实用的角度来解决上面提到的问题。我希望可以设计出容易使用，容易部署，并且足够灵活的API，本文因此而生。

API设计的基本要求

网上的很多关于API设计的观点都十分”学院派“，它们也许更有理论基础，但是有时却和现实世界脱轨（因此我是自由派）。所以我这篇文章的目标是从实践的角度出发，给出当前网络应用的API设计最佳实践（当然，是我认为的最佳了~），如果觉得不合适，我不会遵从标准。当然作为设计的基础，几个必须的原则还是要遵守的：

当标准合理的时候遵守标准。

API应该对程序员友好，并且在浏览器地址栏容易输入。

API应该简单，直观，容易使用的同时优雅。

API应该具有足够的灵活性来支持上层ui。

API设计权衡上述几个原则。

需要强调的是：API的就是程序员的UI，和其他UI一样，你必须仔细考虑它的用户体验！

那么我应该如何拆分出这些资源呢？

显然从API用户的角度来看，”资源“应该是个名词。即使你的内部数据模型和资源已经有了很好的对应，API设计的时候你仍然不需要把它们一对一的都暴露出来。这里的关键是隐藏内部资源，暴露必需的外部资源。

一旦定义好了要暴露的资源，你可以定义资源上允许的操作，以及这些操作和你的API的对应关系：

GET /tickets/12 # 查看某个具体的ticket

POST /tickets # 新建一个ticket

PUT /tickets/12 # 更新ticket 12.

DELETE /tickets/12 #删除ticekt 12

这个endpoint的单数复数

一个可以遵从的规则是：虽然看起来使用复数来描述某一个资源实例看起来别扭，但是统一所有的endpoint，使用复数使得你的URL更加规整。这让API使用者更加容易理解，对开发者来说也更容易实现。

如何处理关联？关于如何处理资源之间的管理REST原则也有相关的描述：

GET /tickets/12/messages- Retrieves list of messages for ticket #12

GET /tickets/12/messages/5- Retrieves message #5 for ticket #12

POST /tickets/12/messages- Creates a new message in ticket #12

PUT /tickets/12/messages/5- Updates message #5 for ticket #12

PATCH /tickets/12/messages/5- Partially updates message #5 for ticket #12

DELETE /tickets/12/messages/5- Deletes message #5 for ticket #12

不符合CURD的操作

对这个令人困惑的问题，下面是一些解决方法：

重构你的行为action。当你的行为不需要参数的时候，你可以把active对应到activated这个资源，（更新使用patch）。

以子资源对待。例如：github上，对一个gists加星操作：PUT /gists/：id/star 并且取消星操作：DELETE /gists/：id/star.

有时候action实在没有难以和某个资源对应上例如search。那就这么办吧。我认为API的使用者对于/search这种url也不会有太大意见的（毕竟他很容易理解）。只要注意在文档中写清楚就可以了。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。