実際に Asana の API を統合する前に、すぐに目に留まった点がいくつかありました。まずはそれらについて見ていきましょう。

簡素化されたUI

まず目に留まるのは、そのエレガントなデザインです。エディターの上部には、左側に接続の詳細、パラメーター、ヘッダー、右側に応答データが表示されます。この整理されたビューにより、API に関するすべての詳細を 1 か所で確認できます。

2 番目に注目すべき点は、Studio Pro から直接 API にテスト リクエストを送信できることです。

これらの素晴らしい機能のいくつかを詳しく見ていきましょう。

API を統合するときに、統合の管理を容易にするためのいくつかの新機能が提供されます。

まず、統合する API コレクションのベース URL を設定できます。[構成と認証] をクリックすると、リクエストに使用するルート URL を定義できます。Asana の場合は https://app.asana.com/api/1.0 です。

ベース URL を定義すると、コレクションから行うすべてのリクエストにその URL がプレフィックスとして付加されます。これは上の画面で確認できます。

新しいリクエストの作成は簡単です。「リクエストの追加」をクリックすると、画面に新しいリクエストが開きます。リクエスト間を移動するには、「構成と認証」と「リクエストの追加」の間のタブをクリックします。作成したリクエストのドロップダウン メニューが表示されます。

ヘッダーとパラメータの追加も簡単になりました。ヘッダーを追加すると、よく使用されるオプションのリストが表示されます。(通常とは異なるものについては、常に「カスタム」オプションがあります。)

新しい UI では、アプリを実行せずに Studio Pro でエンドポイントに直接テスト リクエストを送信することもできます。リクエストが正しく統合されている場合、レスポンスは右側のレスポンス データの下に表示されます。

リクエストが成功すると、Studio Pro は応答データを使用して、適切なドメイン モデルを生成します (現在ドメイン モデルが存在しない場合)。また、「再作成」をクリックすると、いつでも応答のこのデータ マッピングを再作成できます。

新しいコネクタを使用して Asana を統合する

GET/ワークスペース

実験の一環として、Asana のワークスペース エンドポイントに GET リクエストを送信しました。このエンドポイントは、ユーザーの組織 (Asana のデータ構造のルート) を返します。すべてのチーム、タスク、フィードバック項目は、組織構造内に含まれています。ワークスペースまたは組織のグローバル識別子である GID がなければ、先に進むことはできません。

このリクエストにはAsanaからのPATが必要です。この単純な実験ではOAuthを実装しないことに決めたからです。PATの取得方法の詳細については、こちらをご覧ください。 こちら.

これは GET リクエストなので、リクエストの一部として PAT を送信するには、Authorization ヘッダーを定義する必要があります。次に、ユーザーを認証するために、キーワード「bearer」とともにトークンを送信する必要があります。

「ヘッダー」の下で「新規」をクリックし、「カスタム」ヘッダー オプションを選択し、値「Bearer XXX_MyPAT_XXX」でキー「Authorization」を定義しました。

ほんの数回の操作で、送信ボタンを押して作業をテストする準備ができました。「200 OK」の応答が返され、すぐにドメイン モデルが生成されました。そのときに生成することにしました。

この GID を PAT と一緒に使用すると、Create Task エンドポイントを統合できるようになります。

POST/タスク

Asana には非常に柔軟な API があり、タスクを作成するために承認された PAT とワークスペース GID 以外の追加情報は必要ありません。その他のフィールドは空白のままにできます。タスクは、作成時にこれらのデフォルト値を使用します。

ただし、「name」文字列、「completed」ブール値、および「notes」文字列は引き続き設定します。

Asana には、API ドキュメントを表示すると右側にリクエストの作成に役立つ便利なプレイグラウンドがあります。私はこれを使用してリクエストの JSON 本文を作成しました。Studio Pro の「本文」フィールドに貼り付けて、「JSON スニペットの使用」をクリックしました。Asana はデータを解釈し、本文構造の下に可能なモデルを作成したので、それを適用することにしました。

その後、興味が湧いたので送信ボタンを押しました。Studio Pro は即座に「201 Created」応答を返しました。次に、このデータを使用して応答のドメイン モデルを生成しました。このモデルは、実装されると実際にデータを保持します。

残っているのは、このサービスをマイクロフローで呼び出すことだけです。ツールボックスの「統合アクティビティ」の下に「REST リクエストの送信」アクションがあります。これをフローにドラッグしたら、REST サービス (この場合は「CreateTask」リクエスト) を選択するだけです。

その後は、API 用に定義したエンティティを使用してデータを作成するだけです。

通常どおりにエンティティを作成し、互いの関連付けを設定することを忘れないでください。次に、データを「REST リクエストの送信」アクションに提供するだけです。

結論

全体的に、新しいコネクタの使用は非常に直感的であることがわかりました。統合は私の専門分野ですが、この分野の初心者でも、このコネクタの使い方を習得するのに問題はありません。

その一方で、 Mendix 統合により、作業を整理して実装するためのよりクリーンで効率的な方法が実現します。

前述したように、コネクタはベータ版です。現時点では PUT または DELETE アクションはサポートされておらず、柔軟性とセキュリティを向上させるために、さまざまな認証タイプに定数を設定する機能の追加に取り組んでいます。

全体的に、私はこの新しいコネクタを楽しみました。RESTの扱い方に新鮮な変化をもたらしてくれました。 Mendix.