APIの仕様を定めて実装する

[Hiroshiba]

内容

APIの仕様がまちまちなのでちょっと整理します。

• APIバージョン取得
  • GET /
  • ステータスコード 204
  • bodyはなし
• 単語登録・更新
  • POST /upsert_word
  • 単語が既存だったら上書き、そうじゃなかったら新規登録
  • 成功時
    • ステータスコード 204
    • bodyはなし
  • 失敗時
    • 引数がおかしい場合
      • ステータスコード 400
      • エラーメッセージを平文として返す
    • その他　←　未実装
      • ステータスコード 500
      • エラーメッセージを平文として返す
• 単語消去
  • POST /delete_word
  • その単語が存在していなくても成功する
  • 成功時
    • ステータスコード 204
    • bodyはなし
  • 失敗時
    • 引数がおかしい場合
      • ステータスコード 400
      • エラーメッセージを平文として返す
    • その他
      • ステータスコード 500
      • エラーメッセージを平文として返す

[Hiroshiba]

@sevenc-nanashi API設計としてこんな感じでどうでしょう。
タスクとしてはこんな感じかなと

• rewrite_wordをapply_wordに統合してupsertにする
• 成功時のステータスを204にする
• 引数がおかしい場合にステータス400を返し、エラーメッセージをテキストとして返す
• それ以外でおかしい場合はステータス500を返す

rewrite_wordの統合に関しては議論いるかもです。←upsertにするで合意
word_uuidが既存かどうかを得るAPIを用意しないつもりなので、POSTする側はrewriteかどうか判断することができないので、もうまとめちゃって良いかなと。

[sevenc-nanashi]

確かに。upsertみたいな処理で大丈夫そうに感じました。

[sevenc-nanashi]

また、送信が成功したかどうかはエンジンに通知する必要は無く、内部ログで取っておけば良いので、204 No Contentでもよさそうだと思いました。

[Hiroshiba]

確かに。upsertみたいな処理で大丈夫そうに感じました。

名前もupsert_wordが良さそうですね！
リストをそう更新してみます。

204 No Content

たしかに。レスポンスbodyもいらなそうですね、リストを更新します。
エラーの方はレスポンスbodyどうしましょう。一応エラーメッセージあったほうがデバッグで便利かも。

[sevenc-nanashi]

エラーメッセージはお任せします。（API設計の経験が無いので）
スプレッドシートの２枚目あたりにとっておいても良さそう？

[Hiroshiba]

あとはステータスコードを整理したら完成な気がしますね！！！