到底什么是 REST/RESTful API?

=Start=

缘由:

一直都在听别人说什么REST/RESTful API的,之前也找过一些资料进行查看,但是看完了之后也是云里雾里的,没有什么比较明确、清晰的概念。最近又想了解一下这个概念了,所以又找资料看看,希望能有一个大致的概念,起码在和别人聊起来的时候不至于糊里糊涂的。

正文:

参考解答:

首先要明确一点:REST 实际上只是一种设计风格,它并不是标准。

  1. REST 是面向资源的,这个概念非常重要,而资源是通过 URI 进行暴露。
  2. REST很好地利用了HTTP本身就有的一些特征,如HTTP动词、HTTP状态码、HTTP报头等等。

用 URL 定位资源,用 HTTP动词(GET,POST,PUT,DELETE,..) 描述操作,用 HTTP状态码 表示操作结果。即:

  • 看 Url 就知道要什么;
  • 看 HTTP Method 就知道干什么;
  • 看 HTTP Status Code 就知道结果如何。
参考链接:

=END=

声明: 除非注明,ixyzero.com文章均为原创,转载请以链接形式标明本文地址,谢谢!
https://ixyzero.com/blog/archives/4422.html

《到底什么是 REST/RESTful API?》上有11条评论

  1. 正确甄别API & REST API & RESTful API & Web Service之间的差异与联系
    https://juejin.im/post/5d07317e6fb9a07eac05d33c

    1、API 与 REST API
    通俗的讲,API是一段应用程序与另一段应用程序相互“交流”的方式(协议)。
    REST是Representational State Transfer的缩写,直译过来就是:表述状态的转移。REST API是一组关于如何构建Web应用程序API的架构规则、标准或指导,或者说REST API是遵循API原则的一种架构风格。REST是专门针对Web应用程序而设计的,其目的在于降低开发的复杂度,提高系统的可伸缩性。

    2、REST API 与RESTful API
    3、REST与Web Service
    3-1、什么是Web Service?
    3-2、Web Service的优点
    3-3、Web Service的类型
    ​ 目前,Web Service主要有两大流派:
    1、基于SOAP的Web Service : SOAP(简单对象访问协议)是一种基于XML的协议,用以访问Web Service。其接口以机器可处理的格式进行描述,称为WSDL(Web服务定义语言)文档。通过使用标准的的XML文档来描述Web Service,在XML文件中,会详细记录接口的信息,如消息的格式、传输协议以及交互的位置等信息。
    2、基于REST的Web Service :REST(Representational State Transfer)是一种软件架构,它使用JSON来描述数据格式,最重要的是HTTP传输协议对REST来说是非必须的。

    3-4、REST与SOAP的区别和联系
    总结

  2. RESTful API设计 最佳实践。
    https://blog.p2hp.com/archives/6437
    https://phauer.com/2015/restful-api-design-best-practices/

    设计HTTP和RESTful API可能很棘手,因为没有官方和强制标准。基本上,有许多方法可以实现API,但其中一些已在实践中得到证实,并且已被widley采用。这篇文章介绍了构建HTTP和RESTful API的最佳实践。我们将讨论URL结构,HTTP方法,创建和更新资源,设计关系,有效负载格式,分页,版本控制等等。

  3. 将token等认证信息放在URL参数中的危害及其缓解方法(Never Put Secrets in URLs and Query Parameters)
    https://www.fullcontact.com/blog/never-put-secrets-urls-query-parameters/

    They get saved in browser history.
    They’re probably saved in your server’s logs and memory.
    Users might post the link, not realizing what they’ve shared.
    This information will be exposed in the “referrer” header.
    They’re available to browser extensions.

    漏洞场景:
    被保存在浏览器历史记录中
    被保存在服务器日志中
    无意识的敏感链接分享
    被保存在 referer 中
    可被浏览器扩展获取到
    可被搜索引擎检索到

    解决方案:
    将认证信息放在header中
    token过期时间设置
    一次性token
    敏感接口接入风控和二次认证

  4. GraphQL正在超越REST
    https://mp.weixin.qq.com/s/ewL8B7ZqxkELpwT_FzTAaQ

    # GraphQL的优点与挑战

    使用GraphQL的主要好处是,可以在单个请求中获得所需的全部内容,而使用REST,人们往往倾向于“过度获取”或“获取不足”。

    GraphQL简单,更快速,但是,当组合多个字段时,可能会遇到无法预测的性能问题。

    另一个挑战是版本控制。人们将不得不弃用一些字段,也无法知道字段是否随着时间发生了变化。

    GraphQL的另一缺点是缓存问题。在GraphQL中,不能将URL加入缓存标识符,这需要在应用程序中创建唯一键值来实现缓存。

    还有一部分额外的开销,因为服务器需要执行更多处理来解析查询与验证参数。

    最后,如果只是一些简单API的情况下,使用GraphQL增加额外复杂度并不值得。

    # 结论

    GraphQL类似于位于下游服务或数据源之前的API网关或代理服务器。就如同HTTP一样,可以使用动词来获得要求的内容。它也是REST,SOAP或gRPC的替代品,但这并不意味着必须替代当前的体系结构。比如,可以在REST服务之上安装GraphQL。

    GraphQL技术正变得越来越成熟,可用于多种语言,包括JavaScript,PHP,Python,Ruby,C#,Go,Scala或Java,而Pivotal等公司也大力倡导GraphQL。在实际应用中,它也是Spring IO 2019中提出的关键主题之一。

  5. 开发安全的 API 所需要核对的清单
    https://github.com/shieldfy/API-Security-Checklist/blob/master/README-zh.md

    以下是当你在设计, 测试以及发布你的 API 的时候所需要核对的重要安全措施.

    身份认证
    *  不要使用 Basic Auth 使用标准的认证协议 (如 JWT, OAuth).
    *  不要再造 Authentication, token generating, password storing 这些轮子, 使用标准的.
    *  在登录中使用 Max Retry 和自动封禁功能.
    *  加密所有的敏感数据.

    JWT (JSON Web Token)
    *  使用随机复杂的密钥 (JWT Secret) 以增加暴力破解的难度.
    *  不要在请求体中直接提取数据, 要对数据进行加密 (HS256 或 RS256).
    *  使 token 的过期时间尽量的短 (TTL, RTTL).
    *  不要在 JWT 的请求体中存放敏感数据, 它是可破解的.

    OAuth 授权或认证协议
    *  始终在后台验证 redirect_uri, 只允许白名单的 URL.
    *  每次交换令牌的时候不要加 token (不允许 response_type=token).
    *  使用 state 参数并填充随机的哈希数来防止跨站请求伪造(CSRF).
    *  对不同的应用分别定义默认的作用域和各自有效的作用域参数.

    访问
    *  限制流量来防止 DDoS 攻击和暴力攻击.
    *  在服务端使用 HTTPS 协议来防止 MITM 攻击.
    *  使用 HSTS 协议防止 SSLStrip 攻击.

    输入
    *  使用与操作相符的 HTTP 操作函数, GET (读取), POST (创建), PUT (替换/更新) 以及 DELETE (删除记录), 如果请求的方法不适用于请求的资源则返回 405 Method Not Allowed.
    *  在请求头中的 content-type 字段使用内容验证来只允许支持的格式 (如 application/xml, application/json 等等) 并在不满足条件的时候返回 406 Not Acceptable.
    *  验证 content-type 的发布数据和你收到的一样 (如 application/x-www-form-urlencoded, multipart/form-data, application/json 等等).
    *  验证用户输入来避免一些普通的易受攻击缺陷 (如 XSS, SQL-注入, 远程代码执行 等等).
    *  不要在 URL 中使用任何敏感的数据 (credentials, Passwords, security tokens, or API keys), 而是使用标准的认证请求头.
    *  使用一个 API Gateway 服务来启用缓存、访问速率限制 (如 Quota, Spike Arrest, Concurrent Rate Limit) 以及动态地部署 APIs resources.

    处理
    *  检查是否所有的终端都在身份认证之后, 以避免被破坏了的认证体系.
    *  避免使用特有的资源 id. 使用 /me/orders 替代 /user/654321/orders
    *  使用 UUID 代替自增长的 id.
    *  如果需要解析 XML 文件, 确保实体解析(entity parsing)是关闭的以避免 XXE 攻击.
    *  如果需要解析 XML 文件, 确保实体扩展(entity expansion)是关闭的以避免通过指数实体扩展攻击实现的 Billion Laughs/XML bomb.
    *  在文件上传中使用 CDN.
    *  如果需要处理大量的数据, 使用 Workers 和 Queues 来快速响应, 从而避免 HTTP 阻塞.
    *  不要忘了把 DEBUG 模式关掉.

    输出
    *  发送 X-Content-Type-Options: nosniff 头.
    *  发送 X-Frame-Options: deny 头.
    *  发送 Content-Security-Policy: default-src 'none' 头.
    *  删除指纹头 - X-Powered-By, Server, X-AspNet-Version 等等.
    *  在响应中强制使用 content-type, 如果你的类型是 application/json 那么你的 content-type 就是 application/json.
    *  不要返回敏感的数据, 如 credentials, Passwords, security tokens.
    *  在操作结束时返回恰当的状态码. (如 200 OK, 400 Bad Request, 401 Unauthorized, 405 Method Not Allowed 等等).

    持续集成和持续部署
    *  使用单元测试和集成测试来审计你的设计和实现.
    *  引入代码审查流程, 不要自行批准更改.
    *  在推送到生产环境之前确保服务的所有组件都用杀毒软件静态地扫描过, 包括第三方库和其它依赖.
    *  为部署设计一个回滚方案.

    也可以看看:
    * yosriady/api-development-tools - 用于构建RESTful HTTP+JSON API的有用资源集合。

    https://github.com/yosriady/api-development-tools

发表评论

电子邮件地址不会被公开。 必填项已用*标注