アプリケーション連携、外部インタフェース

業務でパッケージのアプリケーションを扱っているのですが、上位システムや周辺システムとの外部インタフェースについて、どういった手段があり、それぞれどんなメリット、デメリットがあるのか、通常はどの手段を使うのか等まとめて教えていただければ幸いです。

その「業務でパッケージのアプリケーション」や「周辺システム」によって「どんなメリット、デメリット」も変わってくるかと思うのでそのアプリケーションのマニュアルやサポート窓口に相談するのが良いかと思います。他との連携を考慮していないシステムであればそもそもそのままでは連携できないこともあります。
また技術的に可能なことと会社内のルールは別なこともあるので事前の確認が必要です。

用語が色々混乱を招いている感じですかね・・・

まずは、「API(Application Programming Interface)」をおさえましょう。

APIとは、アプリケーションがその機能を使うために用意されたインタフェースです。
APIと一言に言っても、色々な形式が存在します。逆に言えば、「このインターフェースでアクセスしてください」と仕様を出せば、どんなものでもそれがAPIなのです。

API以外のアクセスもおさえておきましょう。
これは、API以外の方法でアクセスする方法です。UIを擬似するものなどもあります。公開されていないDBやファイルを直接参照するのもこれに当たります。

メリット、デメリットですが、
APIは、「安全」がメリットです。
内部構造などが変わってもAPIは変化しづらいし、変更があった場合でもその旨がきちんと報告されるので、将来に渡ってアプリケーションの保守が容易です。公開されているAPI以外の動作はできません。

API以外のアクセスは、「自由」「高速」がメリットになることがあります。
内部情報に直接参照するので、提供元が想定する以外の自由なアクセスが可能です。ただし、想定していない不具合が発生することもあります。
（例えば、不用意に排他制御を含むアクセスを頻発させて本来の処理が止まるとか）

APIの実装ですが、
昔はライブラリなどでアプリケーションに組み込み、関数呼び出しするAPIが主流でした。（関数を呼んだ先で通信などを行って他者と連携する感じです）
最近は、通信仕様をAPIとして公開されることも増えてきています。
( RPCやRESTなどで調べてみてください )

・HTTP通信連携？会話の聞き間違いだったら申し訳ないのですが、webアプリケーションのためすべてHTTPでやりとりするものだと思っているのですが間違いでしょうか？

例えばREST APIは、HTTPでやり取りしますが更にルールが決められています。
webアプリケーションはブラウザからのアクセスが基本動作となっていると思いますが、REST APIはアプリケーションからのアクセスを前提としています。（HTMLを返すわけではありません）

通常はどの手段を使うのか

最近の流行は REST APIですね。

• API連携：
  アプリケーションレベルの連携です。提供元が作成したビジネスロジックをそのまま利用できるため、データの整合性が保証され、安心して利用できます。CRUD（参照/登録/更新/削除）が可能ですが、提供元が決めた仕様に合わせる必要があるため、自由度は制限されます。
• データベース連携：
  データベース同士を直接つなぐ手法です。バッチによるテーブルコピーや、DBリンクによる参照などがあります。HTTPではなくDB専用の通信を用います。開発は容易ですが、相手のDB構造の変化に弱く（密結合）、セキュリティ上の懸念もあるため、最近はAPI連携に取って代わられる傾向にあります。ちなみにパッケージという文脈ではデータベース連携はパッケージ提供元が認めていない場合が普通な気がします。
• ファイル連携：
  CSVなどを介したデータ交換です。日次バッチなど、一度に大量のデータを一括処理（バルク処理）するのに適しています。リアルタイム性には欠けますが、システム間の依存度が低く、枯れた技術であるため確実性が高いのが特徴です。通信にはFTPかSFTPを使うことが一般的です。

HTTP通信連携は文脈を聞かないとちょっとわかりませんでした。