OpenAPI 3 ファーストな Web アプリケーション開発(Python で API 編)

2019/04/12
このエントリーをはてなブックマークに追加

ソフトウェアエンジニアの花岡です。前回触れた設計ファーストなアプローチに関して Python での API 実装について書いてみました。

機能

設計ファーストなアプローチでは、OpenAPI 3 ドキュメントをもとにした以下のような機能を実現したいと考えました。

  • リクエストの validation と unmarshaling
    • Operation Object で定義した parameters や requestBody をもとに自動でリクエストを validation
    • さらに format に応じて unmarshaling(たとえば date なら datetime.date のインスタンスに変換)
  • アクセス制御
  • ルーティングの自動生成

これらの機能はアプリケーションで実装せず、ライブラリから自動で提供されるような形が理想です。

Web フレームワークとライブラリ

Web フレームワークは Falcon です。当時、いいかんじの OpenAPI 3 ライブラリがなかったため、OpenAPI 3 実装とそれを利用した Falcon の OpenAPI 3 ライブラリとして falcon-oas を実装しました。Web フレームワーク非依存の OpenAPI 3 実装は falcon_oas.oas に分離しています。spec などのネーミングや jsonschema を利用する仕組みは弊社の開発者ブログでも何度か取り上げてきた bravado-core からいただきました。

設計では、アプリケーション全体を支配するオレオレフレームワークにするのではなく、既存の Falcon の世界で利用可能なライブラリを目指しました。リクエストのバリデーションとアクセス制御は Falcon のミドルウェアから提供されます。バリデーションのパスしたリクエスト情報とアクセス制御のパスしたユーザ情報はそれぞれ falcon.Request.context に格納されます。アプリケーションはそれを使うだけです。他の Falcon の機能も普通に使えます。

以下の例は、OpenAPI 3 と Falcon の知識があるとわかりやすいと思いますが、なくてもなんとなく雰囲気でわかった気になれると思います。

paths:
  /api/v1/pets/{pet_id}:
    get:
      responses:
        '200':
          description: A pet.
    delete:
      responses:
        '204':
          description: Successful deletion.
      security:
      - api_key: []
    parameters:
    - name: pet_id
      in: path
      required: true
      schema:
        type: integer
components:
  securitySchemes:
    api_key:
      type: apiKey
      name: X-API-Key
      in: header

この OpenAPI 3 ドキュメントの断片は /api/v1/pets/{pet_id} のパスの GET と DELETE リクエストに対して

  • pet_id は integer 型であること
  • DELETE リクエストは api_key Security Scheme Object により X-API-Key ヘッダが必要なこと

などを定義しています。Falcon の API 実装としては

class PetItem:
    def on_get(self, req, resp, pet_id):
        pet = get_pet_by_id(pet_id)
        resp.media = pet.to_dict()

    def on_delete(self, req, resp, pet_id):
        if not is_valid_api_key(req.get_header('X-API-Key')):
            raise falcon.HTTPForbidden()

        delete_pet_by_id(pet_id)
        resp.status = falcon.HTTP_NO_CONTENT


api = falcon.API()
api.add_route('/api/v1/pets/{pet_id:int}', PetItem())

のようなかんじになると思います。これが

class PetItem:
    def on_get(self, req, resp, pet_id):
        pet = get_pet_by_id(pet_id)
        resp.media = pet.to_dict()

    def on_delete(self, req, resp, pet_id):
        pet = delete_pet_by_id(int(pet_id))
        resp.status = falcon.HTTP_NO_CONTENT


with open('/path/to/openapi.json') as f:
    spec_dict = json.load(f)
api = falcon_oas.OAS(spec_dict).create_api()

のように書けるようになります。falcon_oas.OAS がエントリポイントで OpenAPI 3 ドキュメントをもとにした falcon.API インスタンスを生成することができます。その他変わったところは

  • Field Converters がなくなった
    • falcon-oas が OpenAPI 3 ドキュメントの schema をもとに pet_id を int に変換します
  • is_valid_api_key がなくなった
    • falcon-oas が Security Scheme Object と Security Requirement Object に基づいたチェックをします
  • falcon.API.add_route がなくなった
    • falcon-oas が OpenAPI 3 ドキュメントのパスと REST リソース実装を falcon.API.add_route します

以上のように OpenAPI 3 ドキュメントで定義した内容を falcon-oas が処理するため、それらの機能の実装がなくなっただけでその他は普通の Falcon の世界ということがわかると思います。OpenAPI 3 ドキュメントは

paths:
  /api/v1/pets/{pet_id}:
    x-falcon-oas-implementation: path.to.PetItem
    get:
      responses:
        '200':
          description: A pet.
    delete:
      responses:
        '204':
          description: Successful deletion.
      security:
      - api_key: []
    parameters:
    - name: pet_id
      in: path
      required: true
      schema:
        type: integer
components:
  securitySchemes:
    api_key:
      x-falcon-oas-implementation: path.to.api_key_validator
      type: apiKey
      name: X-API-Key
      in: header

のようにしてx-falcon-oas-implementation 拡張で Path Item Object に REST リソース実装を、Security Scheme Object にアクセス制御実装を関連付けます。

以下、実装について少し詳しく説明します。

falcon_oas.OAS

エントリポイントです。デフォルトで上記の機能と RFC 7807 サポートを有効にした falcon.API インスタンスを生成することができます。

falcon_oas.OAS.create_apifalcon.API のすべてのパラメータを受け取ることができます。

リクエストの validation と unmarshaling

Operation Object の parameters と requestBody をもとにリクエストをバリデーションします。

リクエストパラメータは文字列のため、Parameter Object の schema で type が定義されているとそれをもとにパースしてからバリデーションします。そのため上記の例では integer な pet_id の値が int になっています。

さらに format の定義がある場合は値の変換もすることができます。デフォルトでは date の場合は datetime.date に変換されます。format のカスタマイズは falcon_oas.OASformats パラメータで可能です。

Parameter Object の style と explode はまだサポートしていません。しかし d=2020-01-01&d=2020-01-02&d=2020-01-03 のようなクエリ文字列は Falcon が値を ['2020-01-01', '2020-01-02', '2020-01-03'] のリストにパースするため

type: array
items:
  type: string
  format: date

のような schema を定義していると [datetime.date(2020, 1, 1), datetime.date(2020, 1, 2), datetime.date(2020, 1, 3)] のリストが得られます。

path パラメータは上記の例の pet_id のように responder のパラメータの値が unmarshal 済みの値になります。

すべての unmarshal 済みのパラメータは falcon.Request.context['oas'].parameters に dict として格納されるので、req.context['oas'].parameters['path']['pet_id'] でもアクセスできます。

unmarshal 済みの request body は falcon.Request.context['oas'].media でアクセスできます。

アクセス制御

現在のところ Security Scheme Object の apiKey type のみサポートしています。上記の例の通り x-falcon-oas-implementation 拡張でアクセス制御関数を関連付けます。

アクセス制御関数は

  • Security Scheme Object に対応するリクエストパラメータの値
    • 上記の例では X-API-Key ヘッダの値
  • Security Requirement Object のスコープリスト
    • 将来的な oauth2、openIdConnect type サポートのため
    • apiKey type のときは常に空のリスト
  • falcon_oas.oas.Request のインスタンス
    • Web フレームワーク非依存な HTTP リクエストの表現

をパラメータとして受け取り、以下のいずれかの値を返す必要があります。

  • True
    • 単にアクセスを許可する場合
  • True 以外の真値
    • アクセスを許可するだけでなく、その戻り値を認証済みユーザとする場合
    • 戻り値は falcon.Request.context['oas'].user でアクセス可能
  • 偽値
    • アクセスを拒否する場合
    • falcon-oas が自動で 403 エラーを返す

たとえば

x-falcon-oas-implementation: path.to.session_cookie_loader
type: apiKey
name: session
in: cookie

のような Security Scheme Object の場合、session_cookie_loader は以下のようなかんじになります。

def session_cookie_loader(value, scopes, req):
    credentials = deserialize_session_cookie(value)
    if credentials:
        return User(**credentials)

さいごに

OpenAPI 3 ファーストな Web アプリケーション開発の設計ファーストアプローチに関して、API でどのような機能を実現したかったのか、Python でどのように実現したのか説明しました。

弊社では一緒に事業をご牽引いただけるエンジニアを募集しています。

その他の記事

Other Articles

2019/04/16
C++のenable_shared_from_thisを使う

2019/04/08
WebGLでレイマーチングを使ったCSGを実現する

2019/04/02
『エンジニア採用最前線』に感化されて2週間でエンジニア主導の求人票更新フローを構築した話

2019/03/29
その1 Jetson TX2でk3s(枯山水)を動かしてみた

2019/03/27
任意のブラウザ上でJestで書いたテストを実行する

2019/02/08
TypeScript で “radian” と “degree” を間違えないようにする

2019/02/05
Python3でGoogle Cloud ML Engineをローカルで動作する方法

2019/01/18
SIGGRAPH Asia 2018 参加レポート

2019/01/08
お正月だョ!ECMAScript Proposal全員集合!!

2019/01/08
カブクエンジニア開発合宿に行ってきました 2018秋

2018/12/25
OpenAPI 3 ファーストな Web アプリケーション開発(環境編)

2018/12/23
いまMLKitカスタムモデル(TF Lite)は使えるのか

2018/12/21
[IoT] Docker on JetsonでMQTTを使ってCloud IoT Coreと通信する

2018/12/11
TypeScriptで実現する型安全な多言語対応(Angularを例に)

2018/12/05
GASでCompute Engineの時間に応じた自動停止/起動ツールを作成する 〜GASで簡単に好きなGoogle APIを叩く方法〜

2018/12/02
single quotes な Black を vendoring して packaging

2018/11/14
3次元データに2次元データの深層学習の技術(Inception V3, ResNet)を適用

2018/11/04
Node Knockout 2018 に参戦しました

2018/10/24
SIGGRAPH 2018参加レポート-後編(VR/AR)

2018/10/11
Angular 4アプリケーションをAngular 6に移行する

2018/10/05
SIGGRAPH 2018参加レポート-特別編(VR@50)

2018/10/03
Three.jsでVRしたい

2018/10/02
SIGGRAPH 2018参加レポート-前編

2018/09/27
ズーム可能なSVGを実装する方法の解説

2018/09/25
Kerasを用いた複数入力モデル精度向上のためのTips

2018/09/21
競技プログラミングの勉強会を開催している話

2018/09/19
Ladder Netwoksによる半教師あり学習

2018/08/10
「Maker Faire Tokyo 2018」に出展しました

2018/08/02
Kerasを用いた複数時系列データを1つの深層学習モデルで学習させる方法

2018/07/26
Apollo GraphQLでWebサービスを開発してわかったこと

2018/07/19
【深層学習】時系列データに対する1次元畳み込み層の出力を可視化

2018/07/11
きたない requirements.txt から Pipenv への移行

2018/06/26
CSS Houdiniを味見する

2018/06/25
不確実性を考慮した時系列データ予測

2018/06/20
Google Colaboratory を自分のマシンで走らせる

2018/06/18
Go言語でWebAssembly

2018/06/15
カブクエンジニア開発合宿に行ってきました 2018春

2018/06/08
2018 年の tree shaking

2018/06/07
隠れマルコフモデル 入門

2018/05/30
DASKによる探索的データ分析(EDA)

2018/05/10
TensorFlowをソースからビルドする方法とその効果

2018/04/23
EGLとOpenGLを使用するコードのビルド方法〜libGLからlibOpenGLへ

2018/04/23
技術書典4にサークル参加してきました

2018/04/13
Python で Cura をバッチ実行するためには

2018/04/04
ARCoreで3Dプリント風エフェクトを実現する〜呪文による積層造形映像制作の舞台裏〜

2018/04/02
深層学習を用いた時系列データにおける異常検知

2018/04/01
音声ユーザーインターフェースを用いた新方式積層造形装置の提案

2018/03/31
Container builderでコンテナイメージをBuildしてSlackで結果を受け取る開発スタイルが捗る

2018/03/23
ngUpgrade を使って AngularJS から Angular に移行

2018/03/14
Three.jsのパフォーマンスTips

2018/02/14
C++17の新機能を試す〜その1「3次元版hypot」

2018/01/17
時系列データにおける異常検知

2018/01/11
異常検知の基礎

2018/01/09
three.ar.jsを使ったスマホAR入門

2017/12/17
Python OpenAPIライブラリ bravado-core の発展的な使い方

2017/12/15
WebAssembly(wat)を手書きする

2017/12/14
AngularJS を Angular に移行: ng-annotate 相当の機能を TypeScrpt ファイルに適用

2017/12/08
Android Thingsで4足ロボットを作る ~ Android ThingsとPCA9685でサーボ制御)

2017/12/06
Raspberry PIとDialogflow & Google Cloud Platformを利用した、3Dプリンターボット(仮)の開発 (概要編)

2017/11/20
カブクエンジニア開発合宿に行ってきました 2017秋

2017/10/19
Android Thingsを使って3Dプリント戦車を作ろう ① ハードウェア準備編

2017/10/13
第2回 魁!! GPUクラスタ on GKE ~PodからGPUを使う編~

2017/10/05
第1回 魁!! GPUクラスタ on GKE ~GPUクラスタ構築編~

2017/09/13
「Maker Faire Tokyo 2017」に出展しました。

2017/09/11
PyConJP2017に参加しました

2017/09/08
bravado-coreによるOpenAPIを利用したPythonアプリケーション開発

2017/08/23
OpenAPIのご紹介

2017/08/18
EuroPython2017で2名登壇しました。

2017/07/26
3DプリンターでLチカ

2017/07/03
Three.js r86で何が変わったのか

2017/06/21
3次元データへの深層学習の適用

2017/06/01
カブクエンジニア開発合宿に行ってきました 2017春

2017/05/08
Three.js r85で何が変わったのか

2017/04/10
GCPのGPUインスタンスでレンダリングを高速化

2017/02/07
Three.js r84で何が変わったのか

2017/01/27
Google App EngineのFlexible EnvironmentにTmpfsを導入する

2016/12/21
Three.js r83で何が変わったのか

2016/12/02
Three.jsでのクリッピング平面の利用

2016/11/08
Three.js r82で何が変わったのか

2016/12/17
SIGGRAPH 2016 レポート

2016/11/02
カブクエンジニア開発合宿に行ってきました 2016秋

2016/10/28
PyConJP2016 行きました

2016/10/17
EuroPython2016で登壇しました

2016/10/13
Angular 2.0.0ファイナルへのアップグレード

2016/10/04
Three.js r81で何が変わったのか

2016/09/14
カブクのエンジニアインターンシッププログラムについての詩

2016/09/05
カブクのエンジニアインターンとして3ヶ月でやった事 〜高橋知成の場合〜

2016/08/30
Three.js r80で何が変わったのか

2016/07/15
Three.js r79で何が変わったのか

2016/06/02
Vulkanを試してみた

2016/05/20
MakerGoの作り方

2016/05/08
TensorFlow on DockerでGPUを使えるようにする方法

2016/04/27
Blenderの3DデータをMinecraftに送りこむ

2016/04/20
Tensorflowを使ったDeep LearningにおけるGPU性能調査

→
←

関連職種

Recruit

バックエンドエンジニア(Python・Go)

業務内容

当ポジションは弊社Webサービスのバックエンド機能設計及び実装を担当します。 サービス毎の開発チームで2週間スプリントのスクラム開発を実施しています。 週次で開発チームミーティングを実施し、実装設計の相談や工数見積もりを行います。 全ての開発コードはレビューと自動テストによって品質を保っています。 また、リファクタリングやフレームワークのバージョンアップも開発フローに組込み、技術的負債を放置しない開発を目指しています。

フロントエンドエンジニア(TypeScript)

業務内容

当ポジションは弊社Webサービスのフロントエンド機能設計及び実装を担当します。 サービス毎の開発チームで2週間スプリントのスクラム開発を実施しています。 週次で開発チームミーティングを実施し、実装設計の相談や工数見積もりを行います。 全ての開発コードはレビューと自動テストによって品質を保っています。 また、リファクタリングやフレームワークのバージョンアップも開発フローに組込み、技術的負債を放置しない開発を目指しています。

機械学習エンジニア

業務内容

センサーデータの分析モデルの調査・研究・開発。 Kabuku Connectの製造データ(3D、2D)から情報を抽出するモデルの構築。 データの前処理や学習、ハイパーパラメータチューニング、獲得モデルの評価、プロダクションのデータパイプラインとの連携をお願いします。

インターン(Webエンジニア)

業務内容

業務から独立した、調査・研究系のタスクをおまかせしています。コードレビュー、 社内での報告会、 ブログ記事執筆を通して着実にスキルアップしていただくことを目指しています。 (希望があれば、プロダクトの開発業務もおまかせします。)

→
←

お客様のご要望に「Kabuku」はお応えいたします。
ぜひお気軽にご相談ください。

お電話でも受け付けております
03-6380-2750
営業時間:09:30~18:00
※土日祝は除く