Debería RESTify mis llamadas RPC a través de HTTP?

Question

Tenemos HTTP servicios web que son RPC. Vuelven XML que representa el objeto del bien recuperado o creado. Quiero saber las ventajas (si lo hay) de "restifying" los servicios.

• http://www.example.com/createDoodad
• http://www.example.com/getDoodad?id=13
• http://www.example.com/getWidget?id1=11&id2=45
• http://www.example.com/createWidget
• http://www.example.com/createSprocked

Una cosa que veo es que no necesitamos representaciones para cada recurso y no necesitamos para apoyar todas las operaciones (GET, PUT, POST, DELETE) sobre todos los recursos tampoco. Básicamente mi pregunta es la siguiente.

convencerme de que debo utilizar los servicios de descanso en lugar de RPC a través de HTTP y lo volvería a aquellos servicios de descanso debería ser?

Answer 1

Por un lado se trata de la semántica, un URI es un uniforme web Indicador. HTTP proporciona métodos para GET, POST, PUT y DELETE un recurso. cabeceras HTTP especifican en qué formato Quiero recibir o enviar la información. Esto es todos fácilmente disponibles a través del protocolo HTTP.

Por lo que podría volver a utilizar la misma URL que utiliza para la salida HTML para obtener XML, JSON de una manera que HTTP estaba destinado a ser utilizado.

XML-RPC y Jabón se basa en llamar a los métodos que se describen mediante un archivo XSD o WSDL mientras RESTO se basa en conseguir / modificar los recursos. La diferencia es sutil pero evidente. La URL describe únicamente el recurso y no la acción como es a menudo el caso de SOAP y XML-RPC.

Los beneficios del resto son que se puede utilizar verbos HTTP para modificar un recurso como se supone que una llamada al método que podría ser nombrado crear / nueva / añadir, etc códigos de estado HTTP claras en vez de diferentes tipos de respuestas de error y poder para especificar diferentes formatos en el mismo recurso de una manera estándar.

También no tiene que aceptar todos los verbos en un recurso REST, por ejemplo, si usted quiere un recurso de sólo lectura simplemente devuelve un código de estado 405 Method Not Allowed en cualquier verbo que no se consigue.

En caso de que de nuevo su llamadas RPC para descansar? No, no lo creo. Los beneficios no son mayores que el tiempo de desarrollo. En caso de que aprender RESTO cuando la creación de un nuevo servicio web? Sí, yo personalmente creo que sí, que consume 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é debe cambiar a un protocolo diferente sólo porque el cambio de marcado transporte?

De esta manera cuando el diseño de un nuevo sitio web (lenguaje agnóstico) si realmente piensa de URI de los recursos que, básicamente, utiliza sus URI como método llama con el verbo HTTP anteponiendo la llamada al método.

Es decir, un GET en / productos / 12 con un encabezado HTTP Accept: application/json; básicamente (imaginarios) se traduce a getProducts(12,MimeType.Json).

Este 'método' entonces tiene que hacer un par de cosas

1. Comprobar si apoyamos JSON como un tipo MIME. (Solicitud Validar)
2. Validar datos de la solicitud
3. Los datos agregados para producto 12.
4. Formato a 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 deseos de hablar con usted de esa manera este tipo MIME está enchufado mucho más fácil que con los servicios web regulares.

Ahora el producto 12 es un recurso que muy probablemente también desea aceptar los tipos MIME HTML en la pantalla de dicho producto, pero para un URI como /product/12/reviews/14/ que no necesita una contraparte HTML, lo que desea que sus consumidores puedan para colocar a esa URL para actualizar (PUT) / borrar (DELETE) su propia opinión.

En el pensamiento de URIs estrictamente como recursos, no sólo un lugar de una página web, y estos recursos a su vez se combina con la petición HTTP a invocaciones de métodos en el servidor lleva a limpiar URL (SEO) y (lo más importante? ) facilidad de desarrollo.

Estoy seguro de que hay marcos en cualquier idioma que va a hacer de forma automática el mapeo de los URI de invocaciones de métodos para usted. No puedo recomendar uno ya que normalmente Estirar la mía.

ASP.NET MVC también trabaja en el mismo principio, pero en mi opinión no produce URI RESTful. ASP.NET MVC hace que la parte verbal de la URI por defecto una vez dicho que es bueno tener en cuenta que de ninguna manera obliga ASP.NET MVC esto (o lo que fuera) sobre ti.

Si vas a elegir un marco por lo menos deberían:

1. enlazar URI a la metanfetaminaSAO en el servidor
2. Soporte de objetos para JSON / XML, etc. serialización. Es un dolor si usted tiene que escribir esto por sí mismo, aunque, depende del lenguaje, no lo necesite demasiado difícil.
3. Exponer una especie de tipo de solicitud ayudantes de seguridad para ayudarle a determinar lo que se solicitó sin necesidad de analizar las cabeceras HTTP de forma manual.

Answer 2

Trate de tomar los verbos de sus URL:

• http://www.example.com/Doodad
• http://www.example.com/Doodad/13
• http://www.example.com/Widget/11/45
• http://www.example.com/Widget
• http://www.example.com/Sprocked

Answer 3

Las cadenas de consulta no se deben utilizar para acceder a un recurso de una manera jerárquica, no consulta. Las cadenas de consulta suelen ser ignorados cuando el almacenamiento en caché, lo cual es peligroso y lento.