目录

前文列表

用 Flask 来写个轻博客 (1) — 创建项目
用 Flask 来写个轻博客 (2) — Hello World！
用 Flask 来写个轻博客 (3) — (M)VC_连接 MySQL 和 SQLAlchemy
用 Flask 来写个轻博客 (4) — (M)VC_创建数据模型和表
用 Flask 来写个轻博客 (5) — (M)VC_SQLAlchemy 的 CRUD 详解
用 Flask 来写个轻博客 (6) — (M)VC_models 的关系(one to many)
用 Flask 来写个轻博客 (7) — (M)VC_models 的关系(many to many)
用 Flask 来写个轻博客 (8) — (M)VC_Alembic 管理数据库结构的升级和降级
用 Flask 来写个轻博客 (9) — M(V)C_Jinja 语法基础快速概览
用 Flask 来写个轻博客 (10) — M(V)C_Jinja 常用过滤器与 Flask 特殊变量及方法
用 Flask 来写个轻博客 (11) — M(V)C_创建视图函数
用 Flask 来写个轻博客 (12) — M(V)C_编写和继承 Jinja 模板
用 Flask 来写个轻博客 (13) — M(V)C_WTForms 服务端表单检验
用 Flask 来写个轻博客 (14) — M(V)C_实现项目首页的模板
用 Flask 来写个轻博客 (15) — M(V)C_实现博文页面评论表单
用 Flask 来写个轻博客 (16) — MV(C)_Flask Blueprint 蓝图
用 Flask 来写个轻博客 (17) — MV(C)_应用蓝图来重构项目
用 Flask 来写个轻博客 (18) — 使用工厂模式来生成应用对象
用 Flask 来写个轻博客 (19) — 以 Bcrypt 密文存储账户信息与实现用户登陆表单
用 Flask 来写个轻博客 (20) — 实现注册表单与应用 reCAPTCHA 来实现验证码
用 Flask 来写个轻博客 (21) — 结合 reCAPTCHA 验证码实现用户注册与登录
用 Flask 来写个轻博客 (22) — 实现博客文章的添加和编辑页面
用 Flask 来写个轻博客 (23) — 应用 OAuth 来实现 Facebook 第三方登录
用 Flask 来写个轻博客 (24) — 使用 Flask-Login 来保护应用安全
用 Flask 来写个轻博客 (25) — 使用 Flask-Principal 实现角色权限功能
用 Flask 来写个轻博客 (26) — 使用 Flask-Celery-Helper 实现异步任务
用 Flask 来写个轻博客 (27) — 使用 Flask-Cache 实现网页缓存加速
用 Flask 来写个轻博客 (29) — 使用 Flask-Admin 实现后台管理 SQLAlchemy
用 Flask 来写个轻博客 (30) — 使用 Flask-Admin 增强文章管理功能
用 Flask 来写个轻博客 (31) — 使用 Flask-Admin 实现 FileSystem 管理

扩展阅读

cookie 和 session 的区别详解

RESTful API

REST(Representational State Transfer)：是一种软件架构的设计风格，而不是一种标准。主要用于 C/S 架构的软件设计，也能很好的支持 B/S 架构，为软件设计提供了一组原则和约束条件，但这些原则和约束的条件均不具有标准性。所以 REST 可以理解为是一组没有严格标准的架构约束条件和设计原则。而满足 REST 风格的应用或设计，就是 RESTful.

API: 为外部提供了可以访问应用程序内容数据资源和业务资源的接口, 并且这个接口应该是统一的, 不依赖于硬件平台/软件操作系统/编程语言的.

REST 原则

无状态原则

REST 具有通过 HTTP/HTTPS(无状态传输协议) 直接传输数据(XML/JSON)的特性, 所以 C/S 或 B/S 之间的交互请求是无状态的. 相对的, 在 <<用 Flask 来写个轻博客>> 系列博文中 Flask-Login 的实现, 其需要通过 session(Server) 和 cookie(Browser/client) 结合来实现在服务器端或客户端中保存用户的身份和登录状态, 以此来实现不同的用户在不同的页面中可以具有不同访问权限的效果. REST 会使用另外的方式来这个目的, 例如 Openstack 中的 Keystone 认证中间件.

面向资源

资源以 URI(统一资源标识符) 的形式向外部公开, 以 URL(统一资源定位器) 的形式来访问获取. 大概而言, 服务器端 Application 的所有概念都可以定义为一种资源. 使用 URL/URI 能够更好的契合 HTTP/HTTPS 协议, 结合 HTTP/HTTP 协议的内置 Methods(GET/POST/PUT/DELETE) 可能非常方便的实现对资源的 CRUD 数据操作, 除此之外还能够自定义出不同的 action 方法并将其绑定到不同的 URL 中来扩展请求的类型, 实现了不仅限于资源的业务逻辑操作. EG. Openstack Nova 中的资源 server, 其含有的 ../os-start, ../os-stop 等 URL, 对应了 启动/关闭 虚拟机的业务操作. 总的来说, 每个资源都使用唯一的 URI 标识, 而资源的 URL 就是 HTTP 方法调用的目标.

URI: protocol://hostname[:port]/path 定义了某一类资源
URL: protocol://hostname[:port]/path/[;parameters][?query]#fragment 定义了某一个具体的资源单位

所以 URL 一般都理解为 URI 的子集.

RESTful API 的优势

基于状态与基于无状态 service 在分布式系统中的区别与理解:
(因水平问题, 并不严谨, 仅为当下的理解, 欢迎指正)
前者, 客户端的 Cookie 中保存了 session_id, 如果在服务器中该 session_id 对应的 Session 仍然存在的话将会由该 Session 来继续维护用户请求的状态等公共信息. 但问题是, 如果在这个过程中该服务器宕机的话, 则需要重新在另外一台服务器中新建一个 Session 并与客户端建立再次连接并生成 Cookie, 显然在分布式系统中这个过程是比较无谓. 这就是基于状态的 Web service 的分布式系统的弊端, 所有的服务器都需要维护用户请求状态. 在这个前提下, 提出了类似于 LDAP(用户信息集中管理服务器) 这样的状态集中管理机制, 由单独的一台或一类服务器或服务来为整个分布式系统提供身份鉴权功能模块. 那么其先决条件当然就是, 所有的用户请求都必须是无状态的, 不再有所有的服务器都维护着用户请求状态等公共信息的情况发生. 而且还需要引入别的实现方式来满足这一方面的需求, 在 Openstack 中就引入了 Keystone 身份认证服务. 这样做的好处还在于改善了分布式系统的可靠性以及可伸缩性.

所以 RESTful API 的优势在于:

• 解耦了客户端和服务器
• 高可靠
• 易扩展
• 不依赖与平台和语言
• 简单轻量

REST 约束

注意: 这里的约束是针对这次的 blog 项目所设计的, 并部一定完全设用于所有应用场景, 需要结合实际进行改进, 所以不应满足与使用, 而是要在不断的实践中加深对 REST 的理解和累积经验.

• 客户端和服务端关心的业务是完全分离的, 前者不能处理数据的持久化, 后者不能处理与用户页面表现层相关的逻辑. 在 blog application 中, 整个项目都会作为服务端.

• 服务端是无状态的, 请求与响应的过程中服务端不会保留任何的 session 等状态信息. 处理请求所需要的信息都会被存储在客户端中, 或者被每一次单独的请求所携带. Flask Application 接受的每一个请求都可以携带保存在客户端中的 cookie 数据, 再交由服务端解析并以此判断权限等信息, 但不保留.

• 服务端公布的所有资源都必须保证统一的接口形似, 即 :

  • 接口必须是基于资源的
  • 不直接返回数据库中的数据而是包装成为 JSON 或 XML 等形式后返回
  • 所有资源都应用一致的包装形式
  • 服务端返回的数据应该足够完整能够满足客户端的业务需求

• 允许中间层的存在, EG. 能够支持使用 负载均衡/代理/缓存 等中间层服务

• 返回正确的 HTTP/HTTPS 状态码