API 設計: gRPC、OpenAPI、REST の概要と、それらを使用するタイミングを理解する | Google Cloud 公式ブログ
※この投稿は米国時間 2020 年 4 月 11 日に、Google Cloud blog に投稿されたものの抄訳です。 ほとんどのソフトウェア デベロッパーがご存じだと思いますが、API 設計には RPC と REST の 2 つの主要なモデルがあります。モデルに関係なく、ほとんどのモダン API は、なんらかの方法で同じ HTTP プロトコルにマッピングすることによって実装されます。また、RPC API 設計では、RPC モデルの範囲から外れずに HTTP から 1 つまたは 2 つのアイデアを採用することが一般的になっています。これにより、API 設計者に提示されるオプションの範囲が広がりました。この投稿ではこれらのオプションについて説明し、どれを選ぶか決める際に役立つガイダンスを提供します。 gRPC は RPC API を実装するためのテクノロジーで、HTTP 2.0 をその基盤
Wordな職場にSwaggerを定着させようとして失敗したけど結局定着した話 - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに 私の職場では、WebAPIの仕様書をWordで書く習慣があったのですが、2018年頃にSwaggerで書くように切り替わったので、そのように変化した経緯を書きます。 何かの参考になれば幸いです。 ちなみに、こちらの記事と同じ職場です。 Wordな職場にMarkdownを定着させるためにやった４つのこと Swaggerとは？ Swaggerとは、REST APIの仕様を定義するためのフォーマットです。その周辺技術も含めて、Swaggerと呼ばれます。以下の記事が非常に参考になりますので、詳細を知りたい方はご参照ください。 Swa
認証
パスワード認証とは、ユーザーのログイン名とパスワードを使って認証する方法です。 パスワード認証では、リクエストヘッダーに「X-Cybozu-Authorization」ヘッダーを指定します。 ヘッダーの値はログイン名:パスワードをBase64エンコードした値です。 たとえば、ログイン名が「Administrator」でパスワードが「cybozu」の場合、リクエストヘッダーには次の値を指定します。
ReStructuredText 入門
以下の文章中に "(quickref)" という形式のリンクがあります。これは、 Quick reStructuredText ユーザリファレンスへの相対リンクです。このリンクが 切れている場合は、 オンラインのクイックリファレンス を参照してください。 構造 まずはじめに、"Structured Text" （構造化されたテキスト）という呼び方には、 いくぶん不適切なところがあると指摘しておきます。実際には、首尾一貫したパターンを使う "Relaxed Text" （形式ばらないテキスト）とでも呼ぶべきものです。そのパターンを HTML コンバータで変換することで、WEB ブラウザで扱えるような「非常に構造化された テキスト」が生成されるのです。 最も分かり易くて基本的なパターンは、 パラグラフ（段落） (quickref) です。 （1つ以上の）空行で区分されたテキストのひとかたまりが
はやわかり reStructuredText
本マークアップ記法の完全な詳細は reStructuredText のページに示されています。このテキストは、覚書としての性格の文書です。 "(詳細)" というリンクを辿ると reStructuredText 仕様書を参照できます。 ただし、相対リンクとなっていますので、リンク切れの場合は、 原版の "Quick reStructuredText" から参照してください。 目次 インライン マークアップ バックスラッシュによるエスケープ 章立ての構造 段落 記号つきリスト 番号つきリスト 定義リスト フィールドリスト オプションリスト 整形済みブロック ラインブロック 引用 Doctestブロック 表 区切り線 明示的マークアップ 脚注 出典 リンクターゲット 外部ターゲット 内部ターゲット 間接ターゲット 暗黙ターゲット ディレクティブ 代入参照とその定義 コメント 助けを得たい場合は
【図解】RESTful WebサービスにおけるHTTPステータスコード : アジャイル株式会社
RESTful WebサービスではHTTPステータスコード=処理結果 弊社 アイコン認証Webサービス は、REST方式のWebサービスとして実装されています。 REST方式でない通常のWebアプリケーションでは、通常HTTPステータスコードとしては200(OK)しか返されません。 エラー等の状態を表す場合でもHTTPステータスは200(OK)が返され、画面に表示される内容にエラーを表すメッセージ等を含ませる事によって状態を表現します。 RESTfulなWebサービスを実現する場合には、処理結果はHTTPステータスコードで表現するべきとされています。 理由としては、以下のものがあげられます。 適切なHTTPステータスコードを返さない ( 全部 200 (OK) とかの ) 場合、エンティティの中身を解析しなければ、処理結果が判別できない。 Web標準に従う事で、HTTPステータスコードから
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
REST API設計者のための有名APIのURL例 - Qiita