GraphQLの "index"リストと "show"の詳細をモデル化するには？

Question

私のデータモデルには、FolderとMessagesという2つのリソースがあります。各メッセージはフォルダに属します。場合によっては、フォルダのリスト（各フォルダのいくつかのフィールドを含む）を取得したいと思うことがあります。ときには、特定のフォルダの詳細（そのフォルダのフィールドやメッセージを含む）を取得したい場合があります。

Rails/RESTfulシステムでは、これはFolderリソースのindexとshowアクションに対応します。後者は所望のフォルダを指定するidパラメータを受け取る。このスキーマは、「慣用的な」GraphQLでどのように見えるでしょうか？

一つのアプローチは、アクションごとに一つのフィールドを持っているかもしれません。

type Query { 
    folders: [Folder] 
    folder(id: String!): Folder 
} 

は厄介なようで、それが難しく、クライアントはイントロスペクションとスキーマを理解できるようになり、ここでいくつかの重複、あります。

おそらく複製はNULL引数で除去することができる。

type Query { 
    folder(id: String): [Folder] 
} 

idが渡された場合、そのFolderのちょうど詳細は（一項目配列として）返されます。 idがnilの場合、すべてのフォルダの詳細が表示されます。このオーバーロードは隠された複雑さを加えるようです。

どのアプローチが「より良い方法」ですか？この状況をモデル化する良い方法はありますか？

Answer 1

私は第2のアプローチを使用します。この方法で、後で同じエンドポイントにさらに引数を追加できます。フォルダーにパスがあるか、作成日にフィルターするのが好きかもしれません。

Answer 2

TLDR：フィールドは安く、使用してください。

私は最初のアプローチを提案します。同じように、REST APIはさまざまな振る舞いを引き起こすフラグで絶望的に混乱する可能性があるため、さまざまな引数を持つフィールドを使用できます。

type Query { folders: [Folder!]! folder(id: String!): Folder }

この場合、あなたは常にfoldersのために戻って、リストのいくつかの並べ替えを得るでしょうし、それが含まれています：2つの異なるフィールドにすることで、あなたはまた、型システムは、より強力なクライアントの保証を与えてみましょうことができます任意null秒。空は空リストに過ぎません。 APIはそれ自体を文書化します。オプション引数の数が増えて1つのフィールドにマッシュしようとすると、そうでないかもしれません。

また、foldersのページ番号を設定する必要がある場合は、そのエンドポイントのページング固有の引数と、おそらくconnection patternの中間構造が必要です。