Firebaseをcurlでもう少しだけ試す

つらつらと考えていたが、こっち側（センサ側）はデータをアップするだけだろう。
だから、クエリーの方法はサーバのことをやる気分になったときでいいや。

なので、もう少しだけデータのアップ方法を見ておこう。
私にとってサーバを立てるというのは、それはもう大ごとなので、簡単にやってもらえるのであればもうちょっと使ってみたいのだ。

---

Saving Data - Firebase

• PUT
• データの置き換え
• PATCH
• データの一部更新
• POST
• リストやデータの追加
• クライアントは「messages/users/<unique-id>/<data>」のようなユニークIDを生成する
• DELETE
• 消す

 

PUTは、前回試したやつだ。
PATCHは、updateとあるから、一部だけ変えるのだろう。
DELETEも試したので、消すだけだとわかる。
問題はPOSTだ。

リストを保存する例だけ見ると、PUTがPOSTになっただけだ。
しかし、戻ってくるデータにユニークIDが含まれている。

---

やってみよう。

$ curl -X POST -d '{"test1":{"name":"hiro","date":"06/03"}}' 'https://xxxx.firebaseio.com/rest/saving-data/test.json'
{"name":"-KJLSkVZbAkcX4hMjxEd"}

うん。
PUTしたときはtestの下にtest1があったけど、これはユニークIDが挟まっているな。
push IDと書いてあるけど、どう使えばよいのだ？
素直に考えると、階層が深くなるだけなのだが。。。

$ curl -X POST -d '{"test2":
{"name":"yoko","date":"11/22"}}' 'https://xxxx.firebaseio.com/rest/saving-data/-KJLSkVZbAkcX4hMjxEd/test.json'
{"name":"-KJLUx5Rr_yCiIadZVLi"}

ああ・・・そうなるのか・・・。
そうなるよな。

では、何も考えずに同じPOSTを2回やってみよう。

$ curl -X POST -d '{"test1":{"name":"hiro","date":"06/03"}}' 'https://xxxx.firebaseio.com/rest/saving-data/test.json'
{"name":"-KJLVqUQNYqMzWKrwGp_"}
$ curl -X POST -d '{"test1":{"name":"hiro","date":"06/03"}}' 'https://xxxx.firebaseio.com/rest/saving-data/test.json'
{"name":"-KJLVyLX0T7_y-8dMvBM"}

まあ、ユニークIDは毎回発行されるから、こうなるわな。

---

このIDは、時間情報があるわけでも無いと思うので、サーバ上には別々の場所に保存されてありがたいのだが、到着した順番はわからんだろう。

となると、どういう風に使う目的なのだ？
JavaScriptでは、これをpush()というAPIでやるらしいから、何かPUSH系のメッセージという扱いのように見えるのだが。

 

今頃知ったのだが、このFirebaseって今年のGoogle I/Oで発表されたばかりなんだな。
新しいドキュメントはGoogleで、前のドキュメントは買収前ということか。
Google I/O 2016 で「Firebase」の新バージョンが発表！プッシュ通知機能を iOS アプリで使ってみた ｜ Developers.IO
ということで、プッシュ通知というのも売りとなる機能らしい。

iOSのNotificationとか出てくるから、これはスマホにとってのプッシュ通知用ということか。
そこは、もう少しスマホ側のアプリに慣れてからにしよう。

---

".sv"というキーを使うと、サーバ側の値が使えるらしい。
今はtimestampだけのようだが、これはありがたい！

 

$ curl -X POST -d '{"test1":{"name":"hiro","date":"06/03",".sv":"timestamp"}}' 'https://xxxx.firebaseio.com/rest/saving-data/test.json'
{"name":"-KJLZhC49FhjrRANKHdq"}

 

えー、他の項目と一緒にやってくれないのかい。。。
これならどうだ？

 

$ curl -X POST -d '{"test1":{"now":{".sv":"timestamp"},"name":"hiro","date":"06/03"}}' 'https://xxxx.firebaseio.c
om/rest/saving-data/test.json'
{"name":"-KJL_u_efy7lsP-O_Hxy"}~$

やれやれだぜ。

センサー側がどういう時間で思っていようと、サーバ側が受け取った時間で管理すればよい場合が多いから、これでよいだろう。
そうすると、RTCとかなくてもいいしね。
まあ、これを使うとなるとHTTPアクセスするくらいだから、NTPとかやってしまえばいいのだけど、時間みたいな繊細な情報は扱いたくないのだよ。

 

ともかく、こういう時間情報が値に含まれることで、ユニークIDがどうであっても時系列は把握できるだろう。
あとは、自分が誰か、というセンサーIDみたいな値があれば、クエリーで引っ張ってきやすいんじゃなかろうか。