Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

¿Cómo regresamos un 200 OK? #5

Open
defvol opened this issue Jun 11, 2015 · 12 comments
Open

¿Cómo regresamos un 200 OK? #5

defvol opened this issue Jun 11, 2015 · 12 comments
Labels

Comments

@defvol
Copy link

defvol commented Jun 11, 2015

No necesariamente será un array de results con paginación.

¿Qué hacemos en estos casos?

@defvol
Copy link
Author

defvol commented Jun 11, 2015

Siguiendo http://jsonapi.org/format/

se me ocurre:

{
    "results": [
        "OK"
    ],
    "errors": []
}

@defvol
Copy link
Author

defvol commented Jun 11, 2015

y para error:

{
    "results": [],
    "errors": [
        {
            "message": "Descripción del error.",
            "exception": "[stacktrace detallado]"
        }
    ]
}

@defvol
Copy link
Author

defvol commented Jun 11, 2015

@chuckcfs
Copy link

@rodowi yo diria que depende del método, si es un POST, PUT o DELETE para con id el resultado debería ser el objeto creado, actualizado, borrado o leído:

{
  "id" : 13141,
  ...
}

si fuera un GET para un listado de datos ahí si deberíamos usar el campo results

{
  "results": [],
  "pagination": {}
}

y si hubiera un error se envia el código 4xx o 5xx y el resultado debería ser sólo el objeto de error:

{
  "message" : "Descripción del error.",
  "exception": "[stacktrace detallado]"
}

@carlosmaya
Copy link
Collaborator

coincido con @chuckcfs , me hace sentido que regrese el "id" en el caso del POST, PUT y DELETE

me queda la duda con el GET, ¿cuál es un escenario en donde hago un GET sin results ? eso me suena a un error, el "resource" no existe

@chuckcfs
Copy link

no, más bien yo no digo regresar solo el id, sino el objeto completo, el objeto que se cree, actualice, borre o lea

@carlosmaya el GET me refiero a:

  • Objeto - ej. GET articles/1211
{
  "id" : 121313,
  "title" : "Lorem ipsum",
  "content" : "Lorem ipsum dolor sit amet...",
  ...
}
  • Lista - ej. GET articles/
{
  "results" : [
    {
      "id" : 121313,
      "title" : "Lorem ipsum",
      "content" : "Lorem ipsum dolor sit amet...",
      ...
    }
  ],
 "pagination" : {
    "page" : 1,
    "per_page" : 20,
    "total" : 1
  }
}

@carlosmaya
Copy link
Collaborator

@chuckcfs got it!!

@rodowi viendo la wiki del API, no me queda claro ¿por qué en las respuestas de éxito también se regresa errors y lo mismo para results en la de Error? solo para entender

@chuckcfs
Copy link

no, creo que ahí esta la confusión, en los resultados existosos no se debe regresar "errors", sólo en los que algo sale mal

@babasbot
Copy link

también me agrada la propuesta de @chuckcfs

@defvol
Copy link
Author

defvol commented Jun 12, 2015

de acuerdo con @chuckcfs, por lo que veo lo que se acordó fue (me corrigen si me equivoco):

  • errors y results no deben aparecer en la misma respuesta
  • results sólo se regresa cuando estamos accesando listas, p. ej. GET /notifications, /comments
  • results siempre va acompañado de pagination
  • en POST, PUT, DELETE, GET con id, se regresa el objeto en cuestión

@defvol
Copy link
Author

defvol commented Jun 12, 2015

hey @chuckcfs lo quieres agregar a la guía?

@defvol
Copy link
Author

defvol commented Jun 12, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants