初めに

仕事でSwagger-Editorを使うことになった。
んだが日本語のドキュメントが見当たらないので使い方兼覚書を作成。
使い始めて1週間もたってないので気づいたことがあったら順次更新していく所存。

※後で清書する（とおもう）

英語でいいぞい、という人は↓とかで
https://github.com/swagger-api/swagger-editor

環境構築

↓をクリックすればswagger-editorが開く。楽。
http://editor.swagger.io/#/

Web上に会社のアレコレを書くのはちょっと…という人はDocker使うのが一番楽。
常に最新のバージョンが使えるのでいい感じ。
やることはDockerをターミナルで起動させた後、以下のコマンドをたたくだけ。
docker pull swaggerapi/swagger-editor docker run -p 80:8080 swaggerapi/swagger-editor

叩いた後、http://DockerのIP/#/ にアクセスすればswagger-editorが開く

因みに自動保存されるので、誤ってブラウザを閉じてしまっても再度開けば続きから編集できる。

基本的な使い方

右にプレビュー、左にエディター。
左上に各種メニューがあるのでそれらを簡単に説明。

File

New -> 新規のYAMLファイルを作成
Open Example -> サンプルが開ける。ミニマムセットからTwitterのAPIまでそろってる。ざっと眺めるだけでも使い方がわかる
Paste JSON -> JSONファイルを張り付けるとYamlに書き出してくれる…のかな。使ったことない。
Import File -> YAMLファイルを取り込む
Download YAML -> YAMLファイルを出力
Download JSON -> JSONファイルを出力

Preference

Font Size -> そのまんま
Editor Setting -> エディタの細かい設定ができる。Keybord Handlerからキーバインドを変えれるのが地味にうれしい(Emac,vim,sublimeの御三家も勢ぞろい)。
Reset Editor Settings -> そのまんま
Preferences... -> プレビューへの反映やらを設定。地味に重要
Keypress debounce -> 何ミリ秒入力がなかったら変更がなくなったとみるか。↓のLive Renderingの反映までの時間だと思えばOK
Live Rendering -> エディタでの修正をプレビューに自動反映するかどうか。チェック有で反映する。ファイルサイズが大きくなると処理が重くなるのでオフにするのも視野に。OFFにした場合は、プレビュー画面の最上部にリロードのリンクがでてくるようになる
Auto-complete -> 自動保管機能。チェック有で保管する。のだがきかなくなるときもしばしば。F5更新で直る
Pointer Resolution Base Path -> JSONの値を$refで参照した時のURL？よくわかってません。。。

Generate Server / Generate Client

選択したフォーマットでソースを吐き出してくれる。ほぼすべてカバーされて気がする。この機能により、ドキュメントから直接ソースを作れる

Help

ヘルプ。

書き方のアレコレ

ここからがメイン。細かい仕様は↓のURLから。英語だけどフィーリングで大体はわかる。
http://swagger.io/specification/

1階層目のスキーマのアレコレ

英語のドキュメントはこの場所

swagger -> 使うバージョン。よほどのことがない限り2.0でデフォルトのまま。必須項目
info -> ドキュメントのバージョンやタイトルなどを記載できる。必須項目
host -> APIがやり取りするホスト名を記載できる。記載することでクライアント版のソースを吐き出したり、プレビュー画面から通信する際のホストとして機能する。無記載でswagger-editorが動いているホスト名が入る
path -> swaggerのメイン要素。この下にURLパスの記載をしていく
definitions -> swaggerのメイン要素。この下にレスポンスのパラメータを記載していく
basePath -> ホストから連なる共通のパス。hostを「hogehoge.com」basePathを「moge/mage/」としたら、URLの始まは「http://hogehoge.com/moge/mage/～」となる
schemes -> スキーム指定。http,https,ws,wssから選ぶ。
produces / consumes -> MimeTypeの指定。選択肢はここを参照
tags -> タグの説明を書ける。
securityDefinitions -> セキュリティ周りの設定を書くならここ。よくわかってない。
security -> セキュリティ周りの設定。よくわかってない
parameters -> パラメータ周りの記載をまとめられる。pathを書く中で個別に定義することもできるが、構造化の観点を考えるならこちらに集約したほうがよさそう

Pathの記載のアレコレ

英語のドキュメントはこの場所
ほとんどはサンプル見たほうが早いので細かい文法などは割愛。自分が書いてるときに気になったことなどを載せていきます

タグはつけたほうが良い。ただし複数はつけないほうが良い
tagsを使うことでプレビュー側でフィルタリングできるので機能毎にタグ名を決めてつけるとよい。さらにソースを吐き出したとき、タグ名でAPIがまとまるようになる。が、複数つけると両方のクラスに含まれるようになってしまう。

例えばタグとして「Users」と「need-login」とつけた場合、Javaで吐き出すとそのPathにアクセスするAPIは「UsersAPI.java」と「NeedLoginAPI.java」の2つに全く同じものができてしまう

enum型をparametersに指定できるが、その場合、「in」のフィールドを「body」にしないといけない...？さらにbodyを指定すると複数のデータが持てなくなる？しかし一方でresponse側で指定する分には問題ない。
「name」と「in」のフィールドは必須項目。

responsesの記載のアレコレ

共通のレスポンスを記載する
用途としてはエラー系のレスポンスをここに書いておけば、pathの中で$refで参照できる
すべてのresponseをここに記載して、ここからdefinitionsを参照するようにしてやると構造化できて良さそう

parametersの記載のアレコレ

共通のパラメータを記載する。
pathで使うparametersの値はここのものを参照するようにすれば整理できて良さそう

enum型っぽく使う場合は一工夫必要(↓の例で、apple,orange,melon個別に含める/含めないが選べる)

selling_flute:
　name: flute
　in: query
　type: array
　collectionFormat: multi
　uniqueItems: true
　items:
　　type: string
　　enum:
　　　- apple
　　　- orange
　　　- melon

こっちの例だとandroid/iphoneどちらかを選択する

　device_type:
　　name: type
　　in: formData
　　description: 端末のタイプ(android / iphone)
　　required: true
　　type: string
　　enum:
　　　- android
　　　- iphone

definitionsの記載のアレコレ

ほとんどはサンプル見たほうが早いので細かい文法などは割愛。自分が書いてるときに気になったことなどを載せていきます

データタイプはここを参考にtypeとformatの組み合わせを決める。