1

JSON で応答をフォーマットする正しい方法とその理由は何ですか? さまざまなサービスが2つの方法でそれを行うのを見てきました。単純なGET /usersリソースを考えてみましょう:

{
    "success": true,
    "message": "User created successfully",
    "data": [
        {"id": 1, "name": "John"},
        {"id": 2, "name": "George"},
        {"id": 3, "name": "Bob"},
        {"id": 4, "name": "Jane"}
    ]
}

それが私が通常そうする方法です。successとのようないくつかの抽象ヘルパー フィールドmessageがあります。さらにいくつかあるかもしれませんが、問題は、dataフィールド内のデータをリソースと同じ方法で呼び出される配列にネストする必要があるかどうかです - users:

{
    "success": true,
    "message": "User created successfully",
    "data": {
        "users": [
            {"id": 1, "name": "John"},
            {"id": 2, "name": "George"},
            {"id": 3, "name": "Bob"},
            {"id": 4, "name": "Jane"}
        ]
    }
}

抽象化を使用しない場合でも:

{
    "users": [
        {"id": 1, "name": "John"},
        {"id": 2, "name": "George"},
        {"id": 3, "name": "Bob"},
        {"id": 4, "name": "Jane"}
    ]
}

どのクライアントも、ユーザーが言及されている 、および次のようなクライアントコードでusers構成される、呼び出したルートを知っているため、キーは廃止されているようです/users

$users = $request->perform('http://this.api/users')->body()->json_decode();

よりもずっと良く見える

$users = $request->perform('http://this.api/users')->body()->json_decode()->users;

繰り返されることを避けるためusers、

4

3 に答える 3

2

同じページにたどり着くのdataは、JSON オブジェクトのフィールドです。最初の例では、の値dataは配列です。2 番目の例では、の値dataはオブジェクトです。

どちらも有効なので、質問に答えるには:いいえ、名前付きオブジェクトに名前付きオブジェクトをネストする必要はありません。オブジェクトのすべてのフィールドに名前を付ける必要がありますが、オブジェクト内で配列を自由にネストできます。

実際には、プロセッサが何を期待しているかに依存します。data何でもよい場合は、最初のアプローチで問題ありません。フィールドの値がdataオブジェクトであることをコードが想定している場合は、2 番目の例のようなものを使用する必要があります。

于 2013-09-25T11:50:19.053 に答える
2

エンベロープが役立つユースケースの 1 つは、大きなリストを処理することが予想され、巨大な応答ペイロードを防ぐためにページネーションを行う必要がある場合です。エンベロープは、ページネーション メタデータを配置するのに適した場所です。

{
    "users": [...],
    "offset": 0,
    "limit": 50,
    "total": 10000
}

(これは、私が取り組んでいる RESTful API で行うことです)

明らかに、これは物事のリストを返すリクエスト (例: /users/) にのみ関連し、単一のエンティティを返すリクエスト(例: ) には関連し/users/42ません。代わりに、このメタ データの応答ヘッダー。

PS。具体的な使用例がある場合にのみ、successandフィールドを使用することをお勧めします。messageそれ以外の場合は気にしないでください。それらは単に不要です。

于 2013-09-25T21:51:14.237 に答える