Tengo una aplicación web que utiliza AJAX para agarrar JSON de datos desde el servidor. Es necesario que el usuario inicie sesión por primera vez en su navegador de forma que, una cookie puede ser establecido. Sólo el GET y POST se utilizan verbos, donde GET es para la recuperación de datos y POST es para cualquier operación que modifica los datos.

De lo que yo entiendo, el RESTO se diferencia del método anterior, en el que la información de autenticación de usuario se envía con cada solicitud y la PUT y DELETE se utilizan verbos como bien.

Mi pregunta es, ¿qué beneficios aporta un DESCANSO de servicio web, a través de los RPC-como método, si el punto final es sólo la intención de ser el navegador de un usuario? Puedo entender cómo el RESTO es beneficioso cuando el cliente es desconocido, pero cuando sólo estoy utilizando ajax de jQuery llamadas, son los beneficios de la pena hacerlo a través de una RPC-como método?

InformationsquelleAutor Daniel T. | 2011-09-14

5 Comentarios

  1. 33

    Una de las grandes diferencias entre el DESCANSO y la RPC es que el RESTO es todo acerca de los recursos, y la RPC es más acerca de las acciones. Por ejemplo, con un verdadero servicio RESTful que nunca llamaría algo así como http://domain.com/service/User/jason/add o http://domain.com/service/User/addUser?username=jason. Con servicio RESTful sólo de referencia de los recursos en la dirección URL y, a continuación, defina qué hacer con ese recurso mediante verbos HTTP y el cuerpo de la solicitud. Así que una petición GET a http:/domain.com/service/jason debe devolver información sobre el recurso (el jason de usuario). Podrías ser más específico y decir http://domain.com/service/user/jason pero el resultado debe ser el mismo. Si la adición de un usuario llamado jason usted podría utilizar la misma URL http://domain.com/service/user/jason pero usaría el verbo y el cuerpo de la solicitud contendrá información adicional. Para eliminar el jason recurso que sería, de nuevo, se utiliza la misma URL (http://domain.com/service/user/jason) y el uso de la eliminación verbo. Para actualizar utilizaría el verbo POST.

    RESTO es genial para el público de la Api que desea para que otros desarrolladores a utilizar. Pueden ser hechos para ser muy estándar, de modo que no requieren de una tonelada de conocimiento ya existente sobre el servicio a utilizar. No WSDL llamadas, etc. Debido a la apatridia puede que también los hace más estables durante el parcial de fallos en la red.

    De lo que usted está describiendo, no creo que usted necesita realmente un servicio RESTful. Pero es posible que desee considerar la posibilidad de, en el futuro, si usted necesita más estándar API. He hecho un servicio REST para un proyecto que sólo utilizo para uso interno, pero eso es porque tengo la intención de acceder a ese servicio de, potencialmente, otras decenas de servicio, y en el futuro, posiblemente, de otros desarrolladores. Así que aunque al principio yo era solo lo utiliza para un par de proyectos, el objetivo final requiere un mayor estándar de interfaz.

    • Desde el RESTO opera en el concepto de los recursos en vez de acciones, ¿cómo se maneja algo así como «el usuario hace clic en un ‘ocultar barra lateral’ enlace, y la aplicación web debe modificar las preferencias en el backend, por lo que está oculto a partir de entonces»?
    • El onyl manera en que yo podía ver el uso de DESCANSO para algo como eso, si desea almacenar un cliente del lado de la representación de el usuario navega por el sitio y mostrar la barra lateral fue una opción de preferencia para el usuario. Cuando se hace clic en «ocultar barra lateral», se establece que la preferencia por el usuario y envía una solicitud POST a la actualización de ese usuario con la nueva preferencia. Pero yo creo que sería un extraño caso de uso. No creo que la mayoría de los desarrolladores sería intentar utilizar el RESTO para que en todos los.
    • Así que en ese caso, probablemente el uso de la RPC método, derecho?
    • Ni siquiera seguro de que yo iba a hacer eso. Yo era un cambio permanente, a continuación, probablemente tendría que. Si fue un cambio temporal, a continuación, probablemente me acaba de uso de JavaScript y no enviar una solicitud para el servidor de todos.
    • En este caso sería un cambio permanente hasta que el usuario elige para volver a mostrarlo.
    • Entonces sí, probablemente me acaba de hacer una simple llamada RPC.
    • Gracias Jason, ha sido muy útil!
    • sería una manera de hacerlo.
    • Asumiendo que usted tiene un /usuarios/nombredeusuario (o /nombre_usuario) «recursos» en la parte final, me gustaría manejar esto con un PUESTO para /usuarios/nombredeusuario/preferencias. Cuando se inicia la aplicación, se iba a LLEGAR a /usuarios/nombredeusuario/preferencias para averiguar cómo configurar sí mismo.
    • eso suena razonable, pero para mi caso de uso, suena como RPC es una mejor solución.
    • Así que después de leer todo esto im todavía un lil confundido. Así que está usted diciendo (de forma simplificada) que la diferencia es que la RPC envía la «llamada de función y parámetros» para el servidor dentro de la URL, pero con el RESTO se utiliza la misma URL y su el servidor del trabajo para «determinar» que la función de llamadas basado en el contenido del cuerpo de la solicitud?
    • Según la dirección URL y el tipo de petición (POST, GET, PUT, etc). Muchas solicitudes no tiene un cuerpo.
    • Su DESCANSO ejemplo de Url debe representar user como en plural: domain.com/service/users/jason
    • > Si la adición de un usuario … tendría que usar la PUT verbo… Para actualizar tendría que usar la POST verbo. < ¿no viceversa?

  2. 6

    Pensar de esta manera — es la función que importa, o de la información que se actuó en?

    Cuando usted está tratando con el RESTO, estás deaing con un estado de información-mira a ver lo que la información actual es (CONSEGUIR), o cambia ese documento específico (POST, DELETE), o crear un nuevo documento (PUT).

    Con RPC, es acerca de los procedimientos /funciones /métodos /operaciones … lo que sea que se les llame en su idioma. La información es sólo algo que se pone operado o devolución de un servicio … pero podría ser uno de muchos. Podríamos estar en busca y devuelve una lista de elementos. O podríamos estar negociando algo donde necesitamos algún tipo de interacción de ida y vuelta. (El RESTO de la negociación para la mayoría de los casos es manejado a través de HTTP, por lo que tiene hacer las cosas con Aceptar y encabezado Accept-Language) Pero se trata de la operación más importante.

    Luego está el tercer tipo, que es el documento/literal de JABÓN … donde es el mensaje de que es importante, y usted tiene que adivinar cuál es la función que se llama está basado en el mensaje. Si usted está tratando con operaciones CRUD, esto es probablemente correcto. Las ventajas sobre el RESTO en este caso es que usted todavía puede tener un WSDL, por lo que usted sabe de antemano cuáles son los elementos necesarios para enviar, y qué esperar en volver.

    De que todo el trabajo … es todo acerca de cómo pensar sobre el problema, y lo fácil que es convertir lo que ya tenemos para exponerlo como una API. Si estás empezando desde cero, es probable que pueda hacer lo que quiera. Personalmente, me gusta el JABÓN (documentos/lit o RPC) en que me puede dar un archivo WSDL que alguien puede usar para arrancar su cliente. He tenido casos en donde la gente estaba haciendo serios consultas dentro de un par de horas. (explicando algunas de las abstracto sutilezas de la API, tales como la diferencia entre el envío de una cadena vacía frente a un null tomó un poco de tiempo, pero yo he tenido los mismos problemas w/DESCANSO)

    • >> o cambia ese documento específico (POST, DELETE), o crear un nuevo documento (PUT) << ¿Es correcto esto? POST se utiliza para crear un nuevo recurso, PUT se utiliza para crear o actualizar.
  3. 4

    RESTO se describe mejor para trabajar con los recursos, en donde el RPC es más acerca de las acciones.

    RESTO:
    representa la Transferencia de Estado Representacional. Es una manera simple de organizar las interacciones entre sistemas independientes.
    Descanso en el uso de aplicaciones de solicitudes HTTP para enviar datos (crear y/o actualizar), lectura de datos (por ejemplo, hacer consultas), y eliminar los datos. Por lo tanto, el RESTO utiliza HTTP para todas las cuatro operaciones CRUD (Crear/Leer/Update/Delete) operaciones.

    RPC:
    RPC es básicamente utilizado para comunicarse a través de los diferentes módulos para servir a las solicitudes del usuario.
    por ejemplo, En openstack como la forma en la que nova, la mirada de neutrones y de trabajo junto al arrancar una máquina virtual.

    RESTO/RPC:

    Como un enfoque de programación, el RESTO es una alternativa ligera a los Servicios Web y la RPC.
    Mucho como Servicios Web, un servicio REST es:

    1. Independiente de la plataforma (no importa si el servidor es Unix, el cliente es un Mac, o cualquier otra cosa),
    2. Independiente del lenguaje (C# puede hablar con Java, etc.),
    3. Basado en estándares (se ejecuta en la parte superior de HTTP), y
    4. Puede utilizarse fácilmente en la presencia de un firewall.
  4. 1

    Estás en lo correcto acerca de DESCANSO de menos junto a el objeto de llamada – si usted está comparando a un servicio web SOAP que requiere un archivo WSDL para ser llamada desde el servidor, que sí, el RESTO de los servicios web son menos unida (es decir, no requieren de conocimientos de la web del servicio antes de llamar). Y la mayoría del tiempo un token debe ser aprobada junto con la solicitud de un determinado ‘representación’.

    No creo que es un gran beneficio mediante RESTO de ajax, de hecho, dependiendo de la API de que se trata, usted puede requerir un token que se pasa como parámetro URI (parámetro querystring), mientras que el uso de un servicio web basado en SOAP, esto no es necesario. En realidad, es muy fácil de combinar servicios web SOAP con las llamadas ajax, pasar los datos en formato JSON y deserializar el JSON en un objeto en el lado del servidor. Y para colmo, jQuery hace que todos los de este super-fácil.

    • Es realmente sólo teóricamente el caso de que la persona necesita menos conocimiento. Con un gran servicio, la cantidad que usted tiene que saber es aproximadamente equivalente (porque las partes duras no son descritos por sea de JABÓN o de DESCANSO, a pesar de WSDL con la adecuada semántica extensiones, posiblemente, podría ser mejor, no de que alguien los molesta con esas cosas).
  5. 1

    odio a romper para todos.
    RPC está haciendo una llamada local, que abstrae la inferior remoto
    comportamiento. y ¿adivinen qué? haciendo el RESTO es la misma cosa.
    el argumento sobre el RESTO es acerca de los recursos es incorrecto, en realidad
    invocar directamente las acciones.

    Reclamo el RESTO a través de HTTP con jsons son una forma de RPC.

    otros populares RPC puede incluir de JABÓN, por ejemplo

    • Esta es la explicación más simple.

Dejar respuesta

Please enter your comment!
Please enter your name here