hola David, Javascript es muy diferente a HTML y CSS, pues JS es un lenguaje de programación completo, así que si nunca has programado en otro lenguaje, es muy probable que sufras, pero valdrá la pena,

Gracias por le comentario Raul, muy buen artículo el tuyo también, facilidades por eso.

Me ha gustado mucho el artículo, enhorabuena 🙂 . Yo escribí hace un tiempo un pequeño artículo para aprender a validar ficheros JSON desde consola en GNU/Linux 😀 . Dejo la URL por si es útil para otros visitantes.

https://www.raulprietofernandez.net/blog/pequenos-trucos/como-validar-ficheros-json-desde-consola-en-gnu-linux

Un saludo 🙂

Hola Miguel.
A lo que yo me refiero con esa frase, es un poco a lo que mencionas, y es que un código 400 no es suficiente, si no que además, es necesario mandar un payload con un mensaje descriptivo del error, de esta forma el código de error (400) le sirve al sistema para identificar que la petición retorno con error, pero el payload le sirve al usuario, pues le muestra un error que hace sentido para un humano.

Espero haber aclaro el comentario.

saludos.

Hola, yo soy nuevo en estos temas pero acabo de terminar de armar un servicio rest

En cuento a esta linea:
por ejemplo si el servicio te regresa un 400 (Bad request), ¿como sabría que hacer el usuario?

Puedo comentar que ambos tienen parte razón y parte no.

Depende de nosotros crear Apps/WebServices de calidad, de mi parte cuando recibo un petición JSON, valido que tenga los datos que requiere la llamada, si no es así respondo con un mensaje claro y descriptivo, para la corrección del problema en fase de desarrollo y algunos otros en fase de producción.

Si bien cuando desarrollamos una app para usuario final, debemos considerar hasta los usos más absurdos para ayuda del usuario, cuando se crea un webservice la responsabilidad es doble ya que también debemos considerar omisiones en el desarrollo del app que consumirá el servicio.

Hola David,
Es claro que tu tienes una opinión diferente a la mía, y eso es bueno, al final, estamos aquí para discutir y aprender entre todos.
Realmente yo si creo que un XML es semanticamente mucho más estructurado que un JSON, además, los XML soportan atributos, los cuales sirven como metadatos que dan más información sobre el mismo campo. Con respecto a las validaciones, en correcto que no debemos de confiar en que el usuario mandará bien la información, por eso comento que en XML como en JSON hay tecnologías para poder validar las entradas, y también comente que el XML tiene un XSD el cual es mucho más potente para validar que todo el XML este bien formado.

Con respecto a tu último párrafo, no creo que sea verdad, por que con el puro código solo te da una remota idea de lo que paso, pero no tienes un mensaje legible para el usuario, para que este pueda tomar las acciones pertinentes para resolver el problema. por ejemplo si el servicio te regresa un 400 (Bad request), ¿como sabría que hacer el usuario?

“con respecto a la simplicidad yo si difiero un poco ya que un XML tiene una sintaxis mas clara”

En realidad es al revés, JSON tiene una mejor estructura (llaves en lugar de etiquetas) para visualizarlo, interpretarlo y procesarlo con respecto a un XML, sobretodo si es un archivo grande y con objetos anidados.

“En un entorno de integración SOA confiar en que el proveedor externo nos envía un mensaje valido es un error que frecuentemente lleva a que los procesos marquen algún error”

No necesariamente tiene que ser así porque con REST la aplicación cliente recibe los códigos de estado propios de HTTP y en base a eso reaccionar de una forma u otra, por otro lado dentro del código de la aplicación un objeto JSON es interpretado como tal en JavaScript y por lo tanto basta una simple validación para saber si un objeto o una propiedad esta presente en él.

Saludos.

Hola Laura, me da gusto que tu interés en el tema, te comento de momento no tengo artículos que hablen de Rest, sin embargo, te puedo contar que los servicios Rest son parecidos a los servicios SOA en algunos puntos, lo principal es que los dos utilizan como protocolo de transporte Http o Https. Una de los puntos más característicos por lo general es que los servicios SOA o SOAP viajan en formato XML mientras que los servicios Rest utilizan Json como formato de los mensajes, sin embargo hay algo que debes de tener en cuenta y por lo general mucha gente ignora, y es que los servicios Rest pueden tener cualquier formato de Entrada/Salida, es decir podrían recibir o responder un Json, un XML, un archivo plano o incluso parámetros en la URL, básicamente podría recibir cualquier cosa que pueda ser enviada por los métodos de http como GET, PUSH, DELETE, POST.

Por otro lado, la forma de implementar un servicio Rest varía según el lenguaje de programación o herramientas del mercado. Cualquier lenguaje de programación moderno tiene APIs que ayudan a su generación, sin embargo, en mi experiencia siempre es mejor utilizar las herramientas que los líderes del marcado que ya están disponibles y que por lo general no es necesario programar una sola línea de código para generar y exponer los servicios. Yo te podría recomendar productos como Oracle SOA Suite 12c o Mule ESB, los cuales, para mí, son los mejores del mercado.

Espero que esta breve explicación te sea de utilidad y que te sirva para encaminar tu aprendizaje en Rest, de cualquier forma puedes volver para preguntar cualquier duda.