API開発におけるIDLの問題

私たちはAPIの時代にあります、そして、我々のサービスはAPIで露出します.新しいビジネス要件が到来すると、コンテクストストームが起こり、DDDの原理で機能が劣化し、APIの形式で実装されます.バックエンドの開発者は、API契約を設計し、彼/彼女のフロントエンドピアと共有することによって彼の作品を開始します.フロントエンド開発者または他のチームからAPI契約によってその機能を設計します.つまり、私たちは、API契約の確固とした基盤に取り組んでいかなければなりません.そうすれば、スコープ内にいる全ての人が独立して仕事を始めることができます.
このドキュメントでは、APIのコンタクト共有の問題について、日常的に直面しています.なぜ、APIのデザイン、共有、開発の方法を変更することで、生産性を向上させる方法を再考する必要があるのでしょうか.

RPC研

代表的な状態転送(REST)スタイルは、分散ハイパーメディアシステム内のアーキテクチャ要素の抽象化ですロイトマスフィールディング.
RESTful APIはAPIクライアントがAPIサービスから必要とするリソースに集中します.これはResourceベースで、通常リソースエンドポイントでCRUD操作を実行します.典型的なRESTful APIは通常以下のようになります.

POST /users/501/messages HTTP/1.1
Host: api.example.com
Content-Type: application/json

{"message": "Hello!"}

対照的に、RPC APIはアクションベースです.

POST /SendUserMessage HTTP/1.1
Host: api.example.com
Content-Type: application/json

{"userId": 501, "message": "Hello!"}

In Contrast, RPC API is action based, which only have *get* and *post* functions.

REPCを使用してRPCを置き換える?

次の例を試してみてください.

用心深いアプローチ

我々はタイトルのステータスを処理する必要がライブラリシステムを開発している想像してください.ライブラリ管理者がTILTLELEのステータスを更新する必要がある場合、以下のようなAPIを提供することができます.

POST /titles/123/in

POST /titles/123/out

POST /titles/123/suspended

`shell
PATCH /titles/123 HTTP/1.1
Host: api.example.com
Content-Type: application/json

{"status": "Out"}

`

There is a problem that you want to update mutilple titles in batch and want to add background logic when you update a specific status. For example, when you want to set a title to state of "In" and notify all the readers that are in the wating list.

RPCアプローチ

You can design your API with action based RPC Post function.

`
POST /api/titles.transition_state HTTP/1.1
Host: api.example.com
Content-Type: application/json

{
"title": "123",
"status": "Out",
"user": "U123,U234"
}

`