Pregunta Transferencia de estado representacional (REST) ​​y Protocolo simple de acceso a objetos (SOAP)


¿Alguien puede explicar lo que es DESCANSO Y lo que es JABÓN ¿en inglés simple? ¿Y cómo funcionan los servicios web?


700
2017-10-16 19:24


origen


Respuestas:


Explicación simple sobre SOAP y REST

SOAP - "Protocolo simple de acceso a objetos"

SOAP es un método para transferir mensajes o pequeñas cantidades de información a través de Internet. Los mensajes SOAP se formatean en XML y generalmente se envían usando HTTP (protocolo de transferencia de hipertexto).


Descanso - Transferencia de estado representacional

El resto es una forma simple de enviar y recibir datos entre el cliente y el servidor, y no tiene muchos estándares definidos. Puede enviar y recibir datos como JSON, XML o incluso texto sin formato. Es ligero comparado con SOAP.


enter image description here


1566
2018-01-24 07:02



Ambos métodos son utilizados por muchos de los jugadores grandes. Es una cuestión de preferencia. Mi preferencia es REST porque es más fácil de usar y entender.

Protocolo simple de acceso a objetos (SOAP):

  • SOAP crea un protocolo XML sobre HTTP o, a veces, TCP / IP.
  • SOAP describe funciones y tipos de datos.
  • SOAP es un sucesor de XML-RPC y es muy similar, pero describe una forma estándar de comunicarse.
  • Varios lenguajes de programación tienen soporte nativo para SOAP, por lo general lo alimenta con una URL de servicio web y puede llamar a sus funciones de servicio web sin la necesidad de un código específico.
  • Los datos binarios que se envían deben codificarse primero en un formato como codificado en base64.
  • Tiene varios protocolos y tecnologías relacionadas: WSDL, XSD, SOAP, WS-Addressing

Transferencia de estado representacional (REST):

  • REST no necesita ser por HTTP, pero la mayoría de mis puntos a continuación tendrán un sesgo HTTP.
  • REST es muy liviano, dice esperar un minuto, no necesitamos toda esta complejidad creada por SOAP.
  • Normalmente utiliza métodos HTTP normales en lugar de un gran formato XML que describe todo. Por ejemplo, para obtener un recurso, utiliza HTTP GET, para poner un recurso en el servidor utiliza HTTP PUT. Para eliminar un recurso en el servidor, utiliza HTTP DELETE.
  • REST es muy simple ya que utiliza los métodos HTTP GET, POST y PUT para actualizar los recursos en el servidor.
  • Por lo general, REST se usa mejor con Arquitectura Orientada a Recursos (ROA). En este modo de pensar, todo es un recurso y operarías con estos recursos.
  • Siempre que su lenguaje de programación tenga una biblioteca HTTP, y la mayoría sí, puede consumir un protocolo REST HTTP muy fácilmente.
  • Los datos binarios o los recursos binarios simplemente se pueden entregar a petición suya.

Existen interminables debates sobre REST contra SOAP en google.

Mi favorito es este. Actualización 27 de noviembre de 2013: el sitio de Paul Prescod parece haberse desconectado y este artículo ya no está disponible, aunque se pueden encontrar copias en Wayback Machine o como un PDF en CiteSeerX.


313
2017-10-16 19:33



DESCANSO

Entiendo que la idea principal de REST es extremadamente simple. Hemos utilizado navegadores web durante años y hemos visto cuán fáciles, flexibles, efectivos son los sitios web. Los sitios HTML usan hipervínculos y formularios como el principal medio de interacción del usuario. Su principal objetivo es permitirnos a nosotros, los clientes, conocer solo aquellos enlaces que puede usar en el estado actual. Y REST simplemente dice '¿por qué no utilizar los mismos principios para conducir la computadora en lugar de los clientes humanos a través de nuestra aplicación?' Combine esto con la potencia de la infraestructura WWW y obtendrá una herramienta arrolladora para la construcción de grandes aplicaciones distribuidas.

Otra posible explicación es para las personas que piensan matemáticamente. Cada aplicación es básicamente una máquina de estado con acciones de lógica de negocios que son transiciones de estado. La idea de REST es asignar cada transición a alguna solicitud a un recurso y proporcionarles a los clientes enlaces que representan las transiciones disponibles en el estado actual. Por lo tanto, modela la máquina de estado a través de representaciones y enlaces. Es por eso que se llama REpresentational State Transfer.

Es bastante sorprendente que todas las respuestas parezcan enfocarse en el formato del mensaje o en el uso de verbos HTTP. De hecho, el formato del mensaje no tiene importancia, REST puede usar cualquiera siempre que el desarrollador del servicio lo documente. Los verbos HTTP solo hacen que un servicio sea un servicio CRUD, pero aún no RESTful. Lo que realmente convierte un servicio en un servicio REST son los hipervínculos (también conocidos como hipermedia controls) integrados en las respuestas del servidor junto con los datos, y su cantidad debe ser suficiente para que cualquier cliente elija la siguiente acción de esos enlaces.

Desafortunadamente, es bastante difícil encontrar la información correcta sobre REST en la Web, a excepción de la La tesis de Roy Fielding. (Él es quien sacó REST). Yo recomendaría el Libro 'REST in Practice' ya que ofrece un completo tutorial paso a paso sobre cómo evolucionar de SOAP a REST.

JABÓN

Esta es una de las formas posibles de estilo de arquitectura RPC (llamada a procedimiento remoto). En esencia, es solo una tecnología que permite a los clientes llamar a los métodos del servidor a través de los límites del servicio (red, procesos, etc.) como si estuvieran llamando a métodos locales. Por supuesto, en realidad difiere de llamar a los métodos locales en velocidad, fiabilidad, etc., pero la idea es así de simple.

Comparado

Los detalles como protocolos de transporte, formatos de mensaje, xsd, wsdl, etc. no importan al comparar cualquier forma de RPC con REST. La principal diferencia es que un servicio RPC reinventa la bicicleta diseñando su propio protocolo de aplicación en la API RPC con la semántica que solo él conoce. Por lo tanto, todos los clientes deben comprender este protocolo antes de usar el servicio, y no se puede construir una infraestructura genérica como cachés debido a la semántica propia de todas las solicitudes. Además, las API de RPC no sugieren qué acciones están permitidas en el estado actual, esto tiene que derivarse de la documentación adicional. REST por otro lado implica el uso de interfaces uniformes para permitir que varios clientes comprendan la semántica API y los controles hipermedia (enlaces) para resaltar las opciones disponibles en cada estado. Por lo tanto, permite almacenar en caché las respuestas para escalar los servicios y hacer que el uso correcto de la API sea fácilmente detectable sin documentación adicional.

En cierto modo, SOAP (como cualquier otro RPC) es un intento de pasar por un límite de servicio que trata los medios de conexión como un recuadro negro que solo puede transmitir mensajes. REST es una decisión para reconocer que la Web es un gran sistema de información distribuida, para aceptar el mundo tal como es y aprender a dominarlo en lugar de luchar contra él.

SOAP parece ser ideal para API de red internas, cuando controla tanto el servidor como los clientes, y aunque las interacciones no son demasiado complejas. Es más natural para los desarrolladores usarlo. Sin embargo, para una API pública que es utilizada por muchas partes independientes, es compleja y grande, REST debería ajustarse mejor. Pero esta última comparación es muy borrosa.

Actualizar

Mi experiencia ha demostrado inesperadamente que el desarrollo de REST es más difícil que SOAP. Al menos para .NET. Si bien existen grandes frameworks como ASP.NET Web API, no hay herramientas que generen automáticamente un proxy del lado del cliente. No hay nada como 'Agregar referencia de servicio web' o 'Agregar referencia de servicio WCF'. Uno tiene que escribir todos los códigos de serialización y consulta de servicio a mano. Y hombre, eso es un montón de código repetitivo. Creo que el desarrollo de REST necesita algo similar a WSDL y la implementación de herramientas para cada plataforma de desarrollo. De hecho, parece haber una buena base: WADL o WSDL 2.0, pero ninguno de los estándares parece estar bien respaldado.

Actualización (enero de 2016)

Resulta que ahora hay un amplia variedad de herramientas para la definición de API REST. Mi preferencia personal es actualmente RAML.

Cómo funcionan los servicios web

Bueno, esta es una pregunta demasiado amplia, ya que depende de la arquitectura y la tecnología utilizada en el servicio web específico. Pero, en general, un servicio web es simplemente una aplicación en la Web que puede aceptar solicitudes de clientes y respuestas de devolución. Está expuesto a la Web, por lo tanto es un web servicio, y generalmente está disponible 24/7, es por eso que es un Servicio. Por supuesto, resuelve algunos problemas (de lo contrario, ¿por qué alguien usaría un servicio web?) Para sus clientes.


239
2017-09-19 18:41



Esta es la explicación más simple que encontrarás.

Este artículo lleva a marido a esposa narrativa, donde el marido le explica a su esposa sobre REST, en términos puramente legos. ¡Debe leer!

how-i-explained-rest-to-my-wife (enlace original)
how-i-explained-rest-to-my-wife (2013-07-19 enlace de trabajo)


38
2017-07-13 07:33



SOAP - Protocolo simple de acceso a objetos es un protocolo!

RESTO - Transferencia de estado representacional es un estilo arquitectónico!

SOAP es un protocolo XML utilizado para transferir mensajes, generalmente a través de HTTP

REST y SOAP son discutiblemente  no mutuamente excluyentes. Una arquitectura RESTful podría usar HTTP o SOAP o algún otro protocolo de comunicación. REST está optimizado para la web y por lo tanto HTTP es una elección perfecta HTTP es también el solamente protocolo discutido en el artículo de Roy Fielding.

Aunque REST y SOAP son claramente muy diferentes, la pregunta ilumina el hecho de que REST y HTTP a menudo se usan en tándem. Esto se debe principalmente a la simplicidad de HTTP y su mapeo muy natural a los principios RESTful.

Principios fundamentales de REST

Comunicación cliente-servidor

Las arquitecturas cliente-servidor tienen una separación muy clara de preocupaciones. Todas las aplicaciones integradas en el estilo RESTful también deben ser cliente-servidor en princple.

Apátrida

Cada solicitud de cada cliente al servidor requiere que su estado esté completamente representado. El servidor debe ser capaz de comprender completamente la solicitud del cliente sin utilizar ningún contexto de servidor o estado de sesión del servidor. Se deduce que todo estado debe mantenerse en el cliente. Discutiremos la representación apátrida en más detalle más adelante.

Cacheable

Se pueden usar restricciones de caché, lo que permite que los datos de respuesta se marquen como caché o no de caché. Cualquier información marcada como almacenable en caché puede reutilizarse como respuesta a la misma solicitud posterior.

Interfaz uniforme

Todos los componentes deben interactuar a través de una única interfaz uniforme. Debido a que la interacción de todos los componentes se produce a través de esta interfaz, la interacción con diferentes servicios es muy simple. La interfaz es la misma! Esto también significa que los cambios de implementación pueden realizarse de forma aislada. Tales cambios no afectarán la interacción de los componentes fundamentales porque la interfaz uniforme siempre se mantiene. Una desventaja es que estás atascado con la interfaz. Si se puede proporcionar una optimización a un servicio específico cambiando la interfaz, no tiene suerte ya que REST lo prohíbe. Sin embargo, el lado positivo es que REST está optimizado para la Web, ¡y por lo tanto, la popularidad de REST sobre HTTP es increíble!

Los conceptos anteriores representan características definitorias de REST y diferencian la arquitectura REST de otras arquitecturas como los servicios web. Es útil tener en cuenta que un servicio REST es un servicio web, pero un servicio web no es necesariamente un servicio REST.

Ver este blog enviar en REST Design Principals para más detalles sobre DESCANSO y las balas indicadas anteriormente.


36
2018-03-14 20:28



Me gusta la respuesta de Brian R. Bondy. Solo quería agregar que Wikipedia proporciona una descripción clara de DESCANSO. El artículo lo distingue de SOAP.

REST es un intercambio de información de estado, hecho de la manera más simple posible.

SOAP es un protocolo de mensajes que usa XML.

Una de las razones principales por las que muchas personas han pasado de SOAP a REST es que los estándares WS- * (denominados WS splat) asociados con los servicios web basados ​​en SOAP son EXTREMADAMENTE complicados. Ver wikipedia para obtener una lista de las especificaciones. Cada una de estas especificaciones es muy complicada.

EDITAR: por alguna razón, los enlaces no se muestran correctamente. REST = http://en.wikipedia.org/wiki/REST

WS- * = http://en.wikipedia.org/wiki/WS-*


12
2017-10-16 19:47



Tanto los servicios web SOAP como los servicios web REST pueden usar el protocolo HTTP y otros protocolos también (solo para mencionar que SOAP puede ser el protocolo subyacente de REST). Hablaré solo sobre el protocolo HTTP relacionado con SOAP y REST, porque este es el uso más frecuente de ellos.

JABÓN

JABÓN (protocolo de acceso a objetos "simple") es un protocolo (y un Estándar W3C) Define cómo crear, enviar y procesar mensajes SOAP.

  • Los mensajes SOAP son documentos XML con una estructura específica: contienen un sobre que contiene el encabezado y la sección del cuerpo. El cuerpo contiene los datos reales, queremos enviar, en formato XML. Existen dos estilos de codificación, pero usualmente elegimos literal, lo que significa que nuestra aplicación o su controlador SOAP realiza la serialización XML y la desserialización de los datos.

  • Los mensajes SOAP viajan como mensajes HTTP con el subtipo MIME SOAP + XML. Estos mensajes HTTP pueden ser multiparte, por lo que, opcionalmente, podemos adjuntar archivos a mensajes SOAP.

  • Obviamente, utilizamos una arquitectura cliente-servidor, por lo que los clientes SOAP envían solicitudes a las webserices de SOAP y los servicios envían respuestas a los clientes. La mayoría de los servicios web usan un archivo WSDL para describir el servicio. El archivo WSDL contiene el esquema XML (XSD en adelante) de los datos que queremos enviar y el enlace WSDL que define cómo el servicio web está vinculado al protocolo HTTP. Existen dos estilos vinculantes: RPC y documento. Mediante el enlace de estilo RPC, el cuerpo SOAP contiene la representación de una llamada de operación con los parámetros (solicitudes HTTP) o los valores de retorno (respuesta HTTP). Los parámetros y valores devueltos se validan contra el XSD. Según el estilo del documento, el enlace del cuerpo SOAP contiene un documento XML que se valida con el XSD. Creo que el estilo de encuadernación de documentos se adapta mejor a los sistemas basados ​​en eventos, pero nunca usé ese estilo de encuadernación. El estilo de enlace de RPC es más frecuente, por lo que la mayoría de las personas utilizan SOAP para fines de XML / RPC mediante aplicaciones distribuidas. Los servicios web usualmente se encuentran preguntando UDDI servidor. Los servidores UDDI son registros que almacenan la ubicación de los servicios web.

SOAP RPC

Así que, en mi opinión, el servicio web SOAP más frecuente utiliza el estilo de encuadernación RPC y el estilo de codificación literal, y tiene las siguientes propiedades:

  • Mapas de URL a las operaciones.
  • Envía mensajes con el subtipo MIME SOAP + XML.
  • Puede tener un almacén de sesión del lado del servidor, no hay restricciones al respecto.
  • Los controladores del cliente SOAP usan el archivo WSDL del servicio para convertir las operaciones RPC en métodos. La aplicación del lado del cliente se comunica con el servicio web SOAP llamando a estos métodos. Por lo tanto, la mayoría de los clientes SOAP se rompen por cambios de interfaz (resultando en nombres de métodos y / o cambios de parámetros).
  • Es posible escribir clientes SOAP que no se rompan mediante cambios de interfaz utilizando RDF y encontrar operaciones por semántica, pero servicio web semántico son muy raros y no necesariamente tienen un cliente sin interrupción (supongo).

DESCANSO

REST (transferencia de estado representativo) es un estilo de arquitectura que se describe en disertación de Roy Fielding. No le preocupan los protocolos como SOAP. Comienza con un estilo de arquitectura nulo que no tiene restricciones y define las restricciones de la arquitectura REST una a una. La gente usa el término RESTful para los servicios web que cumplen con todas las restricciones de REST, pero según Roy Fielding, no hay cosas como Niveles REST. Cuando un servicio web no cumple con cada restricción REST, entonces no es un servicio web REST.

Restricciones REST

  • Cliente - arquitectura del servidor: creo que esta parte es familiar para todos. Los clientes REST se comunican con los servicios web REST, los servicios web mantienen el estado de recursos de datos común a partir de ahora y lo sirven a los clientes.
  • Sin estado: la parte de "transferencia de estado" de la abreviatura: REST. Los clientes mantienen el estado del cliente (estado de sesión / aplicación), por lo que los servicios no deben tener un almacenamiento de sesión. Los clientes transfieren la parte relevante del estado del cliente por cada solicitud a los servicios que responden con la parte relevante del estado del recurso (mantenido por ellos). Entonces, las solicitudes no tienen contexto, siempre contienen la información necesaria para procesarlas. Por ejemplo, mediante la autenticación básica de HTTP, el nombre de usuario y la contraseña son almacenados por el cliente y los envía con cada solicitud, por lo que la autenticación se realiza con cada solicitud. Esto es muy diferente de las aplicaciones web habituales en las que la autenticación solo se produce al iniciar sesión. Podemos utilizar cualquier mecanismo de almacenamiento de datos del lado del cliente, como in-memory (javascript), cookies, localStorage, y así sucesivamente ... para conservar algunas partes del estado del cliente si así lo queremos. La razón de la restricción de apatridia es que el servidor escala bien, incluso con una carga muy alta (millones de usuarios), cuando no tiene que mantener la sesión de cada cliente.
  • Caché: la respuesta debe contener información que el cliente puede almacenar en caché o no. Esto mejora la escalabilidad aún más.
  • Interfaz uniforme

    • Identificación de recursos: el recurso REST es el mismo que RDF recurso. Según Fielding, si puede nombrar algo, puede ser un recurso, por ejemplo: "el clima local actual" puede ser un recurso, o "su teléfono móvil" puede ser un recurso, o "un documento web específico" puede ser un recurso. un recurso. Para identificar un recurso puede usar identificadores de recursos: URL y URN (por ejemplo Número de ISBN por libros) Un único identificador debe pertenecer solo a un recurso específico, pero un solo recurso puede tener muchos identificadores, que con frecuencia explotamos, por ejemplo, mediante paginación con URL como https://example.com/api/v1/users?offset=50&count=25. Las URL tienen algunos presupuesto, por ejemplo, las URL con los mismos parámetros, pero las consultas diferentes no son idénticas, o la parte de la ruta debe contener los datos jerárquicos de la URL y la parte de la consulta debe contener los datos no jerárquicos. Estos son los conceptos básicos de cómo crear URL por REST. Por cierto. la estructura de la URL importa solo para los desarrolladores de servicios, un cliente REST real no se preocupa por ella. Otra pregunta frecuente es el control de versiones API, que es fácil, porque de acuerdo con Fielding, la única constante por recurso es la semántica. Si la semántica cambia, puede agregar un nuevo número de versión. Puedes usar clásico 3 versiones de número y agregue solo el número principal a las URL (https://example.com/api/v1/) Por lo tanto, mediante cambios compatibles con versiones anteriores no ocurre nada; mediante cambios no compatibles con versiones anteriores tendrá una semántica no compatible con versiones anteriores con una nueva raíz API https://example.com/api/v2/. Entonces los viejos clientes no se romperán, porque pueden usar el https://example.com/api/v1/ con la vieja semántica.
    • Manipulación de recursos mediante representaciones: puede manipular los datos relacionados con los recursos (estado de recursos) enviando la representación prevista de los recursos (junto con el método HTTP y el identificador de recursos) al servicio REST. Por ejemplo, si desea cambiar el nombre de un usuario después del matrimonio, puede enviar un PATCH https://example.com/api/v1/users/1 {name: "Mrs Smith"} solicitud donde el {name: "Mrs Smith"} es una representación JSON del estado de recursos previsto, en otras palabras: el nuevo nombre. Esto sucede vica-versa, el servicio envía representaciones de recursos a los clientes para cambiar sus estados. Por ejemplo, si queremos leer el nuevo nombre, podemos enviar un GET https://example.com/api/v1/users/1?fields="name" solicitud de recuperación, que da como resultado un 200 ok, {name: "Mrs Smith"} respuesta. Entonces, podemos usar esta representación para cambiar el estado del cliente, por ejemplo, podemos mostrar "¡Bienvenido a nuestra página, Sra. Smith!" mensaje. Un recurso puede tener muchas representaciones según el identificador de recurso (URL) o el accept encabezado que enviamos con la solicitud. Por ejemplo, podemos enviar una imagen de la Sra. Smith (probablemente no desnuda) si image/jpeg es solicitado.
    • Mensajes autodescriptivos: los mensajes deben contener información sobre cómo procesarlos. Por ejemplo, método URI y HTTP, encabezado de tipo de contenido, encabezados de caché, RDF que describe el significado de los datos, etc. Es importante usar métodos estándar. Es importante saber el especificación de los métodos HTTP. Por ejemplo, GET significa recuperar información identificada por la URL de solicitud, DELETE significa pedirle al servidor que elimine el recurso identificado por la URL dada, y así sucesivamente ... Los códigos de estado HTTP tienen una especificación también, por ejemplo 200 significa éxito, 201 significa que se ha creado un nuevo recurso, 404 significa que el recurso solicitado no se encontró en el servidor, etc. ... El uso de estándares existentes es una parte importante de REST.
    • Hipermedia como motor del estado de la aplicación (HATEOAS en lo sucesivo): Hypermedia es un tipo de medio que puede contener hipervínculos. A través de la web, seguimos los enlaces, descritos por un formato hipermedia (generalmente HTML), para lograr un objetivo, en lugar de escribir las URL en la barra de direcciones. REST sigue el mismo concepto, las representaciones enviadas por el servicio pueden contener hipervínculos. Utilizamos estos hipervínculos para enviar solicitudes al servicio. Con la respuesta obtenemos datos (y probablemente más enlaces) que podemos utilizar para construir el nuevo estado del cliente, y así sucesivamente ... Así que es por eso que hipermedia es el motor del estado de la aplicación (estado del cliente). Probablemente se pregunte ¿cómo reconocen y siguen los hipervínculos los clientes? Para los humanos es bastante simple, leemos el título del enlace, tal vez rellenamos los campos de entrada, y luego solo un clic. Por máquinas tenemos que agregar semántica a los enlaces con RDF (por JSON-LD con Hidra) o con soluciones específicas de hipermedios (por ejemplo Relaciones de enlace IANA y tipos MIME específicos del proveedor por HAL + JSON) Hay muchos legibles por máquina XML y Formatos JSON hipermedia, solo una breve lista de ellos:

      A veces es difícil elegir ...

  • Sistema de capas: podemos usar capas múltiples entre los clientes y los servicios. Ninguno de ellos debería saber sobre todas estas capas adicionales, solo de capa al lado. Estas capas pueden mejorar la escalabilidad mediante la aplicación de cachés y equilibrio de carga, o pueden aplicar políticas de seguridad.
  • Código bajo demanda: podemos enviar un código que extiende la funcionalidad del cliente, por ejemplo, código JavaScript a un navegador. Esta es la única restricción opcional de REST.

Servicio web REST - diferencias SOAP RPC webservice

Por lo tanto, un servicio web REST es muy diferente de un servicio web SOAP (con estilo de enlace RPC y estilo de codificación literal)

  • Define una interfaz uniforme (intead de un protocolo).
  • Asigna URL a los recursos (y no a las operaciones).
  • Envía mensajes con cualquier tipo de MIME (en lugar de solo SOAP + XML).
  • Tiene una comunicación sin estado, por lo que no puede tener un almacenamiento de sesión del lado del servidor. (SOAP no tiene restricciones sobre esto)
  • Sirve hipermedia y los clientes usan enlaces contenidos en ese hipermedia para solicitar el servicio. (SOAP RPC utiliza enlaces de operación descritos en el archivo WSDL)
  • No se divide por cambios de URL solo mediante cambios semánticos. (Los clientes SOAP RPC sin utilizar la semántica RDF se rompen por los cambios en el archivo WSDL).
  • Se escala mejor que un servicio web SOAP debido a su comportamiento sin estado.

y así...

Un servicio web SOAP RPC no cumple con todas las restricciones REST:

  • arquitectura cliente-servidor - siempre
  • sin estado - posible
  • caché - posible
  • interfaz uniforme, nunca
  • sistema de capas - Nunca
  • código bajo demanda (opcional) - posible

7
2017-09-07 03:42



Bueno, comenzaré con la segunda pregunta: ¿Qué son los servicios web? , por obvias razones.

Los WebServices son esencialmente piezas de lógica (a las que puede referirse vagamente como un método) que exponen ciertas funciones o datos. El cliente implementando (técnicamente hablando, consumidor es la palabra) solo necesita saber cuales son los parametros método va a aceptar y el tipo de datos que va a devolver (si es que lo hace).

El seguimiento Enlazar lo dice todo sobre DESCANSO & JABÓN de una manera extremadamente lúcida.

RESTO vs SOAP

Si también quieres saber cuándo elegir qué (REST o SOAP), ¡razón de más para pasar por esto!


6
2017-10-11 07:39