【検討】ユーザ管理の仕様

matsu0228 commented 8 years ago

ユーザ管理の仕様

ちゃんとjsonフォーマットで入出力書いた方が良いと思うけど、概要はこんな感じかな？

入室時(自分)： -- クライアント -> サーバに、ユーザ情報登録のリクエストを送信(POST) --- リクエスト：roomid(部屋ごとに固有), windowid(ユーザごと固有), nickname, gender --- レスポンス：success / error(errorcode) #サーバ側の処理結果 -- サーバ側で、情報を保存する(insert)。すでに４人以上いるルームであればerrorを返却する？
入室時(他人)： -- クライアント -> サーバに、ユーザ属性取得のリクエストを送信(POST) --- リクエスト：roomid(部屋ごとに固有), windowid(ユーザごと固有) --- レスポンス：nickname, gender -- サーバ側で、画面表示ようのユーザ情報を返却する(select)
退出時(自分)： -- クライアント -> サーバに、退出処理のリクエストを送信(DELETE) --- リクエスト：roomid(部屋ごとに固有), windowid(ユーザごと固有) --- レスポンス：success / error(errorcode) #サーバ側の処理結果 -- サーバ側で、当該ユーザの情報を削除する(delete)
退出時(他人)： -- クライアント<->サーバ間の通信なし

xkumiyu commented 8 years ago

サーバサイドからDBの操作は簡単だからクライアントサイドで必要な情報を教えてくれたらそれを返すことはできる。 windowidってのはだれが発行するの？useridと違うの？

ykubot commented 8 years ago

windowidはskyway側が自動でふるIDのことでしょ。各ユーザのチャット名の取得のリクエストどのタイミングでする？ windowidとチャット名の紐づけをサーバ側でやる必要がある。レスポンスの結果でクライアント側は画面描画するからそこも決めないとな。

matsu0228 commented 8 years ago

@kumi ◆windowidは、くぼっちのいうとおり、skywayが発行する部屋ごとにユーザを一意に特定する文字列だよ。具体的には、 APIリファレンス（https://github.com/nttcom/SkyWay-MultiParty）の.on('open', function(myid){ ... });　したときに取得できる「id : 現在のウィンドウのid」

ドライブ/meetalk/設計/　の下にAPI仕様を保存したよーこちらをサーバチームで作成して欲しいです。おかしいところあったら指摘して＾＾ https://docs.google.com/spreadsheets/d/1ahiKQscxp8l1k31b3hOL12Txtjzk2EvSKJJ5HsHShLc/edit?usp=sharing

◆利用イメージは、下記のとおり。・入室時(自分) = .on('my_ms', function(video) {}関数内ユーザ情報登録API ・入室時(他人) = .on('peer_ms', function(video) {関数内ユーザ情報一覧API ・退出時(自分)　= exit_video_chat{}関数内ユーザ退出API ・退出時(他人)　= on('ms_close', function(peer_id) { では、APIのcall不要（クライアント側で、ニックネームなどのhtmlノードを削除する必要あるかも？）

◆ニックネーム表示(htmlとして追加)は、 Feature-client-surveyブランチ　で、実装済みだから、問題なし meetalk/app/assets/javascripts/video_chat_start.js

xkumiyu commented 8 years ago

windowsidについて了解。API仕様もだいたい理解した。今のモデルにないのは、windowsidだけだと思う。 statusとerror_codeはどう区別するの？どっちかだけでよくない？ update_dateとcreate_dateも渡せるけど、使わないならいらなくない？

ちなみに現在のモデルはdb/schema.rbにあるけど、wikiにも転記した。 https://github.com/iot-social-network-link/meetalk/wiki

matsu0228 commented 8 years ago

statusは、成功か失敗だけを返却 error_codeは、エラーの詳細を確認するためにあったほうが良いと思うよー

sql失敗なのか、ロジック的にng(部屋に5人目が入ったとか)なのか、、、そんな大変じゃないと思うから最初に作るのが楽かと。

create_dateは、画面表示するときに、位置の指定(左上なのか右下なのか)に使うかも。あとから追加してもらうより先に入れたほうが良いと思う。(手間じゃないので汎用性もたさたいなと)

hirokoji commented 8 years ago

すまん。これみずにAPI作ってしまった。 error_codeってエラーハンドリングのコードを追加するってことだよね？ Restful APIで毎回、成功失敗いれるのあんまみたことないきがする。

普通に出力されたら成功で、何かおかしい挙動したらエラーコードかえすのでどうかなー？これはstep2かな？

matsu0228 commented 8 years ago

普通に出力されたら成功で、何かおかしい挙動したらエラーコードかえす

その方が早ければ、それでおーけーです^ ^ ただ、ステータスの項目あると、クライアントでハンドリングしやすいなと^ ^

hirokoji commented 8 years ago

はーい♪ もう少し、他の人がどうやってるか調べてみますー♪

xkumiyu commented 8 years ago

step1とかstep2とかってなに？エラー処理は他もまだ全然やってないね。

hirokoji commented 8 years ago

独自用語ですまんねw 今回の仕様にはいれなくていいんじゃないーってことをいいたかったー。

xkumiyu commented 8 years ago

なるほど。了解。リリースするときまでは必要だけど、エラー処理は優先度落としてもいいかもね。

ykubot commented 8 years ago

API仕様いいね！わかりやすい。

あと足りないのはマッチング機能のAPIやね。

ykubot commented 8 years ago

マッチング機能考えた時に、ユーザ退出APIでroomからユーザ情報削除されたらまずくない？タイミングの問題だと思うけど、リクエストの順序考えたいね。

matsu0228 commented 8 years ago

そもそも、合コン開始してから10分経つ前に、ユーザー退出したらどうすべきかってことよね。

退出したメンバーは、そもそもチャットできる状態かも不明だから、いるメンバーだけでマッチングさせるってのが良いのかな？

→退出の仕様としては、物理削除でおーけーなきがする →もしくは、レコード残しておいて、削除フラグ=有効にしておく？

ykubot commented 8 years ago

そうか、勘違いしてた。ユーザ退出APIは途中退出したユーザをリストから削除するリクエストね。だったら強制修旅時にユーザ情報一覧APIでリスエストしたら、最後までいたユーザ同士でマッチング画面作れそうやね。

xkumiyu commented 8 years ago

https://github.com/iot-social-network-link/meetalk/wiki/API設計にAPI設計書いてもらったので、こちらクローズします。

再度、議論が必要であれば新規で起票ください。

iot-social-network-link / meetalk

【検討】ユーザ管理の仕様 #14

ユーザ管理の仕様