2017年6月19日

sql_mode ='STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION'

重啟mysql
sudo service mysql restart
mysql5.7以上版本在常會報關于only_full_group_by的錯誤，可以在sql_mode中關閉他，網上查找的解
查看參數是否存在
mysql> SELECT @@sql_mode;
+------------------------------------------------------------------------------------------------------------------------+
| @@sql_mode                                                                                                             |
+------------------------------------------------------------------------------------------------------------------------+
| STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION |
+------------------------------------------------------------------------------------------------------------------------+
1 row in set (0.00 sec)

mysql> SELECT @@GLOBAL.sql_mode;
+------------------------------------------------------------------------------------------------------------------------+
| @@GLOBAL.sql_mode                                                                                                      |
+------------------------------------------------------------------------------------------------------------------------+
| STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION |
+------------------------------------------------------------------------------------------------------------------------+
1 row in set (0.00 sec)

MYSQL_HOME     解壓路徑   C:\DevelopTool\MySQL\mysql-5.7.25-winx64    

 Path     %MYSQL_HOME%\bin

net start MySQL【或者是MySQL57】

use mysql;
GRANT ALL ON *.* TO root@'%' IDENTIFIED BY '密碼' WITH GRANT OPTION;
flush privileges;

在了解REST API URI設計的規則之前，讓我們快速瀏覽一些我們將要討論的術語。

URIs

REST API使用統一資源標識符（URI）來尋址資源。在當今互聯網上，充斥著各種各樣的URI設計規則，既有像//api.example.com/louvre/leonardo-da-vinci/mona-lisa這樣能夠清楚的傳達API資源模型的文章，也有很難理解的文章，例如：//api.example.com/68dd0-a9d3-11e0-9f1c-0800200c9a66 ；Tim Berners-Lee在他的“Axioms of Web Architecture”一文中將URI的不透明度總結成一句話：

唯一可以使用標識符的是引用對象。在不取消引用時，就不應該查看URI字符串的內容以獲取其他信息。 
——蒂姆·伯納斯 - 李

客戶端必須遵循Web的鏈接范例，將URI視為不透明標識符。

REST API設計人員應該在考慮將REST API資源模型傳達給潛在的客戶端開發者的前提下，創造URI。在這篇文章中，我將嘗試為REST API URI 引入一套設計規則。

先跳過規則，URI的通用語法也適用與本文中的URI。RFC 3986定義了通用URI語法，如下所示：

URI = scheme “://” authority “/” path [ “?” query ][ “#” fragment ]

規則1：URI結尾不應包含（/）

這是作為URI路徑中處理中最重要的規則之一，正斜杠（/）不會增加語義值，且可能導致混淆。REST API不允許一個尾部的斜杠，不應該將它們包含在提供給客戶端的鏈接的結尾處。

許多Web組件和框架將平等對待以下兩個URI： 
http://api.canvas.com/shapes/ 
http://api.canvas.com/shapes

但是，實際上URI中的每個字符都會計入資源的唯一身份的識別中。

兩個不同的URI映射到兩個不同的資源。如果URI不同，那么資源也是如此，反之亦然。因此，REST API必須生成和傳遞精確的URI，不能容忍任何的客戶端嘗試不精確的資源定位。

有些API碰到這種情況，可能設計為讓客戶端重定向到相應沒有尾斜杠的URI（也有可能會返回301 - 用來資源重定向）。

規則2：正斜杠分隔符（/）必須用來指示層級關系

URI的路徑中的正斜杠（/）字符用于指示資源之間的層次關系。

例如： 
(http://api.canvas.com/shapes/polygons/quadrilaterals/squares ；

規則3：應使用連字符（ - ）來提高URI的可讀性

為了使您的URI容易讓人們理解，請使用連字符（ - ）字符來提高長路徑中名稱的可讀性。在路徑中，應該使用連字符代空格連接兩個單詞 。

例如： 
http://api.example.com/blogs/guy-levin/posts/this-is-my-first-post

規則4：不得在URI中使用下劃線（_）

一些文本查看器為了區分強調URI，常常會在URI下加上下劃線。這樣下劃線（_）字符可能被文本查看器中默認的下劃線部分地遮蔽或完全隱藏。

為避免這種混淆，請使用連字符（ - ）而不是下劃線

規則5：URI路徑中首選小寫字母

方便時，URI路徑中首選小寫字母，因為大寫字母有時會導致一些問題。RFC 3986將URI定義為區分大小寫，但scheme 和 host components除外。

例如： 
http://api.example.com/my-folder/my-doc

HTTP://API.EXAMPLE.COM/my-folder/my-doc 
這個URI很好。URI格式規范（RFC 3986）認為該URI與URI＃1相同。

http://api.example.com/My-Folder/my-doc 
而這個URI與URI 1和2不同，這可能會導致不必要的混淆。

規則6：文件擴展名不應包含在URI中

在Web上，（.）字符通常用于分隔URI的文件名和擴展名。 
REST API不應在URI中包含人造文件擴展名，來指示郵件實體的格式。相反，他們應該依賴通過Content-Type中的header傳遞media type，來確定如何處理正文的內容。

http://api.college.com/students/3248234/courses/2005/fall.json 
http://api.college.com/students/3248234/courses/2005/fall

如上所示：不應使用文件擴展名來表示格式。

應鼓勵REST API客戶端使用HTTP提供的格式選擇機制Accept request header。

為了是鏈接和調試更簡單，REST API應該支持通過查詢參數來支持媒體類型的選擇。

規則7：端點名稱是單數還是復數？

keep-it-simple的原則在這里同樣適用。雖然一些”語法學家”會告訴你使用復數來描述資源的單個實例是錯誤的，但實際上為了保持URI格式的一致性建議使用復數形式。

本著API提供商更容易實施和API使用者更容易操作的原則，可以不必糾結一些奇怪的復數（person/people，goose/geese）。

但是應該怎么處理層級關系呢？如果一個關系只能存在于另一個資源中，RESTful原則就會提供有用的指導。我們來看一下這個例子。學生有一些課程。這些課程在邏輯上映射到學生終端，如下所示：

http://api.college.com/students/3248234/courses - 檢索id為3248234的學生學習的所有課程的清單。 
http://api.college.com/students/3248234/courses/physics -檢索該學生的物理課程

結論

當你在設計REST API服務時，您必須注意這些由URI定義的資源。

正在構建的服務中的每個資源將至少有一個URI標識它。這個URI最好是有意義的，且能充分描述資源。URI應遵循可預測的層次結構，用來提高其可理解性，可用性：可預測的意義在于它們是一致的，它的層次結構在數據關系上是有意義的。

RESTful API是為使用者編寫的。URI的名稱和結構應該能夠向使用者傳達更清晰的含義。通過遵循上述規則，您將創建一個更清晰的的REST API與更友好的客戶端。這些并不是REST的規則或約束，僅僅是API的增強和補充。

我也建議你來看看http://blog.restcase.com/5-basic-rest-api-design-guidelines/這篇文章。

最后，望大家牢記：你在為你的客戶端設計API URI，而不僅僅是為你的數據。

* this.getClass().getClassLoader().getResourceAsStream("testVariables.bpmn")

       從classpath根目錄下加載指定名稱的文件

 * this.getClass().getResourceAsStream("testVariables.bpmn")   

       從當前包下加載指定名稱的文件

 * this.getClass().getResourceAsStream("/testVariables.bpmn") 

       從classpath根目錄下加載指定名稱的文件