【開発モダナイゼーション】第16回「APIに関する大きな秘密(前編)」

2023年12月1日　チャーリー・グアリーノ

IBM i上のAPIの日常的価値について、開発者レイニア・サジュー氏と進行役のチャーリー・グアリーノ氏が議論します。

チャーリー・グアリーノ（以下、チャーリーと略記します）：
皆さん、こんにちは。チャーリー・グアリーノです。TechTalk SMBの別エディションにようこそ。今日は、弊社Central Park Data Systemsチームの上級開発者の1人、レイニア・サジュー氏をゲストとして迎えたことをとても嬉しく思います。何年もの間、私はレイニアと一緒に仕事をすることができてとても幸運でした。彼は本当に上級開発者で、私達の最も難しい任務のいくつかをこなしています。レイニア、今日は参加してくれてありがとう。

レイニア・サジュー（以下、レイ二アと略記します）：
ありがとう、チャーリー。ここに来て楽しい時間を過ごせ大変光栄です。

時と共に変わるAPI

チャーリー：
素晴らしい時間を過ごしましょう。レイニア、今日私があなたに参加をお願いした理由は、私達がAPIを使用して私達の顧客と多くの作業を行っていることを知っているからです。モダナイゼーションについて話すと、APIエコノミーという用語が常に出てきます。私達はまさにAPIエコノミーの中におり、今日そこでは世界が相互に取引先等と通信するためにAPIが使用されているように見えます。APIについてはどのような経験がありますか?

レイニア：
APIは私の毎日の仕事の一部です。私達には、毎日、週末、24時間年中無休の店舗で取引を行っている多くの顧客があり、そこでWebサービスやAPI、マイクロサービスを利用したり、ホスティングしたりしています。私はいつもそれらに取り組んでいます。私達は常に新しいものを配備し、新機能を追加し、常に改善を行っており、現在APIはコミュニケーションの方法のフレームワークのようなものになっています。プラットフォームに依存しないので、基本的にAPIを公開すれば、誰もがあなたのシステムに接続したり、あなたが彼らのシステムにアクセスしたりすることができます。

チャーリー：
私達は、長年に渡り特にIBM iのAPIを扱ってきて、テクノロジーがどのように変化してきたかを見てきました。つまり、APIを扱うためにIBMから提供されたツールが、新リリースやTRの都度さらに改善されました。例えば昔、私達は古いHTTPGETCLOBを使用していましたが、大幅な改善が見られました。それについていくつか話しませんか? まず、古い技術について話し、それからそれがどのように改善されたのかについて話しましょう。

レイニア：
HTTPGETCLOBとHTTPGETBLOBが世に出てから少し時間が経ちました。これらは、他のWebサービスや世の中にあるAPI (マイクロサービス) を利用できるようにするためにIBMがJavaの上にSQLコマンドを置いたSQL関数です。現在、それらにはもっと新しいものがありますが、私の理解ではもっとcurlベースだと思われます。それは、遥かに高速でほとんど同じ仕事をしますが少しだけ異なります。

チャーリー：
確かにより速く動作し、パフォーマンスが改善していると言いましたが、新旧のサービスを使ってこれらのサービスの1つを利用するのにかかる時間について、パフォーマンスの観点で何が分かりましたか?

レイニア：
古いWebサービスはJavaベースでした。IBM i上でJavaを実行したことがある人なら、それが少し負荷の高いことを知っています。それはいくらか多く資源を消費します。Java環境を構築しなければならず、いくつかの困難を経験します。Javaを離れてそれをcurl に移行すると、呼び出しはおそらくほぼ200%高速になるでしょう。新しいコマンドは古いコマンドに比べて大変高速です。

チャーリー：
明確にしておきたいのですが、私達はWebサービス、つまりあなたの言うAPIの利用について話しています。なぜなら、この議論では明らかにどちらの方向にも進むからです。私達はAPIを利用することも提供することもでき、２つの異なることについて話をしますが、現時点ではこれらの新機能に関してはWebサービスの利用について話しています。

レイニア：
その通りです。

チャーリー：
私達が話している新しいSQL関数についてですが、これらの新しい関数を使い始めるために移行するのは、どれくらい難しいのでしょうか? それは、ただそのまま組み込むだけの何かだったのでしょうか? 新しいコマンドの実際の構文形式にはアンダースコア文字が使われており、少し異なっていることは知っています。しかし、新しい関数を使用するための移行作業はどのようなものでしたか?

レイニア：
非常に高いレベルで見ると、それらはまったく同じ仕事をします。もう少し下のレベルに進むと、IBMがデータ部分とヘッダの仕様またはオプションを反転したことに気づくでしょう。以前APIの1つを呼び出したときは、URLがありその次にヘッダのようなものがありました。呼び出しにデータが必要な場合は、データパラメータがあります。現在、IBMはデータとヘッダまたはオプション (IBMはパラメータと呼んでいますが) をちょっと反転させました。ですから、Java版のAPIから始めている場合は、それが基本的に同じ3つの変数であることを知っておく必要があります。しかし最後の2つ、データとヘッダはちょっと反転させられています。

新旧のAPIを両方保持・使用する理由

チャーリー：
私達が使用するすべてのサービスを実行する1つの大きなサービスプログラムがあること、そしてそのサービスプログラムには、従来の機能と新しい機能の両方の機能がすべて含まれていることは知っています。その目的は何でしたか? なぜAPIを処理するただ1つの大きなサービスプログラム内に新旧両方の機能を保持しなければならないのですか?

レイニア：
その質問をしてくれてありがとう。両者の土台には違いもあります。Java Webサービスを使用すると、証明書は実際にJava環境に組み込まれます。証明書は一般的なIBM証明書の保管場所を使用しているので、何かが機能せず新しい証明書が必要になることや、古い証明書では機能したのに新しい証明書では機能しなくなることが時々あります。時にはJavaに組み込まれているJava証明書の保管場所から証明書をエクスポートし、IBMが新しいSQL HTTP関数用に作成することを推奨している新しい証明書の保管場所にインポートする必要があります。留意するべきもう1つの警告は、古いSQL関数はすべてXMLベースだったので、ヘッダ及びヘッダの仕様、オプションの仕様は XML である必要があるということです。ヘッダとすべてにほぼ同じオプションがありますが、新しいものはJSONベースなので、現在はすべてが JSON構文である必要があります。

チャーリー：
つまり、使用されているすべてのAPIを分離すると、サービスプログラムで行ったようなプログラミングが、API呼び出しの必要なすべてのプログラムのためにすぐに使い始められ、新しい機能をすぐに使い始められるのですか?

レイニア：
そうです。サービスプログラムを通じてそのようにした理由は、サービスプログラムには役に立つオプションパラメータがあるからです。これは、サービスプログラムの実行の仕方を指定する一連のフラグです。フラグの1つは、新しいサービス呼び出しを使用するか古いサービス呼び出しを使用するかというものでした。そのため、基本的にすべてのプログラムからは何も変更されませんでしたが、内部ではパラメータに基づいて新しいサービス呼び出しを使用するか古いサービス呼び出しを使用するかを決定できました。

チャーリー：
新しいものの方がずっと優れているのに、古いものをまだ使いたいと思う人がいるのはなぜですか?

レイニア：
先ほど言ったように、まだそのアプリケーションに手が回らないことがあるので、それは一種のレガシーとして残っています。また、新しい顧客が現れ、新しいAPIでプログラムがうまく動作させられないように見える場合には、古いAPIを実行して動作するかどうかを調べるために先を見越して使用することもあります。それがうまく行くとしたら、主な違いは何でしょうか? 新しいAPIではなく古いAPIで機能するのはなぜでしょうか? 私にとって、これは単なる組織内のツールの1つであり、Webサービスをどのように実行するか、またはどのように利用するかを理解するためにPostmanまたはSoapUIを使用する必要があるのと同じことです。

チャーリー：
あなたが言ったツール、PostmanとSoapUIはとても優れています。最初にデータ つまりペイロードについて学び、何が返されるかを調べるにはもってこいだと思いますし、特定のAPIを使用してプログラミングを行うために知る必要があることです。

レイニア：
私はプログラム全体の作成に入る前に、よくそれを最初のステップとして使用します。呼び名はどうあれ、APIマイクロサービスあるいはWebサービスが確実に動作することを確認したいので、すべての事からIBM iを除外したいと考えています。PostmanまたはSoapUIにアクセスして、認証情報が機能することを確認します。つまり、私に提供された情報が機能することを確認したいのです。なぜなら、これらすべての接続を構築しているときほど悪いことはないからです。プログラムを実行すると、トークンが間違っているか、URLが間違っているか、そのようなことが分かります。あなたは何が起こっているのかを理解しようと頭を悩まし、これにずっと時間を費やしているのです。

チャーリー：
SoapUIとPostmanは本当にこの世界に入るために不可欠なツールです。

レイニア：
SoapUIまたはPostmanとの間で送受信される生データが確認できるので、それは優れたスナップショットも提供します。何が送信されているか、そして戻ってくる生データが何であるかを調べることもできます。データが戻って来て可能な限り多くのデータが取得できるという同じ見地から、たとえ古い関数であっても私は常に詳細バージョンを使用することを勧めます。なぜなら、詳細ヘッダを取得できるので、返送されたHTTPヘッダを実際に調べられるからです。エラーコードを見ることができ、何が起こっているのかが理解できます。

主流はSOAPからRESTへ

チャーリー：
私達がAPIの世界に入ると、常に異なる議論や技術が存在します。例えば、何年も前に私達が初めてこの問題に取り組み始めたとき、重要なAPIはSOAPでした。そして、私達の顧客の中にはまだSOAPを使用している顧客が何人かいることを知っています。なぜなら、それが顧客の求めていることだからです。しかし、RESTとSOAPに関してはどう考えていますか? 明らかに、今ではほとんどの顧客がRESTを使用していると想像しなければなりません。

レイニア：
SOAPが最初に出てきてRESTは少し遅れて登場しましたが、RESTはもう少し柔軟です。RESTはSOAPのようなプロトコルではないので、より柔軟でカスタマイズしやすい傾向があります。様々な市場やあらゆるものに取り組む場合、皆同じREST APIを使用して、GETとPUTなどあらゆることを行っていますが、誰もが独自のちょっとした特色を持っています。データをどのように保護するか、トークンをどのように実行するか、データをどのように送信したいか、データが暗号化されているかどうか、その他すべてのことです。確かに、世の中にはSOAPよりも多くのRESTが存在します。もう1つの理由は、SOAPはXMLベースですが、RESTサービスはもっと柔軟なのでXML、JSONまたは任意のものにできるからだと思います。

チャーリー：
しかしその点でも、今日ではJSONが明らかに王様であることが分かりましたね。

レイニア：
ええ、いかなる新しいSOAP呼び出しも受信したことがありません。SOAP Webサービスをもっている顧客の一部は現在も保守を行っており、ある点で、SOAPを保守しつつ、REST Webサービスつまり顧客が利用できるAPIも導入しています。なぜなら、先ほど言ったように、XMLではなくJSONを求める顧客が増えているからです。

APIのバージョン管理

チャーリー：
あなたは簡単に触れましたが、新しいバージョンのサービスが利用可能になること等について話しましたね。まず、バージョン管理とは何なのか、そしてAPIの世界でそれがどのように機能するのかを皆さんに説明してもらえますか?

レイニア：
バージョン管理は基本的に、API Web サービスプログラムに機能拡張や変更を加えるときに行われます。そこでは、より多くの情報や詳細を消費者に提供するためにデータを送り返す方法を変更したりすることがあり、逆もまた同様です。これを使用するときに、接続している相手が新しいバージョンの API を提供する可能性があります。多くの場合、基本的に全員がそれに慣れることができるようにするために、彼らは新しいバージョンに徐々に移行します。彼らは1つのURLをもつ傾向があります。彼らはURLにバージョンを埋め込んでいることがあるのでV2かV3であるかが分かります。新しいものが出たらV4かV5になるでしょう。これにより、実稼働中に開発を行うことができ、適切な情報を取得してプログラムに適切な変更を加えたことに満足したら移行することができます。これにより、誰もが自分の経路、自分のタイミングで移行できるようになります。ただし、通常彼らは期限を設定します。通常は、6か月以内にV2をサポート中止にするなどと言います。V4に移行しなければならないので、それまでに6か月の猶予が与えられます。変更などを行う場合、私は同じ方法を使用する傾向、つまりユーザーが新しい体験を得られるように、新しいURLまたは別のブランチ即ちURLの拡張子を作成する傾向があります。ただし、準備ができていない他の顧客や消費者に配慮して、古い機能を取り除くことはありません。

チャーリー：
そうですね、同一プログラムの2つまたはそれ以上の数のバージョン、あるいは同様のプログラムが同じ時期に使われたりしていました。

レイニア：
そうですね。前に述べたように、私達がホスティングしているレガシーSOAPサービスを使用している顧客がいくつかありますが、一部の顧客はそれをJSONなどで要求するので、そのRESTバージョンも導入しており、それには別のURLがあります。したがって、SOAP版に行くこともREST版に行くこともできます。

取得データの解析

チャーリー：
そうです。APIからペイロードを取得したら、このペイロードに対して何かを行う必要があります。通常はそれを解析する必要があり、IBM i上でデータを解析するにはいくつかの方法があります。RPG内から直接実行できることは知っています。それがXML、XMLTOまたはDATA-INTOの場合は言うまでもありませんが、方法はこれら2つだけではなく、より有利な方法があることは知っています。あなたがSQLを使うのが好きなのは知っています。通常、SQLを使用してペイロードをどのように解析しますか?

レイニア：
そうですね、JSONテーブルやXMLテーブルなど、IBMが提供する組み込み関数がいくつかあります。私がもっぱらXMLとJSONテーブルを気に入っているのは、必要なデータを具体的に要求して、必要なものだけを取り出すことができるからです。あなたが前に述べた他の解析オプションの一部では、すべてのデータを取り込む必要があります。SQLではデータを取り込み、更新された価格だけを探している場合に、すべてを取得する必要がないのが便利です。基本的にはAPIでデータを取得するとすべてのデータが取得されますが、実際SQLを使用すると必要な価格だけを取得できます。

今回はここまでです。次回の後編ではAPI使用時の文字コード変換やスロットリング対策など、実務上トラブルになりやすい話題について議論します。