API の形式 — REST・SOAP・JSON・XML・CRUD を 4 つの質問に落とす

調査の詳細

このページの答えは、以下の調べで出しました。対象・確認時期・出典を並べます。

REST と SOAP — 新旧ではなく「相手が決めた形」

ここが誤解されやすい箇所です。

「RESTが新しくてSOAPが古い」という説明をよく見ますが、実務ではそう単純ではありません。 SOAPが残っているのは、相手がそう決めているからです。

編集部が56件の仕様記述を読んだ範囲では、SOAPに言及があったのは3件でした。

• Garoon
• Salesforce Platform
• Salesforce Sales Cloud

いずれもRESTと併存しています。Salesforceの場合、REST APIを中心に、SOAP・Bulk 2.0・Metadata・Connect REST など用途別のAPI群を公開しています。古いものを消していないのです。長く使われている製品ほど、こうなります。

判断としては、こうなります。

新しくつなぐなら REST を選ぶ。SOAPしかない相手なら、扱える人を確保する必要がある。

SOAPは書き方が固いので、対応できる開発者が限られます。これは費用の話です。

JSON と XML — 見た目が違うだけ

やり取りする中身の書き方です。同じ「顧客1件」を、こう書きます。

JSON

{ "id": 123, "name": "山田商事", "tel": "022-000-0000" }

XML

<customer><id>123</id><name>山田商事</name><tel>022-000-0000</tel></customer>

業務の判断は、どちらでも変わりません。 同じ情報が入っています。

変わるのは扱える人です。いまの開発者はJSONに慣れています。XMLは書式が厳密なぶん、行政の様式のように構造をきっちり決めたい場面で使われ続けています。

行政系はXMLが残っています

• e-Gov電子申請：REST/JSONのAPIですが、様式の構造仕様はXMLで定義されています
• eLTAX / PCdesk：開発者向けのXML構造仕様が地方税共同機構への申込制で開示されます。一方、給与支払報告書等のCSVレイアウト仕様書は一般公開されています

外側の通信はREST/JSONでも、中身の様式はXML、という組み合わせがあることは知っておくと混乱しません。

いつ動くのか — Webhook

4つ目の質問です。「リアルタイム連携」という言葉の正体は、たいていこれです。相手で何か起きたときに向こうから通知が来るのが Webhook、こちらから決まった間隔で聞きに行くのがポーリングで、この 2 通りしかありません。編集部が調べた範囲では、56件中7件でWebhookに言及がありました。無ければポーリングになり、聞く間隔が呼び出し回数の上限との相談になります。

GraphQL は1件

新しい方式として名前を聞くことがあります。ほしい項目をこちらから指定する書き方です。

編集部が調べた56件のうち、GraphQLに言及があったのは1件だけでした。Shopifyです。Admin APIはRESTとGraphQLの2システムで、REST Admin APIは2024年以降 legacy 扱い、2025年4月以降の新規公開アプリはGraphQL Admin APIのみで構築する決まりになっています。

1件では傾向は語れません。ただし「新しい方式に切り替える製品がある」という事実は、版（バージョン）の話として知っておく価値があります（「版（バージョン）— 旧版はいつか止まる」）。

実態：56件を数えるとこうなった

用語の説明はここまでです。実際にどれだけ使われているのかを見ます。

編集部が56件の「API仕様」欄の記述を読み、通信の作法で分類しました。

さらに、但し書きも数えました。

読み方

26件がREST/JSON。ここは素直です。用語を1つ覚えるなら REST/JSON でいい、ということになります。

問題は11件の「形式が読めない」です。 APIがあると書いてあるのに、REST なのか SOAP なのか、公開資料からは分かりません。理由はさまざまで、仕様書が申込制だったり（GビズID、ジョブカン勤怠管理）、規約同意後にしか読めなかったり（formrun）、仕様書がWord・Excelで配られていたり（e-Tax）します。

この11件は、見積もりを取る前に「形式は何ですか」と聞く必要があります。

ファイル受け渡しの2件も重要です。弥生は公開API仕様書がなく、代替として帳簿・伝票のテキスト出力とインポートの記述形式が公式サポートページで公開されています。楽楽精算は、公開ページから読み取れる仕様の輪郭が「仕訳データの自動出力」と「CSV自動取込」の2機能です。

つまりこの2件では、CSVが公式の連携手段です。 APIを探しても見つかりません。

版（バージョン）— 旧版はいつか止まる

最後にもう1つだけ。APIには版があります。版が切られるということは、いつか旧版が止まるということで、止まる前に直す必要があります。これが「作って終わりではない」と言われる理由の1つです。告知の型（廃止日が決まる／追う手段がある／追う手段がない）と、変更に気づく経路の作り方は専用のページにまとめました。

ここでの調査範囲について

• 対象は、編集部が一次調査を終えて公開している56システムです。日本の業務システム全体ではありません。「56件中26件」を「日本の○%」と読み替えることはできません。
• 確認時期は2026年7月28日〜8月19日です。仕様は変わります。
• 分類は編集部が手で割り当てました。 本文検索で語を数えると、「RESTではない」「OpenAPIの配布は確認できていない」といった否定の文でも語が出るため、逆に読んでしまいます。判断の元にした記述と出典URLは全件公開しています。
• 「公開情報を確認した範囲では見つからなかった」と「機能が無い」は区別しています。

規格そのものの出典は RFC 9110（HTTP Semantics）、RFC 8259（JSON）、OpenAPI Specification です。各システムの「API仕様」欄は RenkeiMap で1件ずつ公開しています。