跳到主要內容

[筆記] Google API

每次都要登入 playground 找 API 實在有點小麻煩，且一陣子不用就會忘記規則 ( 太菜惹
乾脆就認真把幾個重要的記錄下來吧！

BTW google fitness的是走OAuth2認證~

撈資料：
 https://www.googleapis.com/fitness/v1/users/me/dataSources/這裡是預查找資料的id


API manual 上的，要幹嘛我忘惹(待確認)
https://www.googleapis.com/fitness/v1/resourcePath?parameters

下指令語法：

curl -H 'Authorization : [ User 身分 (ex:Bearer) ] [Token ] [放撈資料的URl囉~]


最後小抱怨一下，google+的fitness豪難用RRR  超級不適合菜鳥的QAQ
標籤：

留言

張貼留言

這個網誌中的熱門文章

南京初行

南京交換一個多月了，從一開始過得很痛苦每天都想直接飛回台灣，到現在慢慢融入這裡生活，感謝主讓我始終是幸運的。 很幸運從決定交後，親戚給我各式資訊，父母給我足夠支持與鼓勵，陪我來南京辦東辦西熟悉環境兼旅遊，讓我不至於手忙腳亂，也讓我有獨自一人生活的勇氣，同時還幫我這個有點雷的女兒張羅個識時務伴手禮。 很幸運在元智友一群很carry的白癡損友，為我辦wechat想辦法幫我翻牆幫我跑單位聯絡老師退課選課想作業，然後塵埃落定後依舊時不時和我聊天打屁，在冷颼颼的南京跨海給我一點溫暖 很幸運一開始遇到一個帥哥學伴，幫我讓在這裡的日常生活步入正軌，雖然現在幾乎沒有聯絡讓我小感傷，但重要的是曾經擁有 很幸運有一群很親切的室友學姊，常常分我零食餅乾水果雞蛋，還叮嚀我要去哪玩哪邊很雷不要去玩 很幸運遇到一群友善的同學，很快地接納來自台灣的我，邀請我去春遊上課借我筆記戴我體驗校園競賽 很幸運遇到一群個性算合拍的交換小夥伴，在南京大小事上彼此互相照顧，連出去玩彼此也是不離不棄 回想起來原來有這麼多的幸運，相較之下初來到時的無助顯得那麼微不足道 然後是本文重點，講講同時炫耀一下出去玩的心得，依時間序大概去了 西湖→南京總統府→夫子廟→雞鳴寺、玄武湖→紫金山 →雨花台、老門東→明孝陵→閱江樓→朝天宮 →鎮江 金山、西津都→莫愁湖公園 大部分都是一些極具歷史文化遺產的地方，真的很典雅而且古色古香，漂亮的景色讓怎麼拍都好看，甚至有一度被鎮江美哭，當國文與歷史課本所讀到的詩詞古賦圖突然變成眼前的風景，很感動。以後看電視應該對於一些講述古裝或是穿越的故事劇情會略有心得。 在這裡有趣的是看看不同城市開發狀況。城市硬體設施建設，到對整個市容的設計規劃，都可以明顯看出這個城市是屬於正常發展或是經由政府推動發的階段性發展輪廓 同時這裡保留很多傳統文化，受西方影響程度的確比較不明顯，很有趣的一點，是這裡的人都有非常明顯的特徵可以略窺一二他們所屬的年代，每個年代之間彼此都有明顯的價值觀與審美觀落差。我想大概是因為改革開放影響，這裡的民間發展有一點跨時代的現象。在這邊極不相似的風格特色與時代文化卻可以融合在一起，看起來很突兀，卻又不突兀。 以上是我來南京以後小小心得，希望待越久可以有更多的發現與體悟，大家不要擔心，我過馬路還是會看紅綠燈，搭捷運位記得排隊，遵守先下後上原則的！
張貼留言
閱讀完整內容

[筆記] 串接 知識決策模型 / 知識推論引擎 / 工作流程模型 / 工作分派引擎 ，一起手牽手心連心！ Case實例

生字： Ontology 知識本體論：   定義特定的應用領域中，知識術語的集合。什麼種類的事情可以存在， 以及它們之間的交互關係，以達到知識共享目的。 如：包含語彙（Vocabulary），語意上的相互連結（Semantic Interconnection）， 以及在推論（Inference）和邏輯（Logic）上的簡單規則（Hendler , 2001）。 OWL：The Web Ontology Language SWRL ：Semantic Web Rule Language ，以語 義 的方式呈現規則的 一種語言 ，細節待研究 Protégé： 本體編輯和 知識取得 軟體，一種工具而已，不用想太多。 Jess Rule Engine：Java寫的一種工具，也不用想太多  ------------------------------------------------------- 知識決策人工智慧的領域演化過程： > 從20年前的數學模型、機率統計 >  語意描述建模 > 語意法則 > 推論引擎去分析推斷，產生真實的邏輯判斷結果 過去Ontology定義領域知識架構與其樹狀圖，在進步一點的利用RDF標準化結構。 今日利用OWL定義Ontology結構與親屬關係，建立實例 ( Instance ) 轉化為 Rule， Rule再利用推論引擎產生推論結果。 知識決策模型(Hypothesis) + 知識推論引擎(Procedure) + 工作流程模型(Model) + 工作分派引擎(Procedure) + 系統開發 (Implementation)  結合實例 //Ontology架構  知識決策架構 瞭解 領域環境 分析 & 歸納 領域問題 定義   領域知識 & 知識關聯架構  透過   OWL-DL語言 建立 Ontology 模型  透過   Protégé工具 ， 管理 Ontology (亦可用於建立)  定義   屬性(Property)  建立 ...
張貼留言
閱讀完整內容

[筆記]Fitbit API - HR Time Series

由於之前使用 FITBIT api 不同 type 要資料時，回傳 json 檔案格式不盡相同，也並非所有 api 所提供的 URL 都能取得資料，因此決定專門整理一篇，將 app type 設為 client 與 personal 進行回傳資料格式實測並記錄結果 當 app type 為 client 時： 一般的 Time Series ： Resource URL ： 當 URL 為 https://api.fitbit.com/1/user/[user-id]/activities/heart/date/[date]/[period].json 回傳資料：取得僅 daily 總結資料，包含 restingHeartRate( 型態同 API) period ： 1d 、 7d 、 30d 、 1w 、 1m ，回傳資料是 period 前所設定的 [ date ] 往回推 [ period ] time ， 30d 與 1m 差別於，取 [ date ] 往前推算的整整 30 天，或是 [ date ]  往前推的一個月 當 URL 為  https://api.fitbit.com/1/user/[user-id]/activities/heart/date/[base-date]/[end-date].json 日期可以跨月份任意指定 Intraday Time Series Resource URL ： 當 URL 為 1.      GET https://api.fitbit.com/1/user/-/activities/heart/date/[date]/[end-date]/[detail-level].json 2.      GET https://api.fitbit.com/1/user/-/activities/heart/date/[date]/[end-date]/[detail-level]/time/[start-time]/[end-time].json 3.      GET https:/...
張貼留言
閱讀完整內容