Para uno todo se trata de semántica, un URI es un Uniforme Recurso Indicador. HTTP proporciona métodos para OBTENER, PUBLICAR, PONER y ELIMINAR un recurso. Los encabezados HTTP especifican en qué formato quiero recibir o enviar la información. Todo esto está disponible fácilmente a través del protocolo HTTP.
De modo que podría volver a utilizar la misma URL que utiliza para la salida HTML para obtener XML, JSON de forma tal que HTTP estaba destinado a ser utilizado.
XML-RPC y SOAP se basan en los métodos de llamada que se describen en un archivo XSD o WSDL, mientras que REST se basa en obtener/modificar recursos. La diferencia es sutil pero aparente. La URL solo describe el recurso y no la acción, como suele ser el caso con SOAP y XML-RPC.
Las ventajas de REST son que puede utilizar verbos HTTP para modificar un recurso como se supone a una llamada a un método que podría llamarse create/new/add, etc. Códigos de estado HTTP significativos en lugar de diferentes tipos de respuestas de error y ser capaz de especificar diferentes formatos en el mismo recurso de forma estándar.
Tampoco tiene que aceptar TODOS los verbos en un recurso REST, por ejemplo, si desea un recurso de solo lectura, simplemente devuelva un código de estado 405 Method Not Allowed en cualquier verbo que no sea GET.
¿Debería volver a hacer sus llamadas RPC a REST? No, no lo creo Los beneficios no superan el tiempo de desarrollo. ¿Deberías aprender REST al configurar un nuevo servicio web? Sí, personalmente creo que sí, consumir un recurso REST se sentirá mucho más natural y puede crecer mucho más rápidamente.
EDITAR
¿Por qué me siento RESTO gana sobre XML-RPC/SOAP es que cuando el desarrollo de sitios Web que ya agregados todos los datos necesaria para utilizar la salida a HTML, también se escribe código para validar cuerpos POST. ¿Por qué debería cambiar a un protocolo diferente solo porque el marcado de transporte cambia?
De esta manera cuando diseña un nuevo sitio web (independiente del idioma) si realmente piensa en los URI como recursos, básicamente utiliza sus URI como llamadas de método con el verbo HTTP prefijando la llamada al método.
Es decir, un GET en/products/12 con un encabezado HTTP Accept: application/json; básicamente (imaginario) se traduce en getProducts(12,MimeType.Json).
Este 'método' a continuación, tiene que hacer un par de cosas
- Comprobar si apoyamos JSON como un tipo MIME. (Solicitud Validar)
- Validar solicitud de datos
- datos agregados para producto 12.
- Formato para JSON y retorno.
Si por alguna razón en los próximos 4 años YAML va a ser la próxima gran moda y una de sus consumidores desea hablar con usted de esa manera este tipo MIME está enchufado mucho más fácil que con la web normal servicios.
Ahora el producto 12 es un recurso en el que probablemente también desee aceptar tipos HTML MIME para mostrar dicho producto, pero para un URI como /product/12/reviews/14/ no necesita una contraparte HTML, solo quiere que sus consumidores puedan publicar en esa URL para actualizar (PUT)/eliminar (DELETE) su propia revisión.
Al pensar en los URI estrictamente como recursos, no solo como una ubicación de una página web, estos recursos a su vez combinados con la solicitud de HTTP para las invocaciones de métodos en el servidor conducen a URL limpias (SEO friendly) y (más importante aún ?) facilidad de desarrollo.
Estoy seguro de que hay marcos en cualquier idioma que automáticamente harán la asignación de URI a invocaciones de métodos para usted. No puedo recomendar ninguno, ya que suelo lanzar el mío.
ASP.NET MVC también funciona con el mismo principio, pero en mi opinión no produce URI RESTful. ASP.NET MVC hace que el verbo sea parte del URI por defecto, y dice que es bueno notar que de ninguna manera ASP.NET MVC fuerza esto (ni nada por el estilo) sobre usted.
Si vas a elegir un marco por lo menos deberían:
- Enlazar URI de los métodos en el servidor
- soporte de objetos a JSON/XML, etc. serialización. Es un dolor si tiene que escribir esto usted mismo, aunque, dependiendo del idioma, no es necesariamente demasiado difícil.
- Exponga algún tipo de tipo de ayuda de solicitud segura para ayudarlo a determinar lo que se solicitó sin analizar manualmente los encabezados HTTP.
No creo que haya mucha diferencia entre REST y cualquier RPC que use HTTP. Probablemente pueda documentar el servicio web en términos de REST si su servicio usa GET y POST de manera similar. Dependerá de qué biblioteca esté utilizando para RPC a través de HTTP. ¿Están todas las solicitudes POST? – Kekoa