ARTS - Week 6

Share

RESTful服务（上）：从面向过程编程到面向资源编程

这次 share 的周志明的两篇文章，是我目前看过的把 RESTful 解释的最清晰的文章，曾几何时，有多少次打开 Google 想弄明白到底什么是 RESTful，为什么要 RESTful，都没有找到答案，因此这次真的是全程跪着看完的。

1. 从 Paper 的作者入手，文中提到 RESTful 概念论文的作者 Roy Fielding 是 Apache 服务器的开发者，同时他既是 HTTP 1.0 协议的专家组成员，又是 HTTP 1.1 协议的负责人。用来指导设计 HTTP 1.1 协议的理论和思想，最早是以备忘录的形式在专家组成员直接传递和交流的，这个备忘录就是 RESTful 的雏形。

2. Representational State Transfer（REST），这个让人不知所云的“表征状态转移”到底是啥？其实它就是 HTTP 里的 HTT（Hyper Text Transfer）的进一步抽象。

3. 突然发现自己其实一直没有理解什么是“超文本”。因为当我在这个年代接触编程时，自然而然的觉得，像 HTML 这样的纯文本文件，其中的一段文字可以点击、可以触发脚本执行、可以调用服务端，都已经非常平常，毫不稀奇了。然而当“超文本”这个概念在 1960 年被提出来的时候，应该还属于科幻的范畴。

4. 而所谓的“表征（Representation）”其实就是资源的一种表现形式，比如一篇博客在浏览器以 HTML 形式表现，也可以以 PDF，markdown 等其他形式体现。在这里，“博客”是一种资源，HTML 是一种“表征”

5. 当你读完当前这一篇博客后，想点击按钮“下一篇”来读取，这时就会出现“状态”的概念，你的当前状态是你正在读的博客，你的下一个状态是“下一篇博客”

6. 至此，一个读博客的过程就是一个完整的表征状态转移的过程。

7. 都说 RESTful 是一种架构风格，是一种理念，而 RESTful 理念的核心就是“面向资源”

8. RESTful 希望软件系统设计的重点放在抽象系统有哪些资源上，而不是抽象系统有哪些行为上

9. 例如系统的登录、登出是一种行为的抽象，通常被设计成 login、logout 两个行为的接口，而如果换做 RESTful 风格的设计，就应当将登录、登出设计为对 Session 这个资源的抽象，登录对应 addSession 接口，登出对应 deleteSession 接口

10. To Be Continue...

Review

来自 Laurence McCahill 的How to Build a Minimum Loveable Product

貌似是第一次看这种“产品经理该看的文章” :)

文章提到了两个很有意思的观点

• 一个是类似 CAP 理论的一个东西，指的是一个产品：

• GOOD & CHEAP won't be FAST

• FAST & GOOD won't be CHEAP

• CHEAP & FAST won't be GOOD

• 另一个是说一个好的产品不应该以满足所有人为目标，而是满足你最忠实的那一群人，为他们做一个“最小可爱的产品”，不禁让我想到川普拉票，只要把自己票仓里的人关心好就 OK 了。：）

不过我确实很认同作者的这两个观点！

Tips

JDK 8 Optional 的典型使用场景

Optional 貌似是 JDK 8 里一个一直被我遗忘的特性，这次终于碰到一个典型的“用武之地”了。

不知道是不是所有人第一次使用 Optional 都像我一样：

// 这是没有Optional的日子Object o = new Object();if (o == null) {  // do something here}
// 这是有了Optional的日子Object o = new Object();Optional<Object> optional = Optional.of(o);if (optional.isPresent()){  // do something here}

这 TM 有什么用。。

其实，Optional 主要是用来解决链式调用下令人恶心的 NPE。典型场景如下：

通常网络调用其他系统接口时，都会返回一个如下类似的 Response 对象：

public class ApiResponse<T> {  private Integer code = 0;  private String msg;  private T result;}  

如果泛型 T 是 List 对象，通常处理 Response 的代码都是这样：

Response resp = RPC.call();// 保证resp不为空， resp.getResult也不为空，避免直接调用resp.getResult()报NPEif (Objects.isNull(resp) || Objects.isNull(resp.getResult()) {	return new Arraylist<>();}// code == 0才是正常返回if (resp.getCode() != 0) {	return new ArrayList<>();}return resp.getResult();

这么写可以但是不够优雅，这个时候用 Option 就会变成这样：

Response resp = RPC.call();return Optional.ofNullable(resp)  .filter(r -> r.getCode() == 0)  .map(r -> r.getResult())  .orElse(new ArrayList<>());

End

：)

Algorithm

写了三个一个系列的链表题恢复一下手感，这次准备用 Go 写，顺便练练 Go 的基本语法

206. 反转链表

92. 反转链表 II

25. K 个一组翻转链表

这几个链表题都用的同一个反转算法。

没什么特别的，链表题感觉只要画的出来过程就基本上解的出来。

主要是要在纸上画流程，否则指针指来指去的非常容易混乱。