API 2.0とAPI 1.0の違い

API IDの廃止

API 2.0では、API 1.0のAPI IDが廃止されました。
これにより、API 2.0では、APIリクエストの際、path parameterなどでAPI IDを指定する必要はありません。

参考

LINE WORKSを利用するには、テナントとドメインの関係について理解しておく必要があります。
1つのテナントは 1 つもしくは複数のドメインから構成されます。
基本的にテナントとドメインの関係は、1:1です。
グループ企業機能をこ利用中のお客様の場合は、テナントとドメインの関係が、1:Nになります。

サービス/サーバーAPI区分の廃止

API 1.0では、APIごとにサービス/サーバーAPIに区分され、認証を使い分ける必要がありました。
API 2.0では、OAuth 2.0に準拠した認可機能に統一され、APIを区分せずに利用することができます。
API 1.0のサーバーAPIに相当する利用シナリオは、API 2.0のService Account認証(JWT)を利用することにより対応できます。

Refresh Tokenの提供

API 2.0では、OAuth 2.0に準拠した認可機能により、APIを利用するために必要なAccess Tokenを取得する際にRefresh Tokenも取得することが可能になりました。
Access Tokenの有効期限が切れた場合は、Refresh Tokenを用いて、Access Tokenを再発行することができます。
これにより、API 1.0のAccess Tokenを延長する機能は廃止されます。

リソース単位のAPIアクセス権限付与

API 1.0のサービス単位でCreate/Read/Update/Delete権限付与するConsumer Keyを廃止し、API 2.0は、リーソス単位でRead/Writeアクセス権付与するOAuth Scopeを採用しました。

詳細はOAuth Scopesを参照してください。

統一されたAPIインターフェース

API別に異なったファイルアップロード/ダウンロード、リスト取得(Pagination)インターフェースを整理し、API 2.0ではすべてのファイルアップロード/ダウンロード、リスト取得APIインターフェースが統一されました。

詳細はFile Upload / Download, Paginationを参照してください。

ユーザーリソースへのアクセス方法の改善

ユーザーリソースにアクセスするために、APIリクエストのPath parameter(userId)にアカウント名(email)、リソースID(userId)、ExternalKeyを指定可能になりました。
それに加えて、一部のAPIではpath parameter(userId)に「me」キーワードを利用することができます。
「me」キーワードを利用するとOAuthで認可されたユーザー自身の権限を利用してAPIの呼び出しが可能になります。

リソースIDの提供

API 1.0の組織連携ではExternalKeyをKeyとした外部システムとの連携機能を提供していました。
API 2.0では、ExternalKeyを用いたアクセスに加え、組織、メンバー、グループ、利用権限タイプ、職級、役職などのリソースを登録する際、自動で発行されるリソースIDを用いてアクセスすることができます。
これにより、組織連携の際にExternalKeyをKeyとして外部システムと連携する必要はなくなります。

詳細はDirectory 概要を参照してください。