展开

关键词

HTTP API 设计指南HTTP API 设计指南

HTTP API 设计指南 前言 这篇指南介绍描述了 HTTP+JSON API 的一种设计模式,最初摘录整理自 Heroku 平台的 API 设计指引 Heroku 平台 API 指引。 这篇指南除了详细介绍现有的 API 外,Heroku 将来新加入的内部 API 也会符合这种设计模式,我们希望非 Heroku 员工的API设计者也能感兴趣。 我们的目标是保持一致性,专注业务逻辑同时避免过度设计。我们一直试图找出一种良好的、一致的、显而易见的 API 设计方法,而并不是所谓的"最终/理想模式"。 我们假设你熟悉基本的 HTTP+JSON API 设计方法,所以本篇指南并不包含所有的 API 设计基础。 强制头信息 Accept 中提供版本号 制定版本并在版本之间平缓过渡对于设计和维护一套API是个巨大的挑战。所以,最好在设计之初就使用一些方法来预防可能会遇到的问题。

34631

API如何设计

在之前《应对变化》[1]中提到模块之间合的策略:缩小依赖范围,API是两个模块间唯一的联结点 ? 怎么才是一个好的API设计呢? 设计成: systemB.receive(long userId,String username,Object data); 一切都是行云流水,大家都很happy,如期发布上线 爱情总是在转角处遇到,上线完 系统A:太麻烦了,你自己取了,想怎么控制就怎么控制 系统B:你是不爱我了 系统A:你怎么就不理解我呢 ---- 温习一下一个好的API设计要求: 缩小依赖范围,就是要精简APIAPI要稳定得站在需求角度 因为任何一项知识的变化都会导致双方变化2.API也要高内聚,不应强迫API的客户依赖不需要的东西3.站在what角度;而不是how,怎么技术实现的角度 上面示例的问题就在系统B接受数据api: systemB.receive ,但回头复盘,发现了很多理论缺乏,惯性思维使然造成的不合理,难维护,难扩展的设计 由此看出,日常的CRUD并不是没有技术含量,而是我们有没有深刻认知 References [1] 《应对变化》: http

17110
  • 广告
    关闭

    【玩转 Cloud Studio】有奖调研征文,千元豪礼等你拿!

    想听听你玩转的独门秘籍,更有机械键盘、鹅厂公仔、CODING 定制公仔等你来拿!

  • 您找到你想要的搜索结果了吗?
    是的
    没有找到

    API Gateway 设计

    1.1 什么是API网关 API网关可以看做系统与外界联通的入口,我们可以在网关进行处理一些非业务逻辑的逻辑,比如权限验证,监控,缓存,请求路由等等。 1.2 为什么需要API网关 RPC协议转成HTTP。 1.3 统一API网关 统一的API网关不仅有API网关的所有的特点,还有下面几个好处: 统一技术组件升级 在公司中如果有某个技术组件需要升级,那么是需要和每个业务线沟通,通常几个月都搞不定。 在Netflix Zuul中也应用了这种模式,如下图所示: image 这种模式在网关的设计中我们可以借鉴到自己的网关设计: preFilters:前置过滤器,用来处理一些公共的业务,比如统一鉴权,统一限流 1.基本流控:基于API的QPS做限流。2.运营流控:支持APP流量包,APP+API+USER的流控33.大促流控:APP访问API的权重流控。

    11900

    RESTful API 设计指南

    这导致API构架的流行,甚至出现"API First"的设计思想。RESTful API是目前比较成熟的一套互联网应用程序的API设计理论。 今天,我将介绍RESTful API设计细节,探讨如何设计一套合理、好用的API。我的主要参考了两篇文章(1,2)。 ? 一、协议 API与用户的通信协议,总是使用HTTPs协议。 举例来说,有一个API提供动物园(zoo)的信息,还包括各种动物和雇员的信息,则它的路径应该设计成下面这样。 animal_type_id=1:指定筛选条件 参数的设计允许存在冗余,即允许API路径和URL参数偶尔有重复。比如,GET /zoo/ID/animals 与 GET /animals? Hypermedia API设计被称为HATEOAS。Github的API就是这种设计,访问api.github.com会得到一个所有可用API的网址列表。

    59150

    RESTful API设计指南

    一、协议 API与用户的通信协议,总是使用HTTP/HTTPS协议。 二、域名路径 应该尽量将API部署在专用域名之下。 https://api.example.com 如果确定API很简单,不会有进一步扩展,可以考虑放在主域名下。 https://example.org/api/ 三、版本(Versioning) 应该将API的版本号放入URL。 举例来说,有一个API提供动物园(zoo)的信息,还包括各种动物和雇员的信息,则它的路径应该设计成下面这样。 https://api.example.com/v1/zoos https://api.example.com/v1/animals https://api.example.com/v1/employees

    21930

    RESTful API 设计指南

    SOAP(Simple Object Access protocol,简单对象访问协议)以及XML-RPC更加简单明了,无论是对URL的处理还是对Payload的编码,REST都倾向于用更加简单轻量的方法设计和实现 值得注意的是REST并没有一个明确的标准,而更像是一种设计的风格。 定义:简单来说REST是一种系统架构设计风格(而非标准),一种分布式系统的应用层解决方案。 举例来说,有一个API提供动物园(zoo)的信息,还包括各种动物和雇员的信息,则它的路径应该设计成下面这样。 animal_type_id=1:指定筛选条件 参数的设计允许存在冗余,即允许API路径和URL参数偶尔有重复。比如,GET /zoo/ID/animals 与 GET /animals? Hypermedia API设计被称为HATEOAS。Github的API就是这种设计,访问api.github.com会得到一个所有可用API的网址列表。

    40450

    RESTful API 设计指南

    这导致API构架的流行,甚至出现"API First"的设计思想。RESTful API是目前比较成熟的一套互联网应用程序的API设计理论。 今天,我将介绍RESTful API设计细节,探讨如何设计一套合理、好用的API。我的主要参考了两篇文章(1,2)。 一、协议 API与用户的通信协议,总是使用HTTPs协议。 举例来说,有一个API提供动物园(zoo)的信息,还包括各种动物和雇员的信息,则它的路径应该设计成下面这样。 animal_type_id=1:指定筛选条件 参数的设计允许存在冗余,即允许API路径和URL参数偶尔有重复。比如,GET /zoo/ID/animals 与 GET /animals? Hypermedia API设计被称为HATEOAS。Github的API就是这种设计,访问api.github.com会得到一个所有可用API的网址列表。

    28140

    php API设计实现

    如何设计错误码? 如果做版本控制? 版本信息写进请求头 url路由 框架选用? api路由解决出现post请求报错问题 默认走的是web.php路由,而web.php在laravel中是有csrf保护的,为了防止伪造跨站请求csrf,post请求必须带上token,具体操作见文档的

    17910

    RESTful API 设计指南

    这导致API构架的流行,甚至出现"API First"的设计思想。RESTful API是目前比较成熟的一套互联网应用程序的API设计理论。 今天,我将介绍RESTful API设计细节,探讨如何设计一套合理、好用的API。我的主要参考了两篇文章(1,2)。 一、协议 API与用户的通信协议,总是使用HTTPs协议。 举例来说,有一个API提供动物园(zoo)的信息,还包括各种动物和雇员的信息,则它的路径应该设计成下面这样。 animal_type_id=1:指定筛选条件 参数的设计允许存在冗余,即允许API路径和URL参数偶尔有重复。比如,GET /zoo/ID/animals 与 GET /animals? Hypermedia API设计被称为HATEOAS。Github的API就是这种设计,访问api.github.com会得到一个所有可用API的网址列表。

    4610

    Restful API 设计指北

    订阅本站 近期学习了Go语言,跟着七米在学习,学习过程中了解到了 API 的一个设计规范,也就是本文要讲的 Restful API 设计模式,现在互联网处在前后端分离的阶段,API 的书写及规范化是非常重要的 ,针对于 API 中 Restful API设计比较规范的是 Github API,可以直接访问他们的 https://api.github.com 直接查看 Github 针对与公共接口的链接及使用方法 1、使用 HTTPS 协议 这个协议使用本身与这个 API 设计标准没有什么直接联系,使用 HTTPS 协议主要目的是将用户客户端与 API 服务器链接过程中保证其数据的安全性 ?。 即使我们遵循了上面提到的所有规范,设计API 非常优雅,用户还是不知道怎么使用我们的 API。最后一步,但非常重要的一步是:为你的 API 编写优秀的文档。 参考资料 RESTful API 设计指南 – 阮一峰 跟着 Github 学习 Restful HTTP API 设计 REST API Tutorial Representational State

    27620

    API设计最佳实践

    良好设计API = 快乐的程序员 ?。 应用程序接口(API)是一种接口,它让应用程序可以轻松地使用另一个应用程序的数据和资源,API 对于一个产品或公司的成功至关重要。 如果没有它,你将不得不设计和开发自己的地图数据库。这样的话,在地图上显示一个位置需要花费多少时间? 为什么要使用 API? 在大多数实际场景中,数据模型 已经存在,但由于我们将讨论 API 设计最佳实践,我将从头开始说起。 数据建模与结构化 以 API 为中心对您的数据进行建模,是设计易于创建、维护和更新 API 的第一步 在设计 API 时,尽量考虑使用通用的术语,而不是使用内部的复杂业务术语,因为这些术语在公司外可能不为人所知 这些就是设计 API 的最佳实践。它让你的 API 更健壮、简洁并易于与其他应用程序集成。 请记住。 良好设计API = 快乐的程序员 ?。

    16220

    异步 API设计

    网站的前后端通信,往往会有异步请求,这时应该怎么设计 API? 我最近读到一篇文章,作者介绍了他的做法,设计得很精细,我觉得值得借鉴,可以当作异步 API 的标准设计。 一、同步 API 为了便于比较,先看看同步 API设计。下面是一个很简单的例子。 客户端发出一个请求,要求创建资源。 POST https://api.service.io/stars name='Death Star' 服务器回应 201。 GET https://api.service.io/queue/12345 服务器回应 200。 DELETE https://api.service.io/queue/12345 服务器回应 204。

    20231

    API接口TOKEN设计

    首先需要知道API是什么? API(Application Programming Interface)即应用程序接口。你可以认为 API 是一个软件组件或是一个 Web 服务与外界进行的交互的接口。 加密密钥'为私有的加密密钥,手机端需要在服务端注册一个“接口使用者”账号后,系统会分配一个账号及密码,数据表设计参考如下: 字段名及字段类型 client_id varchar(20) 客户端ID client_secret ($client_id); //服务端重新生成一个api_token $api_token_server = md5($module . $client_secret); //客户端传过来的api_token与服务端生成的api_token进行校对,如果不相等,则表示验证失败 if ($api_token ! user_token = md5('用户的uid' + 'Unix时间戳') = etye0fgkgk4ca2ttdsl0ae9a5dd77471fgf 服务端用数据表维护user_token的状态,表设计如下

    11830

    异步 API设计

    网站的前后端通信,往往会有异步请求,这时应该怎么设计 API? 我最近读到一篇文章,作者介绍了他的做法,设计得很精细,我觉得值得借鉴,可以当作异步 API 的标准设计。 一、同步 API 为了便于比较,先看看同步 API设计。下面是一个很简单的例子。 客户端发出一个请求,要求创建资源。 POST https://api.service.io/stars name='Death Star' 服务器回应 201。 GET https://api.service.io/queue/12345 服务器回应 200。 DELETE https://api.service.io/queue/12345 服务器回应 204。

    89620

    API接口TOKEN设计

    首先需要知道API是什么? API(Application Programming Interface)即应用程序接口。你可以认为 API 是一个软件组件或是一个 Web 服务与外界进行的交互的接口。 加密密钥'为私有的加密密钥,手机端需要在服务端注册一个“接口使用者”账号后,系统会分配一个账号及密码,数据表设计参考如下: 字段名及字段类型 client_id varchar(20) 客户端ID client_secret ($client_id); //服务端重新生成一个api_token $api_token_server = md5($module . $client_secret); //客户端传过来的api_token与服务端生成的api_token进行校对,如果不相等,则表示验证失败 if ($api_token ! user_token = md5('用户的uid' + 'Unix时间戳') = etye0fgkgk4ca2ttdsl0ae9a5dd77471fgf 服务端用数据表维护user_token的状态,表设计如下

    3.8K140

    RESTful API 设计详解

    设计概念和准则 所有事物都可以被抽象为资源。 每一个资源都有唯一的资源标识,对资源的操作不会改变这些标识。 所有操作都是无状态的。 但拒绝提供服务 404 Not Found 500 Internal Server Error 服务器不可预期的错误 503 Server Unavailable 服务器当前不能处理客户端的请求 设计要素 http://www.ruanyifeng.com/blog/2011/09/restful.html http://www.ruanyifeng.com/blog/2014/05/restful_api.html

    70840

    RESTful API设计--指南

    亚马逊是如何有效地使用 api 进行通信的最佳例子。 在这篇文章中,我将讨论如何更好地设计 RESTful api 以避免常见错误。 ---- RESTful api设计原则 现在,让我们来了解在设计 RESTful api 时应该遵循的原则。 保持精简 我们需要确保 API 的基本 URL 是简单的。 例如,如果我们想为产品设计 api,它应该是这样设计的: /products /products/12345 第一个 API 是获取所有产品,第二个 API 是获取特定产品。 OpenAPI 允许您首先设计 api,并以更简单的方式与消费者分享。 结论: 很明显,如果你想更好地交流,api 是一条路。但是如果它们设计得不好,可能会增加混乱。 因此,尽最大努力做好设计,剩下的只是实现。 ---- 感谢您的阅读 如果你遇到了一些更好的设计 api 的方法,请随时在评论部分分享这些方法。欢迎所有反馈!

    1K50

    聊聊rest api设计

    序 本文主要研究下rest api设计设计准则 easy to use & hard to misuse 易用不易误用,也就是api设计不要太复杂,要简单易用,而且还不能容易用错。 use case & document story api文档要围绕story或者use case来进行,在一个业务场景下提供完整的闭环操作。 版本不建议版本化,建议采用新的领域命名才与原有的api区分开来 输出规范 返回码遵循http的返回码规范,4xx表示客户端错误,5xx表示服务端错误。 的设计牵扯的方面比较多,本文暂时只是先列了一些,后续有待补充。 doc API设计要点 聊聊jpa的动态查询 使用RSQL实现端到端的动态查询

    34410

    逆向 AWS API 设计

    由于AWS并没有像Google一样公开出一份API Design Guide,所以只能根据 API 的模样去逆向工程最初的设计考量。 来看一个创建实例的 API,从这里就能明白 AWS 的设计风格了。 https://ec2.amazonaws.com/ ? 可以看出 AWS API设计最初就是希望能够一套方法操纵世界范围内的计算资源。 所有的 API 参数第一个部分都是 Action=xxx,可以看出来和 REST 围绕资源构造方法的思路不同,AWS API设计原则的中心就只有方法。 既然不需要围绕资源来构造方法,那么很多 API设计就会直白很多。

    46100

    浅谈API安全设计

    比如: 1.接口被大规模调用消耗系统资源,影响系统的正常访问,甚至系统瘫痪 2.数据泄露 3.伪造(篡改)数据,制造垃圾数据 4.App被仿制… 那么我们设计API时,就要保证RESTful API的安全性

    9610

    相关产品

    • 云 API

      云 API

      云 API 是腾讯云开放生态的基石。通过云 API,只需执行对应 API 命令行工具即可快速操作云产品;在熟练的情况下,使用一些频繁使用的功能,使用云 API 可以极大的提高效率;除此之外,通过API可以组合功能,实现更高级的功能,易于自动化, 易于远程调用, 兼容性强,对系统要求低。

    相关资讯

    热门标签

    活动推荐

    扫码关注腾讯云开发者

    领取腾讯云代金券