API/設計 のバックアップ(No.3)

[ トップ ]   [ 新規 | 一覧 | 単語検索 | 最終更新 | ヘルプ | ログイン ]

• バックアップ一覧
• 差分 を表示
• 現在との差分 を表示
• ソース を表示
• API/設計 へ行く。
  • 1 (2021-05-06 (木) 17:26:21)
  • 2 (2021-05-06 (木) 17:48:36)
  • 3 (2021-05-06 (木) 21:33:53)
  • 4 (2021-05-07 (金) 11:25:48)
  • 5 (2022-04-19 (火) 14:56:43)
  • 6 (2022-04-22 (金) 09:03:49)

---

• 5分で絶対に分かるAPI設計の考え方とポイント

• 翻訳: WebAPI 設計のベストプラクティス
• GoogleのWebAPI設計とWebAPI設計のベストプラクティスを比較してみる
• 「WebAPI 設計のベストプラクティス」に対する所感

• WebAPIの設計から実装まで〜設計編〜
• WebAPIの設計から実装まで〜実装編〜

• API 設計: gRPC、OpenAPI、REST の概要と、それらを使用するタイミングを理解する
• Swagger、GraphQL、gRPC+Protocol Buffersの概観

• OpenAPI や Protocol Buffers のおかげで開発がかなり捗っている話
• マイクロサービスにおけるWeb APIスキーマの管理 ─ GraphQL、gRPC、OpenAPIの特徴と使いどころ

• ASP.NET CoreでgRPCサービスを作ってみた
• IoTと業務システムをつなぐgRPC/RESTサービスの開発と運用

URI †

• スネイクケース推奨
• ベースURIに「api」という単語を含める

レスポンス †

• RESTful APIのHTTPステータスコード設計

データ表記 †

• 日時
  • ISO 8601 - WIkipedia
  • ISO 8601 の時刻表記
  • ISO8601に準拠
  • 日本時間の場合：YYYY-MM-DDTHH:mm:ss+0900
• 性別
  • システムで「性別」の情報を扱う前に知っておくべきこと
  • ISO5218に準拠
  • 男性は 1、女性は 2、それ以外は 9、不明な場合は 0

エラー †

• RESTful APIのエラー設計
• WebAPIでエラーをどう表現すべき？15のサービスを調査してみた

データ項目 †

• status ... HTTPステータスコードをHTTPレスポンスヘッダに格納
• type ... エラーの種別を示すURIを格納
• title ... エラーの名称を表示
• detail ... エラーの説明文を格納

セキュアなエラーフィードバック †

• 403 Forbidden
  • データへのアクセス不許可 → データが存在することを暗に認めていることになる
  • 「404 Not Found」レスポンスに変えることも検討する

• 500 Internal Server Error
  • APIのベースとなっている技術スタックに関する詳細情報が提供されないようにすること
  • APIの内部で実際に稼働しているものの手がかりになるような情報を提供しないように注意する必要がある

ファイルアップロード †

• WebAPI でファイルをアップロードする方法アレコレ

     

Site admin: anonymous

PukiWiki 1.5.1 © 2001-2016 PukiWiki Development Team. Powered by PHP 5.6.99-hhvm. HTML convert time: 0.013 sec.