読者です 読者をやめる 読者になる 読者になる

Appresso Engineer Blog

アプレッソのエンジニアが書く技術ブログです。

APIStudy#4 開催報告

皆さんこんにちは。 技術部 對馬です。

APIのベストプラクティスを考える会「APIStudy」の第4回が開催されました。

今回もとても濃い内容となりましたのでご報告します。

前回の第3回開催報告はこちら。

appresso.hatenablog.com

去る1月24日に開催された第4回は、株式会社フロムスクラッチさんのオフィスにお邪魔しました。 f:id:ytsushima:20170203172810j:plain

また今回も市川さんにグラフィックレコーディングをしていただきました。

どんな仕上がりになるのか!楽しみです。(すっかりファンになりました私です) f:id:ytsushima:20170203172740j:plain

第1部

フロムスクラッチさんLT

まずはフロムスクラッチの井戸端さんからAPI連携開発における共通化についてお話がありました。 f:id:ytsushima:20170203172837j:plain

マーケティングプラットフォームであるB→Dashでは、データ取得のため様々なサービスとAPIで連携をしています。

しかし連携するサービスごとにAPIの仕様が異なり、ひとつひとつ開発をしていたが辛いので、昨年、共通化できる部分はマスタを作成し、サービス固有のところだけを開発できるように取り組んだそうです。

f:id:ytsushima:20170203173147j:plain

共通化することで、「新しい連携においてもマスタの追加だけで良くなった」「開発しやすくなった」「外部にも頼みやすくなった」とたくさんの嬉しいことがあったとおっしゃっていました。

有志LT

今回は初めて会場企業さん以外の方にもLTをしていただきました!

株式会社KUFU 芹澤さんから「RESTfulなAPIにおけるファイルアップロード」についてです。

f:id:ytsushima:20170203173259j:plain

SmartHRという労務管理ソフトウェアの開発をされていて、前職含めてWeb API関連のお仕事ばかりで、API漬けの人生を送られている芹澤さん。

そんな中で、ファイルの入力についてのベストプラクティス模索し、今回はその調査結果をご紹介していただきました。

インプットの方法について。

インプットは以下2つが主流パターン

  • multipart/formdata

  スタンダードな規格なので便利!

  • Base64

  ファイルのデータをエンコードして文字列型として扱う。

データの保存方式について。

  • リソース紐付けパターン

  特定アトリビュートに対してファイルデータを直接送る方法。

  • 汎用ファイルアップロードパターン

  ファイルアップロードのエンドポイントを作ってファイルを送る方法。

f:id:ytsushima:20170203173427j:plain

それぞれ2つの方法を、APIの性質やファイルの用途で適切に組み合わせることがベストプラクティス!だそうです!!

質問タイム

LT発表者に対して質問をする時間。

質問というより全体のディスカッションタイムみたいになっています。

f:id:ytsushima:20170203173517j:plain 活発に意見が飛び交っていて、チーム分けの前のこの時点でもう楽しそうです。

第2部

チームに分かれて好きなテーマをもとに話し合います。

今回のテーマは以下3つです。

  • APIの有効無効の通知、取り扱い
  • パラレルで叩くAPIの設計思想
  • エラーコード(発生原因による切り分け)

ディスカッション・発表

f:id:ytsushima:20170203173811j:plain

皆さん熱く討論をしています。

少人数でのディスカッションなので、じっくり話すことができます。

f:id:ytsushima:20170203173629j:plain

APIの有効無効の通知、取り扱い

f:id:ytsushima:20170203173843j:plain 企業にとって通知は面倒なので、だったら作ればいいじゃない!ということで kintoneのWebhookを利用して通知する機能を新たに開発すればいいという提案をされていました。

ディスカッションで新機能を提案しているのは新しいですね…。

ちなみに5月リリースだとか…?技術者はAPI Study参加者だとか…? 楽しみですね。

パラレルで叩くAPIの設計思想

f:id:ytsushima:20170203173919j:plain

APIによっていろんなものをとってこようとしたときに、何か処理が発生してしまいます。

そして複数APIを誰がハンドリングするのかという問題がありますが、 これは、クライアント側でだときれいではないのでサーバー側で一枚ファサードみたいなもの、APIの前にAPIを作ってそこで全て処理していくと綺麗にいくのではないか、という結果になりました。

しかし、となると「サーバーサイドでなんでもかんでもやることになる問題」も気にしなければならないど、バランスの良い設計について話し合うにはもう少し時間が必要のようです。

ただ、ファサード入れることでアプリからアプリを解析されたときにエンドポイントがバレて攻撃を受けるリスクを少し低減されるようになると良いと、メリットもあることをお話いただきました。

エラーコード(発生原因による切り分け)

f:id:ytsushima:20170203174240j:plain エラーコードだけでもなく200番台の話も。

AWS S3で分割アップロードするときは、とりあえず200を返すらしいです。

AWSがそうなら長いものには巻かれましょう!

また、複数返したいのなら207でカプセル化してボディで詳細とかもありではないかという意見も。

そして、ステータスコードにはいろいろなものがあるらしく…、

418  I’m a teapot (ティーポットです)

451  Unavailable For Legal Reasons 法的理由により利用不可能

402  Payment Required お金払ってないからあなたは使えない!

「402はすごい使ってみたかったから使いました!」by松本さん

今後のステータスコード発掘に期待です。

最後に

まずは今回のグラフィックレコーディング!

f:id:ytsushima:20170203174419j:plain やはり素敵ですね。

1部と2部、今回はかなり濃厚な内容でしたが、見事まとまっています。

ここは私の感想ですが、 APIStudyは回を重ねるごとに内容の濃さが比例して増しているような気がしています。

それが私はとてもうれしいです。開催報告は大変ですが。

そして!

APIStudy #5 の申込みがすでに始まっています!

そしてもうたくさんの方にお申込みを頂いておりますありがとうございます!!!

じっくりAPIについて語りたい方は、ぜひお越しください。

以下connpassページからどうぞ。

apistudy.connpass.com

API愛が濃ければ濃いほど喜ばれる、そんな勉強会です。

皆さん、宜しくお願いします。