usar tipos services saber restful qué otro mejor ejemplos cuando como web-services soap rest

web-services - tipos - web service soap y restful



¿Por qué el servicio web basado en SOAP no es RESTful? (7)

Protocolo SOAP: SOAP es un protocolo que significa que tiene una estructura definida.

  1. POST: la solicitud SOAP siempre requiere un cuerpo HTTP, por lo tanto, el método HTTP es POST. Más acerca de los métodos HTTP en un futuro POST (estos son muy relevantes en REST), pero por ahora supongamos que esto siempre es POST en caso de SOAP
  2. Acción SOAP: vacío significa, intención en el URI de solicitud HTTP.
  3. Content-Type: SOAP usa XML como el lenguaje para la comunicación y por lo tanto, esto siempre es texto / xml
  4. con el espacio de nombres XML (xmlns) es necesario para indicar que se trata de una solicitud SOAP.
  5. es el elemento raíz SOAP que describe la Solicitud y la Respuesta.

El diseño RESTful API implica romper el sistema en términos de recursos y proporcionar acceso a esos recursos a través de puntos finales (también llamados operaciones) definidos en los uris base del servicio web. El acceso se realiza utilizando métodos HTTP estándar y controlado por un mecanismo de autenticación. La configuración del recurso se proporciona y se obtiene mediante solicitud y respuesta con códigos de estado HTTP que comunican el estado. 1. Los recursos son las entidades que existen en el sistema que se hace RESTful. Por ejemplo, en el caso de un sitio web de blogs, estos pueden ser los blogs, publicaciones y comentarios. 2. Los EndPoints u operaciones proporcionan un mecanismo a través del cual se puede acceder a estos recursos. Por ejemplo, el punto final para enumerar todas las publicaciones de blog en un blog en particular sería un GET en / blogs / {blogId} / posts. 3. Los URI de base definen la ubicación del uri web donde los recursos están disponibles a través de los puntos finales. Para tomar un ejemplo real, para el blogger de Google, el base_uri es https://www.googleapis.com/blogger/v3 . 4. HTTP Methods es donde reside la simplicidad de REST. En el diseño RESTful API, las operaciones en los recursos se realizan a través de los métodos HTTP estándar, principalmente GET, POST, PUT y DELETE. Otros métodos HTTP: OPTIONS, HEAD, PATCH también se usan en algunos casos.

Entiendo que RESTful es un estilo de arquitectura, pero ¿qué hace exactamente que el servicio web basado en SOAP no cuente para RESTful?

No tengo claro qué puntos a continuación (de Wikipedia ) no están conformados por SOAP.

  1. Servidor de cliente
  2. Apátrida
  3. Cacheable
  4. Sistema de capas
  5. Código bajo demanda (opcional)
  6. Interfaz uniforme
    • Identificación de recursos
    • Manipulación de recursos a través de estas representaciones
    • Mensajes autodescriptivos
    • Hipermedia como el motor del estado de la aplicación

EDITAR : Acabo de encontrar this que lo resume bastante bien.

REST no es RPC, dice RPC, "define algunos métodos que hacen algo", mientras que REST dice, "define algunos recursos y ellos tendrán estos métodos". Es una diferencia sutil pero vital, cuando se le administra un URI, cualquiera sabe que puede interactuar con él a través del conjunto predefinido de métodos y recibir a cambio respuestas HTTP estándar. Así que dado http://www.peej.co.uk/ Sé que puedo emitir un GET en él y recibir algo significativo de nuevo. Luego puedo probar con PUT para cambiarlo y recibir un código de error HTTP significativo, ya que no estoy autorizado a inmiscuirme.

REST se ajusta a nada más que el protocolo http.

RESTO y SOAP no son conceptos equivalentes.

DESCANSO:

  • Depende de un protocolo de transporte (HTTP).
  • Aprovecha al máximo las características específicas de ese protocolo (verbos GET, POST, PUT, DELETE, almacenamiento en caché, encabezados y códigos de error predefinidos).
  • No dice nada sobre el formato de los mensajes pasados. Sin embargo, dado que el verbo HTTP y la URL ya definen la acción a tomar, el cuerpo del mensaje debe contener solo los datos.
  • La seguridad de los mensajes es proporcionada por el protocolo de transporte (HTTPS), y es punto a punto solamente. Si desea asegurar el mensaje de principio a fin, debe hacerlo usted mismo.
  • Originalmente diseñado para operaciones simples de CRUD en objetos.

JABÓN:

  • Independiente del protocolo de transporte (podría ser HTTP, FTP, TCP, UDP, canalizaciones con nombre, memoria compartida o incluso correo electrónico).
  • Solo requiere que el protocolo de transporte sea capaz de enviar y recibir texto (por ejemplo, en HTTP, solo se usa el verbo POST).
  • Define estrictamente el formato de los mensajes pasados. Un mensaje SOAP contiene los datos, la acción a realizar en él, los encabezados y los detalles del error en caso de falla.
  • La seguridad de los mensajes es proporcionada por los estándares WS- *, y es de extremo a extremo.
  • Originalmente diseñado para llamadas RPC arbitrarias.

Los puntos 2 y 3 de las listas anteriores son los principales puntos de incompatibilidad.

SOAP sigue el patrón RPC. Una API SOAP describe una serie de métodos, junto con sus parámetros y valores de retorno, a los que puede llamar desde su código. Hay un paso de clasificación que convierte esto en su representación de red.

REST nunca es RPC. Una API REST describe una serie de recursos, junto con un conjunto de verbos (generalmente HTTP''s GET, POST, PUT, DELETE) que pueden actuar sobre ellos.

Para responder a su pregunta directamente: SOAP infringe principalmente el punto 6 (no proporciona un conjunto uniforme de verbos en las API). También infringe el punto 2 (el servidor puede mantener el estado de cada cliente) y, como resultado, el punto 3 también (el estado impide el almacenamiento en caché).

Uno de los objetivos de REST es cachability, para eso el recurso debe ser identificado por el uri (cadena de consulta). En soap, la solicitud se publica, por lo tanto, para diferentes solicitudes, tiene el mismo uri y, por lo tanto, el recurso no puede ser identificado de manera exclusiva por el usuario.

Descanso: REST es el estilo arquitectónico para construir un servicio web utilizando el protocolo HTTP, donde los servicios web se tratan como recursos y algunos métodos básicos HTTP como GET, POST, DELETE se utilizan para identificar acciones estándar en los recursos. La API web RESTful (también llamada servicio web RESTful) es una API web implementada utilizando HTTP y los principios de REST.

Soap: SOAP, originalmente definido como Simple Object Access Protocol, es una especificación de protocolo para intercambiar información estructurada en formato XML.

Servicios web SOAP vs REST

1) SOAP es un protocolo, mientras que REST es un estilo arquitectónico.

2) SOAP no puede usar REST porque es un protocolo, mientras que REST puede usar servicios web SOAP porque es un concepto y puede usar cualquier protocolo como HTTP, SOAP.

3) SOAP utiliza interfaces de servicios para exponer la lógica de negocio, mientras que REST usa URI para exponer la lógica de negocios.

4) SOAP define estándares que se deben seguir estrictamente, mientras que REST no define demasiados estándares como SOAP.

5) SOAP requiere más ancho de banda y recursos que REST, mientras que REST requiere menos ancho de banda y recursos que SOAP.

6) SOAP define su propia seguridad mientras que los servicios web RESTful heredan medidas de seguridad del transporte subyacente.

7) SOAP solo permite el formato de datos XML, mientras que REST permite diferentes formatos de datos, como texto sin formato, HTML, XML, JSON, etc.

Los servicios web RESTful son muy preferidos sobre los servicios web SOAP.