jquery - servicio - web service soap vs rest

¿Qué diferencia a un servicio web REST de uno similar a RPC? (5)

Tengo una aplicación web que utiliza AJAX para capturar datos JSON del servidor. Requiere que el usuario primero inicie sesión con su navegador para que se pueda configurar una cookie. Solo se utilizan los verbos GET y POST , donde GET es para recuperar datos y POST es para cualquier operación que modifique datos.

Por lo que entiendo, REST se diferencia del método anterior en que la información de autenticación del usuario se envía con cada solicitud y también se usan los verbos PUT y DELETE .

Mi pregunta es, ¿qué beneficios tiene un servicio web REST sobre el método similar a RPC, si el punto final solo pretende ser el navegador de un usuario? Puedo entender cómo REST es beneficioso cuando el cliente es desconocido, pero cuando solo uso las llamadas ajax de jQuery, ¿valen la pena los beneficios sobre un método similar a RPC?

Odio decírtelo a todos ustedes. RPC está realizando una llamada local, que abstrae el comportamiento remoto subyacente. ¿y adivina qué? hacer REST es lo mismo. El argumento sobre REST es sobre recursos es incorrecto, en realidad invoca acciones directamente.

Reclamo que REST sobre HTTP con jsons es una forma de RPC.

otro RPC popular puede incluir SOAP, por ejemplo

Piénselo de esta manera: ¿es la función lo que importa o la información sobre la que se está actuando?

Cuando se trata de REST, se está desactivando con un estado de información: se ve para ver cuál es la información actual (GET), se modifica ese documento específico (POST, DELETE) o se crea un nuevo documento. (PONER).

Con RPC, se trata de los procedimientos / función / métodos / operaciones ... como se llame en su idioma. La información es solo algo que se opera o se devuelve de un servicio ... pero puede ser uno de muchos. Podríamos estar buscando y devolviendo una lista de elementos. O podríamos estar negociando algo donde necesitamos una interacción de ida y vuelta. (La negociación de REST en su mayor parte se maneja a través de HTTP, por lo que tiene que hacer las cosas con el encabezado Aceptar y Aceptar Lenguaje) Pero lo que es más importante es la operación.

Luego está el tercer tipo, que es el documento / SOAP literal ... donde el mensaje es importante, y usted tiene que adivinar qué función se llama en función del mensaje. Si solo estás tratando con operaciones de CRUD, esto probablemente está bien. Las ventajas sobre REST en este caso es que aún puede tener un WSDL, por lo que sabe de antemano cuáles son los elementos necesarios para enviar y qué esperar a cambio.

Todos funcionan ... se trata principalmente de cómo piensas sobre el problema, y de lo fácil que es convertir lo que ya tienes para exponerlo como una API. Si estás empezando desde cero, es probable que puedas hacer lo que quieras. Personalmente, me gusta SOAP (ya sea documento / litro o RPC) porque puedo proporcionar un archivo WSDL que alguien puede usar para iniciar a su cliente. He tenido casos en los que las personas hacían consultas serias en un par de horas. (Explicar algunas de las sutilezas abstractas de la API, como la diferencia entre enviar una cadena vacía frente a una nula tomó algún tiempo, pero habría tenido los mismos problemas con REST)

Tiene razón acerca de que REST está menos acoplado al objeto llamante: si se compara con un servicio web SOAP que requiere que se llame un archivo WSDL desde el servidor, entonces los servicios web REST están menos acoplados (es decir, no requieren conocimiento de la servicio web antes de llamarlo). Y la mayoría de las veces es necesario pasar un token junto con la solicitud de una ''representación'' determinada.

No creo que haya un gran beneficio al usar REST de ajax, de hecho, dependiendo de la API con la que esté trabajando, puede necesitar un token que se pasa como parámetro URI (parámetro de cadena de consulta) al usar una web basada en SOAP Servicio, esto no es necesario. En realidad, es bastante fácil combinar los servicios web SOAP con llamadas ajax, pasar sus datos en formato JSON y deserializar JSON en un objeto en el lado del servidor. Y para colmo, jQuery hace que todo esto sea muy fácil.

Una de las grandes diferencias entre REST y RPC es que REST se trata de recursos, y RPC es más acerca de las acciones. Por ejemplo, con un servicio realmente RESTful nunca llamaría algo como http://domain.com/service/User/jason/add o http://domain.com/service/User/addUser?username=jason . Con el servicio REST, solo hace referencia al recurso en la URL y luego define qué hacer con ese recurso usando verbos HTTP y el cuerpo de la solicitud. Por lo tanto, una solicitud GET para http: /domain.com/service/jason debe devolver información sobre el recurso (el usuario jason). Podría ser más específico y decir http://domain.com/service/user/jason pero el resultado debería ser el mismo. Si estuviera agregando un usuario llamado jason, usaría exactamente la misma URL http://domain.com/service/user/jason pero usaría el verbo PUT y el cuerpo de la solicitud contendría datos adicionales. Para eliminar el recurso jason, nuevamente usaría exactamente la misma URL ( http://domain.com/service/user/jason ) y use el verbo DELETE. Para actualizar usarías el verbo POST.

REST es ideal para las API de cara al público que pretende que utilicen otros desarrolladores. Se pueden hacer que sean muy estándar para que no requieran un montón de conocimiento preexistente sobre el servicio a utilizar. No hay llamadas WSDL, etc. Debido a la falta de estado, también puede hacerlas más estables durante fallas parciales de la red.

Por lo que está describiendo, no creo que necesite un servicio verdaderamente RESTful. Pero es posible que desee considerar, en el futuro, si alguna vez necesitaría una API más estándar. Hice un servicio REST para un proyecto que solo uso para uso interno, pero eso se debe a que tenía la intención de acceder a ese servicio desde, potencialmente, docenas de otros servicios, y en el futuro posiblemente de otros desarrolladores. Entonces, aunque al principio solo lo estaba usando para un par de proyectos, el objetivo final requería una interfaz más estándar.

REST se describe mejor para trabajar con los recursos, donde RPC tiene más información sobre las acciones.

RESTO: significa transferencia estatal representativa. Es una forma sencilla de organizar las interacciones entre sistemas independientes. Las aplicaciones RESTful utilizan solicitudes HTTP para publicar datos (crear y / o actualizar), leer datos (por ejemplo, hacer consultas) y eliminar datos. Por lo tanto, REST utiliza HTTP para las cuatro operaciones CRUD (Crear / Leer / Actualizar / Eliminar).

RPC: RPC se utiliza básicamente para comunicarse a través de los diferentes módulos para atender las solicitudes de los usuarios. por ejemplo, en openstack como nova, vistazo y neutrón trabajan juntos al arrancar una máquina virtual.

REST / RPC:

Como enfoque de programación, REST es una alternativa ligera a los servicios web y RPC. Al igual que los servicios web, un servicio REST es:

Independiente de la plataforma (no le importa si el servidor es Unix, el cliente es una Mac o cualquier otra cosa),
Independiente del lenguaje (C # puede hablar con Java, etc.),
Basado en estándares (se ejecuta sobre HTTP), y
Se puede usar fácilmente en presencia de cortafuegos.