操作を探す
サポートされている GraphQL サブセットについては、スキーマが正式な情報源です。操作のルート、名前、引数、入力型、列挙値がスキーマに定義されています。説明には使用方法のガイダンスが記載されており、GraphQL Explorer ではその両方を確認できます。REST のみで利用できる機能については、REST API リファレンスを使用してください。 操作名は、対応する REST エンドポイントに従い、camelCase で命名されています。GET /history は postHistory、GET /analytics/social は socialAnalytics、POST /post は createPost です。
クエリは読み取り、ミューテーションは書き込み
クエリは、こちら側で何も変更しない読み取りと検証です。ミューテーションは、公開や状態の変更、処理の開始、メールの送信を行います。どちらのルートになるかは、REST の HTTP メソッドや呼び出しのコストでは決まりません:validatePostは、投稿を公開せずにチェックします。validateMediaは、メディア URL にアクセスできるかをチェックします。generatePostは、こちら側で何も変更しないためクエリです。ただし API 呼び出しとしてカウントされ、毎回異なるテキストを返すため、クライアントのキャッシュや自動再取得によって気付かないうちに繰り返し実行されないようにしてください。mediaUploadUrlは、アカウント用のアップロード URL を作成するためミューテーションです。linkAnalyticsは、メールでのレポート送信をリクエストできるためミューテーションです。userBatchは、エクスポートジョブを開始するためミューテーションです。
投稿を作成する
createPost は単一の input 引数を受け取るため、投稿全体が 1 つのオブジェクトになります:
引数の型
ほとんどの引数は、通常の文字列、数値、ブール値です。知っておくべきケースが 3 つあります。列挙型
サポートされる値の集合が決まっている文字列引数の多くは GraphQL の列挙型であり、引用符なし・大文字で記述します:"instagram" ではありません。サーバーは、受け付けた各列挙値を内部の REST コントローラーが期待する正確な値にマッピングします。多くの場合は小文字の文字列ですが、常にそうとは限りません。無効な列挙値は、操作の実行前に GraphQL の検証段階で拒否されるため、入力ミスによるコストは発生しません。
一部の引数は、操作間で名前が同じでも受け付ける値が異なります。これはエンドポイントが実際に異なるためです。reviews(platform:) は GMB と FACEBOOK のみを受け付けます。レビューがあるソーシャルネットワークはこの 2 つだけだからです。クライアントの自動補完では、操作ごとに正しい値の集合が表示されます。
JSON スカラー
一部の引数は、特定の型ではなくJSON として型付けされています。これは、値が正当に複数の形式を取り、単一の GraphQL 型では正確に表現できない場合です:
explainError(code:)は215と“215”のどちらも受け付けます。お客様がエラーコードを両方の形式で保持しているためです。createPost(input:)は、postやmediaUrlsなどのフィールドに JSON を使用します。これらは共通の値にも、プラットフォームごとのオブジェクトにもなり得るためです。createAutomation(triggers:, actions:)は、各要素のtypeによってフィールドが変わる配列を受け取ります。boostFacebookPost(interests:)は、Meta のインタレスト ID を文字列または数値で受け付けます。
JSON 引数は抜け道ではありません。リゾルバーはディスパッチ前に値を検証するため、無効な値は検証エラーを返し、API 呼び出しを消費しません。
オプション引数と null
オプション引数や入力オブジェクト内のオプションフィールドでは、明示的なnull は省略として扱われます。リスト型が許可している場合、リスト内の null 要素は保持されます。
レスポンスを読む
ほとんどの操作は、REST のレスポンスエンベロープ全体を含むJSON スカラーを返すため、サブフィールドなしでルートフィールドを選択します。createPost は現在、型付きの PostResult を返すため、そのフィールドを選択します:
PostResult などの型付きレスポンス型には、変更されていない REST レスポンス全体を含む raw: JSON! も含まれます:
raw は恒久的なフィールドです。REST レスポンスに新しいフィールドが追加された場合に、こちらで型付けが追いつくまでの間も GraphQL からアクセスできなくなることがないように用意されています。型付きフィールドで公開されていないものが必要な場合は、raw を要求してください。
メディアのアップロード
メディアのバイトデータは GraphQL リクエストでは送信できません。 GraphQL リクエストは 64 KB の制限内に収まる単一の JSON ドキュメントであるため、ファイルを受け付けるフィールドはありません。また、画像をクエリ内で base64 エンコードすると、サムネイルより大きいものはこの制限を超えてしまいます。 サポートされている方法はこの問題を完全に回避し、バイトデータが直接ストレージに送られるため、いずれにしても API 経由でアップロードするよりも高速です:-
アップロード URL を要求します:
-
返された JSON から
data.mediaUploadUrl.uploadUrl、accessUrl、contentTypeを読み取ります。 -
ファイルを Ayrshare API ではなく
uploadUrlに直接PUTし、リクエストのContent-Typeヘッダーには返されたcontentTypeを設定します。 -
アップロードが成功したら、
createPost.input.mediaUrlsにaccessUrlを渡します:
uploadUrl は有効期間の短い書き込み用認証情報として扱い、ログに記録したり公開したりしないでください。accessUrl は投稿の作成時に使用するメディア URL です。
REST のアップロードエンドポイントを引き続き使用し、得られた URL を GraphQL から参照することもできます。2 つのインターフェースは同じメディアライブラリを共有しています。