Gibt es einen Standard für das JSON-API-Antwortformat?

Question

Gibt es Standards oder bewährte Verfahren für die Strukturierung von JSON-Antworten von einer API? Natürlich sind die Daten jeder Anwendung anders, so dass ich mich damit nicht befasse, sondern eher mit der "Antwortvorlage", wenn Sie so wollen. Ein Beispiel für das, was ich meine:

Erfolgreiche Anfrage:

{
  "success": true,
  "payload": {
    /* Application-specific data would go here. */
  }
}

Anfrage fehlgeschlagen:

{
  "success": false,
  "payload": {
    /* Application-specific data would go here. */
  },
  "error": {
    "code": 123,
    "message": "An error occurred!"
  }
}

Answer 1

Früher habe ich mich an diesen Standard gehalten, er war ziemlich gut, einfach und sauber auf der Client-Ebene.

Normalerweise ist der HTTP-Status 200, also eine Standardprüfung, die ich oben verwende. und ich verwende normalerweise das folgende JSON

Ich verwende auch eine Vorlage für die APIs

dynamic response;

try {
   // query and what not.
   response.payload = new {
      data = new {
          pagination = new Pagination(),
          customer = new Customer(),
          notifications = 5
      }
   }

   // again something here if we get here success has to be true
   // I follow an exit first strategy, instead of building a pyramid 
   // of doom.
   response.success = true;
}
catch(Exception exception){
   response.success = false;
   response.message = exception.GetStackTrace();
   _logger.Fatal(exception, this.GetFacadeName())
}

return response;

{ 
  "success": boolean,
  "message": "some message",
  "payload": { 
     "data" : []
     "message": ""
     ... // put whatever you want to here.
  } 
}

auf der Client-Ebene würde ich folgendes verwenden:

if(response.code != 200) { 
  // woops something went wrong.
  return;
}

if(!response.success){
  console.debug ( response.message ); 
  return;
}

// if we are here then success has to be true.
if(response.payload) {
  ....
}

Beachten Sie, dass ich die Pyramide des Verderbens frühzeitig vermeide.

Answer 2

Ein bisschen spät, aber hier ist meine nehmen auf HTTP-Fehler-Antworten, ich sende den Code, (über Status), die generische Nachricht und Details (wenn ich Details für einen bestimmten Endpunkt, einige sind selbsterklärend, so dass keine Notwendigkeit für Details, aber es kann benutzerdefinierte Nachricht oder sogar eine vollständige Stack-Trace je nach Anwendungsfall) bieten wollen. Für den Erfolg gibt es ein ähnliches Format, Code, Nachricht und alle Daten in der Eigenschaft data.

Beispiele für ExpressJS-Antworten:

// Error

    res
      .status(422)
      .json({
        error: {
          message: 'missing parameters',
          details: `missing ${missingParam}`,
        }
      });

    // or

    res
      .status(422)
      .json({
        error: {
          message: 'missing parameters',
          details: 'expected: {prop1, prop2, prop3',
        }
      });

 // Success

    res
      .status(200)
      .json({
         message: 'password updated',
         data: {member: { username }}, // [] ...
      });

Answer 3

Beste Antwort für Web-Apis, die von mobilen Entwicklern leicht verstanden werden kann.

Dies ist für "Erfolg" Antwort

{  
   "code":"1",
   "msg":"Successfull Transaction",
   "value":"",
   "data":{  
      "EmployeeName":"Admin",
      "EmployeeID":1
   }
}

Dies ist für "Fehler" Antwort

{
    "code": "4",
    "msg": "Invalid Username and Password",
    "value": "",
    "data": {}
}