学习总结：WorkShop（一)

基于RestfulAPI的Service服务-Micro-Service to ingestion auto seller data

• What is a /Workshop/?(2 min)
• Rest API introduction (5 min)
• Workshop demo Q & A.(10~15 min)
• New requirement introduction and analysis (5 min)
• Task separation (20 min)
• Work out solution (20 min)
• AML (20 min)
• Pair programming (TDD?) (1 hour)
• Docker & Deployment (30 min)
• Free talk (30 min ~ 1 hour)</br>
  
  初入IT行业，承蒙老师（阿尔法二狗）指引，于17年6月10日在thoughtwork开始生涯中第一次Workshop，
  记录下学习心得，以备日后查看。新手上路，大佬们多多指教。

一、Workshop

Workshop最早的定义为，由几个人进行密集讨论的集会，通常需要当场练习，后续在IT行业广为
推广，为求“跳脱喧嚣、远离噪音、沉下心一起做一次深潜”为愿景。

二、Restful架构

1、概述

"互联网软件"采用客户端/服务器模式，建立在分布式体系上，通过互联网通信，具有高延时、
高并发等特点。网站开发，完全可以采用软件开发的模式。但是传统上，软件和网络是两个不同的领
域，很少有交集；软件开发主要针对单机环境，网络则主要研究系统之间的通信。互联网的兴起，使
得这两个领域开始融合，现在我们必须考虑，如何开发在互联网环境中使用的软件。

    RESTful架构，就是目前最流行的一种互联网软件架构。它结构清晰、符合标准、易于理解、

 扩展方便，所以正得到越来越多网站的采用。（引用自：阮一峰博客“理解restful构架”）

REST（Representational State Transfer）如果一个架构符合REST原则，就称它为
RESTful架构。

      ps：Representational State Transfer 中，这里省略了主语Resource，State为资
 源的状态，Reset可以理解为用户在使用互联网软件的过程中，资源的状态的转化。（个人理解）

2、分类说明

1）资源（resource）

资源，即为网络上的具体信息。文字、图片、音频等等都可以视为资源。每一种资源都有与之对应的
特定的URI，想要获取特定的资源，就要访问与之相对应的URI。
eg：Uri resource（/companies/{id}/employees/{id}）

2）表述性（representational）

资源是一种信息，信息有各种各样不同的表述方式，具体的表述方式就是资源的表述性。

    eg：文本资源的表述性可以为：TXT,HTML,XML,JSON等。

3）状态转换（state transfer）

 互联网通信协议HTTP协议，是一个无状态协议。这意味着，所有的状态都保存在服务器端。因此，

 如果客户端想要操作服务器，必须通过某种手段，让服务器端发生"状态转化"（State Transfer）。
 而这种转化是建立在表现层之上的，所以就是"表现层状态转化"。
 (引用自：阮一峰博客“理解restful构架”）

具体来讲就是HTTP协议下常用的四种方法：GET（查找）、POST（新增）、PUT（更新）、DELETE（删除）

三、Service Demo Q&A

• Q：阅读完全未接触过的代码时，使用什么方式可以快速的了解代码的架构。</br>
  A：对于Rest API架构的代码来说，可以通过Controller快速了解RestAPI构成，阅读modules可以快速
  的了解项目数据结构。

• Q：Rest API架构的项目开发过程中，有哪些实用的工具。</br>
  A:

  1. Curl:curl是利用URL语法在命令行方式下工作的开源文件传输工具</br>
  2. postman:自带UI的Web开发工具，更加方便实用和测试</br>
  3. Raml:RAML的全称是RESTful API建模语言，这是一种基于YAML格式的新规范，人机都能很好的理解。

• Q：测试代码的原理。</br>
  A: 设定好被测模块的运行目标，当测试代码得到该结果时，证明被测模块功能正常。

四、完整的项目开发模块和需求分析方法

1、项目开发模块

 Project{
    Coding{
        Dao
        Controller
        Service
        Model
        ...
    }
    Doc{}
    Test{
      UI AutoTest
      UnitTest{
          Junti
         ...
      }
    }
    Deploy{}
 }

2、需求分析方法

在收到客户需求后，一定不能直接根据大致的理解就进行项目的开发，这个时候的Coding大部分都是废品，
在理清需求之后大部分，甚至全部代码都需要返工，所有盲目的编写代码是项目开发中最大的忌讳，而与之
相对的，分析客户需求成了重中之重。</br></br>
首先，对需求进行分级，用户提出的需求作为最高等级。从最高等级的需求开始拆分，将需求尽量的细化成
一个一个有逻辑关联的单功能模块，便于分单元开发与测试。</br></br>
一般需求都会拆分两至三次，最低级的需求要求实现单一功能，设计好模块的输入和要求的输出。完成好最
低级需求的分析后才可开始按模块的进行开发。</br></br>
建议：开发与测试同步进行。