fusion_place のサーバの URL の末尾に、/api/1.2/requests を追加したものが、API 用の URL です。例えば fusion_place のサーバの URL が、http://localhost:50000/fusionplace ならば、API 用 URL は以下の通りです。

[Web-API] の HTTP アクセスにおいては、[ブラウザ] 等のクライアントプログラムと同様に、fusion_place サーバに設定された認証方式（デフォルト: Digest 認証 ^[2]）が用いられます。したがって、[Web-API] を使用して fusion_place サーバに処理を依頼するクライアントプログラムは、設定された認証方式に対応している必要があります。多くのプログラミング言語で、Digest 認証（または Basic 認証）に容易に対応できるようなライブラリが提供されています。

Digest 認証 / Basic 認証では、ユーザ管理の範囲を表すために「レルム（Realm）」を用います。fusion_place のレルムは FusionPlace System です。

なお、[Web-API] は、fusion_place 使用権許諾契約書で定義される「クライアントプログラム」のひとつです。従って、ひとつのユーザアカウントを用いてひとつのクライアントプログラムで運用できるセッション（ログイン以降ログアウトまたはクライアントプログラム終了までの業務）の数はひとつに限られるという、使用権許諾契約約款又は利用規約中の規定は、[Web-API] にも適用されます。

HTTP メソッド（HTTP プロトコルを用いてサーバに処理やデータを依頼する際の命令文）には、GET, PUT, POST などがありますが、fusion_place の [Web-API] では、必ず、POST を用いて下さい。

リクエスト送信に先立って、認証を済ませ、セッションを確立したい場合があります。このようなニーズが生じるのは、典型的には、HTTP/1.1 で導入された「Chunked transfer encoding （CTE）」を用いてデータ送信したい場合です。

CTE を適用すると、送信するデータの長さを HTTP ヘッダ（Content-Length）に設定する必要がないため長大なデータを送信するのに便利ですが、一部のクライアントは、CTE を適用した場合には認証に対応していません（例えば、Java のクライアントサイド API である HttpUrlConnection）。

そのような場合、ここでご説明するリクエストボディを含むリクエストを CTE を適用しないで送信し、その後、CTE を適用して通常のリクエストを送信します。そのようにすると最初のリクエスト送信時に認証が行われますので、後続の CTE でのリクエスト送信時は認証を回避することができます。