シェア:
){kind=small}
シナはVonageのJavaデベロッパー・アドボケイト。アカデミックなバックグラウンドを持ち、自動車、コンピューター、プログラミング、テクノロジー、人間性など、あらゆることに好奇心旺盛。余暇には散歩をしたり、対戦型ビデオゲームをしたりしている。
Vonage Java SDK v9.0.0の発表
所要時間：1 分
Java SDKは、前回の発表記事 前回の発表記事- 39,000行以上のコード行以上のコードだ！このメジャー・リリースには長い時間がかかり、多くの改善や、削除やリファクタリングの結果、避けられない変更もありました。SDKの品質がさらにレベルアップし、以下のようになりました。 テストカバレッジ100を達成しました。 Kotlin SDK!
当然ながら、最新のSDKバージョンを維持することは、サポートされているAPIのすべての機能を利用できるようにする最善の方法であり、もちろんバグフィックスやセキュリティアップデートも行われます。特に メッセージAPI(受信/送信メッセージのオプションプロパティ追加)、MMS、WhatsApp Reaction & Button メッセージの新メッセージタイプ、WhatsApp メッセージの既読マーク機能、そしてもちろん RCSメッセージング.Video APIでは、実装が更新され、Live Captions、Audio Connector、Experience Composer、セッショントークンのPublisher-onlyロール、エンドツーエンドの暗号化、Archivesの最大ビットレートと量子化パラメータがサポートされ、様々なバグや不整合が修正されました。
Webhookも見直され、それぞれのAPIに適したパッケージに移動され、シンプルになりました。Voice では アンサーウェブフックと EventWebhookを使うことができます。 ウェブフックを使用します (通常、アンサーとイベントの URL は異なるエンドポイントに送信されるため)。SMS API の場合は メッセージイベントを使用して 受信メッセージのウェブフック.
前回のメジャーリリース以降、新たに3つの対応APIが追加された：
待望の Conversion APIの実装は、v8.4.0でJava SDKに追加されましたが、ほぼすべてのイベントタイプをサポートするように改良されました。この低レベルAPIは Voice APIの内部構造を下支えし、多人数参加型のオムニチャネル通話やチャットを扱う、より強力な機能を提供する。これは間違いなくSDKでサポートされているAPIの中で最大かつ最も複雑なもので、上級/パワーユーザーは REST APIリファレンス.
SIMスワップ SIM スワップ APIはVonageのネットワークAPIの一つです。これにより、番号に関連付けられたSIMカードが別のデバイスに交換されたかどうかをチェックすることができます。デフォルトでは、過去10日以内をチェックしますが、過去100日以内の任意の期間を1時間単位で設定できます。これは現在、ドイツ語とスペイン語の番号でのみ利用可能であることに注意してください ( ネットワークAPIの可用性).それでも、私たちの プレイグラウンドで試すことができます。 仮想オペレーター.ただし APIコールは3段階のプロセスOAuthのため、API呼び出しは3段階のプロセスですが、SDKはこれを1つのメソッド呼び出しに簡略化し、このすべてを自動化します。
Numbers Insightと混同しないでください。 番号検証APIとは別のネットワークAPIで、デベロッパーはユーザーのデバイスが携帯電話番号と一致するかどうかをチェックすることができる。これはすでに Verify API のサイレント認証ワークフローに統合されている。- に統合されている。 コード・スニペットを参照のこと。Numbers Verification APIは複数のAPIコールを必要とするため、若干複雑である。最初のステージでは、ネットワークに接続されたユーザーのデバイスでたどれるように、ユーザーに渡せるURLを構築する。この結果、コードを含むコールバックがあなたのサーバーに送信され、あなたはそれをAPIに渡して番号とデバイスの一致をVerifyする。現在のところ、上記のSIM Swap APIと同じ制限が適用されます。
メジャーリリースは、SDKのライフサイクルが進化するにつれて自然に発生する技術的負債に対処する絶好の機会を提供します。今回のリリースも例外ではなく、前回のメジャーリリース以降、多くの非推奨事項が含まれています。これらの非推奨事項は VonageClient.Builder#setHttpClient- はすべて削除されました。VonageClient.Builderの setHttpClientメソッドはまだ存在しますが、より特注のオプションが必要な場合は httpConfigプロキシ、リクエストタイムアウト、ベース URI の設定などです。 で利用可能です。.
このリリースでは、MeetingsとProactive Connectという日没後のAPIが削除されたほか、SDK周辺の荒削りな部分が整理され、内部メソッド、クラス、コンストラクタがさらにカプセル化されたことで、SDKとのやり取りがより一貫性のある合理的な方法で行われるようになり、混乱が最小限に抑えられました。Pythonの Pythonのマントラ:
"明白な方法は1つ、できれば1つだけであるべきだ"
その結果、このリリースの変更点のほとんどは不整合への対応です。リファクタリングや変更の大部分は、ほとんどのユーザーには影響しません。気をつけなければならない主な点は、enumの再配置（以下でさらに詳しく説明します）、Stringではなくより具体的な戻り値の型（該当する場合）、そして、より一貫性のある、あるいはよりシンプルな選択肢を選ぶためにメソッド名が変更されたいくつかの場所です。うまくいけば、これらは比較的簡単に解決できるはずで、特にIDEからのヘルプや包括的なJavadocsが役立ちます。 変更履歴を参照すると便利かもしれません。削除されたほとんどの非推奨事項については、代替方法がJavadocに記述されているので、v9.0.0にアップグレードする前に、まず非推奨の使い方に対処することに集中した方がスムーズに移行できるかもしれません。
デバッグとトレーサビリティはどんなアプリケーションでも重要なので、v8.16.0ではこの点が改善された。Javaエコシステムには無数のロギング・フレームワークがあり、数年前に発見されたLog4jの脆弱性は今や悪名高いものですが、Java SDKは組み込みの java.util.logging機能に依存し、依存性と潜在的な互換性の問題をさらに最小化している。ロギングは主に で実行されます。の中で行われます。リクエストは、完全なURI、リクエストメソッド、クエリパラメータ、およびリクエストボディを含め、API呼び出しが行われる前にログに記録されます。呼び出しが成功した場合、レスポンスボディが存在すれば、それもログに記録される。さらに細かいレベルのロギングについては を参照してください。.
バージョン7.7.0以降、SDKの大幅なリファクタリングにより Jsonableインターフェイスを導入しました。現在、これらのオブジェクトはすべて JsonableBaseObjectクラスを継承しています。これは イコール, hashCode、および toStringメソッドを使って、オブジェクトのデータモデルに基づいてJSONペイロードのシリアライズとデシリアライズを行うことができます。 toJsonと fromJsonメソッドを使って、オブジェクトのデータモデルに基づいてJSONペイロードのシリアライズとデシリアライズができます。後者は Jsonableインターフェイスの静的メソッドとして実装されています。
今回のリリースの主な変更点のひとつは、列挙型の扱い方だ。ほとんどの列挙型は、内部クラスから、そうすることが意味のある上位レベルに移動され、いくつかは com.vonage.client.commonパッケージに移されました。さらに、デシリアライゼーションは全体的に標準化され、Jsonable.fromStringに依存しています。 Jsonable.fromStringメソッドに依存しています。文字列表現が既知の値と一致しない場合、IllegalArgumentExceptionを投げる代わりにnullを返します。こうすることで、オブジェクト・データ・モデルの残りの部分への入力が可能になります。このアプローチとの一貫性を保つために UNKNOWN値は、APIから返されるリテラルな有効値でない限り、ほとんどの列挙型で削除されました（例えば、Number Insightの場合）。
今回のリリースでは、データモデル・オブジェクトで使用される型が改善されました。いくつかの戻り値の型が文字列からenumや、UUID、URI、Doubleなどのより適切な型に変更されました。これらの変更に対応するためのアプリケーションのアップデートは、うまくいけば簡単で自明なはずです。 変更履歴.
最も革新的な変化は Voice APIの実装に現れている。すべてのメソッドとクラスが完全にドキュメント化され、多くの矛盾が解消された。セッター・メソッドはすべて削除され、代わりにビルダーに置き換えられている。新機能やバグ修正の他にも、Voice APIには多くの変更が加えられている。例えば、ビルダーは イベントURL.これはJSONとしてシリアライズされる際に配列でラップされなければなりませんが、SDKは混乱を避けるためにこれを隠しています。同じことが コールと ConnectAction- のエンドポイントも同様で、単一のエンドポイントしか使用できませんが、以前のSDKでは、複数の宛先エンドポイントを指定できるかのような印象を与えていました。エンドポイントといえば、NCCOを使って通話を接続するときに、2つのクラスがあったので、混乱したことがあるかもしれません： com.vonage.client.voice.エンドポイントと com.vonage.client.voice.ncco.Endpointです。.前者は 呼び出しで使われ、後者は ConnectActionNCCOで使用される。これらは現在 コールエンドポイントと ConnectEndpointという名前に変更されたので、両方をインポートすることができる。最後に CallsFilter(現在は を継承するようになりました。を継承している)。 インスタントを使用します。 クラスクラスの代わりにInstantを使用する。 CallInfoPageを継承した HalPageResponse.また EmbeddedCallsクラスが削除されたことに注意してください。 メソッドメソッドでより直接的にコールリストにアクセスできます。 の getCallInfo() メソッドを使用して、より直接的に呼び出しリストにアクセスできます。.最後に、前述したように、より強力な型付けが適用可能な場合に使用されます（たとえば レートと 価格の CallInfoの rate と price は、String ではなく Doubles に変更された)、enum は内部クラスから移動された。
v8.10.0では Numbers APIの実装が更新され、不足していたプロパティが追加されただけでなく、ドキュメントも改善されました。他のAPIとの一貫性を保つため、セッターは削除され、ビルダーが使用されるようになりました。不足していたプロパティが追加されたため、アプリケーションへのNumbersのリンクが意図したとおりに動作するようになりました。また NumbersClient#listNumbersメソッドが リスト<所有番号を直接返すようになりました。 を直接返すようになりました。を返すようになり、追加のメソッド呼び出しが不要になりました。
Numbers Insight APIのユーザーには、以下のサポートが追加された。 非同期アドバンスドインサイトが正しく実装され、正しいリクエストタイプとレスポンスタイプが設定されました。また コールバックパラメータは非同期のアドバンストインサイトでは必須です。 AdvancedInsightResponseに解析できます。 Jsonable.fromJson(String, Class)メソッドを使用して AdvancedInsightResponse に解析できます。
余談ですが、Number Insight v2がどうなったか気になるかもしれません。技術的には、このAPIはベータ版であったため、v8.2.0で追加されたこのリリースでは削除されました。このAPIは 不正検出しかし、私たちは、Number Insightと同様に、詐欺の検出と予防のための大きな計画を立てていますので、今後のアップデートにご期待ください。
Java SDKのMessages APIを使ってマルチ・チャネルやマルチ・メディア・メッセージのビルドを行おうとしたことがある人は、それぞれの場合のコードが同じであっても、チャネルとタイプの組み合わせを個別に処理する必要があるという問題に出くわしたことがあるかもしれません。例えば、次のコードですべてのチャネルとメッセージタイプの組み合わせをデモしています。 このSpringBootアプリケーションでは.共通点は何でしょう？すべてのテキストメッセージ（つまり メッセージタイプが TEXTの場合）には text(String)メソッドがあります。同様に、すべてのメディアメッセージ（つまり メッセージタイプが FILE, IMAGE, オーディオ, ビデオまたは VCARD) には url(String)メソッドがあります。これらをリファクタリングして、繰り返さずに一箇所に設定する方法が2つあります。厄介な回避策はリフレクションを使うことです。より良い方法は、インターフェイスを使うことだ。これはまさにv8.11.0から実装されたものです。テキストメッセージビルダーを にキャストできるようになりました。と MediaMessageRequestにキャストできるようになりました。チャネルによってはオプションの プロパティもあります。プロパティもサポートしているため CaptionMediaMessageRequestもあります。 MediaMessageRequestもあります。その結果、URL、キャプション、またはテキストの適用は、複数のチャネルにわたって多形的に実行できるようになりました。
昨年、Kotlin SDKを開発しているときに、Java SDKがアプリケーションAPIでCapabilitiesを扱っていることに気づきました。 アプリケーションAPIでのCapabilitiesの扱いが、不必要な冗長さと、構造上正しくないという事実のために、望まれることが多く残っていることに気づきました。Kotlin SDKの実装では、ウェブフックの型（例えば イベント, status_url, answer_url、など）をサポートするケイパビリティにのみ適用することができました。Java SDKのケーパビリティ・ビルダーは、構造上正しくなるように更新されました。 addWebhookと removeWebhookメソッドは、型固有のメソッドに置き換えられました。例えば com.vonage.client.application.capabilities.Voice.Builderクラスでは イベント, answer、そして fallbackAnswer.メッセージ機能には ステータスと イベント.これらの各メソッドは、JSONペイロードの適切なプロパティを設定し、ビルダーをより宣言的に、より冗長でなく、構造的に正しくします。ウェブフックを削除するには、単純に nullを渡すだけです。
Kotlin SDKはJava SDKの上に構築されているため、v9.0.0で導入されたブレークチェンジと互換性があるように更新されている。 旧プライシングAPIや Verify API のコードレスワークフローの削除などが含まれます。Kotlin SDKは以下の通りです。 セマンティック・バージョニングに従っているため、2.0.0がリリースされた。
ドキュメントに関する簡単なメモ：IDEから直接、またはJavadocレンダラーからインライン・コードのドキュメントを見つけることができます。 Java SDKおよび Kotlin SDKで動作します）、そしてもちろん、コード・スニペットを私たちの 開発者ポータル各製品について、SDKで各APIを使用する方法を示すコードサンプルの簡潔な単一ページビューが欲しいかもしれません。今回、このようなファイルの生成が自動化されたことをお知らせします。 Javaおよび KotlinCtrl-Fで心ゆくまでご覧ください！
Java（ひいてはKotlin）SDKは、今回のメジャーリリースでも最低限必要なランタイムとしてJava 8をサポートし続けている。この記事を書いている時点で11年前にリリースされたJava 8が、2025年になってもまだ関連性があり、使われていると考えるのは乱暴だ。しかし、人気のあるフレームワークは最低限Java 17に移行しており、私たちが依存している主要なビルド・ツール（Maven、Gradle）でさえ、Java 8のサポートを非推奨としている。さらに、Java SDKのベースとなっているApache HTTP Client 4は、アクティブな開発を終了した。一方、非同期/反応呼び出しのサポートは は長い間要望されてきた。.これを容易にするため、そしておそらくセキュリティ更新のためだけでも、ベースラインをJava 11に移行することが賢明であろう。 ビルトインHTTPクライアントを導入した。外部依存の代わりにこれを活用することで、SDKのフットプリントをさらに減らすことができる一方、基盤となるHTTPクライアントのメンテナンスとセキュリティの負担をプラットフォーム自体に押し付けることができます。したがって、一般的なグッドプラクティスとして、また次のメジャーリリースに備えて、Java 8からの移行をお勧めしたい。
Java SDKのバージョン9.0.0と、それに伴うKotlin SDKの2.0.0リリースで知っておくべき変更点は以上です。より包括的な変更点の概要については CHANGELOG.mdを参照してください。 Javaおよび コトリンを参照してください。もし何か問題が見つかったり、機能強化の提案があれば、遠慮なく GitHubで問題を提起するまたは コミュニティ・スラック.JavaとKotlin SDKの最新バージョンでVonage APIを使用する素晴らしい体験ができることを願っています！