Diferencias clave explicadas a principiantes

¿Quieres vincular tu aplicación a Instagram para volver a publicar imágenes usando ciertos hashtags o a Facebook para crear publicaciones automáticamente? ¿O tal vez desea incrustar videos de YouTube en su sitio web? Puede hacer todas estas cosas y más con las interfaces de programación de aplicaciones (API).

Las API como la API de Instagram, la API de Facebook y la API de YouTube brindan una forma segura y estandarizada para que varios programas se «comuniquen» entre sí. Esto significa que una aplicación puede extraer funciones o datos de otro software y usarlos para mejorar su propia funcionalidad o UX.

Pero, ¿cómo envían las aplicaciones estas solicitudes, las procesan y las responden de manera que la otra persona pueda entenderlas? Depende de cómo se haya construido la API. Analicemos dos de los métodos más populares a continuación.

Ahora que tenemos una descripción general de las diferencias entre SOAP y REST, echemos un vistazo más de cerca a su comparación en términos de servicios, seguridad y ejemplos.

Servicios SOAP y servicios REST

Para comparar las API SOAP y REST, primero debemos comprender qué hace exactamente cada tipo de API.

servicios SOAP

SOAP es un sistema de protocolo de comunicación estandarizado que utiliza tecnologías XML para definir una estructura de mensajería elaborada que permite el intercambio de información estructurada en un entorno distribuido y descentralizado. En otras palabras, SOAP permite que las aplicaciones que se ejecutan en diferentes sistemas operativos se comuniquen utilizando diferentes tecnologías y lenguajes de programación.

El cliente puede usar las API de SOAP para crear, descargar, actualizar o eliminar registros como contraseñas, cuentas, clientes potenciales y objetos personalizados del servidor.

servicios de descanso

Por otro lado, REST es un estilo arquitectónico, no un protocolo. Como se mencionó anteriormente, esto significa una transferencia al estado representativo. Esto significa que cuando un cliente solicita un recurso mediante la API REST, el servidor devuelve el estado actual del recurso en una representación estandarizada. En otras palabras, las API REST reciben solicitudes de recursos y devuelven toda la información de recursos relevante en un formato que los clientes pueden interpretar fácilmente.

Además de solicitar recursos, los clientes pueden usar las API REST para modificar e incluso agregar nuevos elementos en el servidor mediante métodos HTTP.

Para una descripción más detallada sigue leyendo REST API: cómo funcionan y qué necesitas saber.

Seguridad SOAP y REST

Ahora que comprendemos mejor lo que hacen las API SOAP y REST, comparemos sus medidas y protocolos de seguridad.

seguridad SOAP

Dado que SOAP es un protocolo de mensajería, la protección de las API de SOAP se centra principalmente en evitar el acceso no autorizado a los mensajes (y la información del usuario contenida en esos mensajes) recibidos y enviados desde las API de SOAP. La principal defensa contra el acceso no autorizado es la seguridad de los estándares web (WS), un conjunto de reglas que rigen la confidencialidad y los procedimientos de autenticación de los mensajes SOAP. Las medidas compatibles con WS Security incluyen contraseñas, cifrado XML y tokens de seguridad, entre otras.

WS Security va más allá de los mecanismos de seguridad de red tradicionales como HTTPS, que solo protege los mensajes durante el transporte entre el cliente que realizó la solicitud y el servidor o servicio de Internet que tiene los datos solicitados. WS Security, por otro lado, protege los mensajes más allá de la conexión HTTPS y, a veces, incluso más allá de la capa de transporte.

¿Cómo lo hace exactamente?

Un mensaje SOAP contiene la información necesaria para protegerlo o contiene información sobre dónde obtener la información necesaria para protegerlo. El mensaje SOAP también incluye información sobre los protocolos y procedimientos para procesar la seguridad de nivel de mensaje específico en su encabezado. Esto significa que cuando un punto final de servicio web recibe un mensaje SOAP, verifica la información de seguridad en el encabezado para asegurarse de que no haya sido manipulado. Por lo tanto, se dice que SOAP tiene «seguridad a nivel de mensaje».

Dado que SOAP admite especificaciones de WS como WS-Addressing, WS-Policy, WS-Security, WS-Federation, WS-ReliableMessaging, WS-Coordination, WS-AtomicTransaction y WS-RemotePortlets, la API de SOAP es ideal para transferencias de datos internas y más tareas delicadas, pero innecesarias cuando se utiliza un servicio público de Internet que está disponible gratuitamente para todos, por ejemplo, descargar datos meteorológicos. Hablaremos más sobre cuándo usar las API SOAP y REST más adelante en esta publicación.

Seguridad DESCANSO

Las API REST solo admiten mecanismos de seguridad de Internet tradicionales como HTTPS. Esto significa que cuando una aplicación envía y recupera un mensaje de la API REST mediante HTTPS, el mensaje se protege solo en la conexión HTTPS. Esto significa que el mensaje solo está protegido durante el transporte entre el cliente y el servicio. Esto está bien para los servicios públicos de Internet, pero puede no ser suficiente para transferencias de datos más confidenciales.

Dado que las API REST no tienen las funciones de seguridad ni las extensiones integradas que tiene SOAP, su seguridad depende del diseño de las propias API. Las API REST se pueden diseñar con ciertos mecanismos de seguridad para garantizar que solo los usuarios autenticados y autorizados puedan acceder a ellas. Los métodos comunes de autenticación de la API REST incluyen autenticación básica HTTP, tokens web JSON, OAuth y claves API.

Las API REST también deben tener especificaciones detalladas y rechazar cualquier solicitud que no tenga las declaraciones correctas en los encabezados HTTP, por ejemplo, o que siga sus especificaciones. Esto ayudará a proteger la aplicación web subyacente de entradas distorsionadas y maliciosas, incluso después de que el cliente haya accedido a ella.

Ejemplos SOAP vs REST

Comparemos algunos ejemplos de solicitudes y respuestas hacia y desde la API SOAP y la API REST. Los siguientes ejemplos se basan en QAComplete SOAP API y REST API, respectivamente. QAComplete es una herramienta integral de gestión de pruebas de software de SmartBear.

Un ejemplo de jabón.

Las solicitudes QAComplete SOAP son solicitudes HTTP POST realizadas a la URL del punto final del servicio web. El cliente y el servidor intercambian datos en formato XML en el cuerpo de las solicitudes y respuestas HTTP.

Esta API SOAP solo acepta solicitudes HTTP POST, pero también admite varias operaciones comunes para todos los tipos de elementos, incluidos Agregar, Eliminar, Cargar, Cargar por criterios y Actualizar. Verá estas operaciones en lugar de los verbos HTTP GET, PUT, PATCH y DELETE.

los ejemplo de código a continuación solicitudes para descargar un defecto según su ID en el proyecto en QAComplete usando la API SOAP. El fragmento de código está escrito en XML y utiliza la operación Bugs_Load:

 
POST /psws/psws.asmx HTTP/1.1
Host: myteam.mysite.com
Content-Type: application/soap+xml; charset=utf-8
Content-Length: 486 {Insert an appropriate value here}
<?xml version="1.0" encoding="utf-8"?>
<soap12:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap12="http://www.w3.org/2003/05/soap-envelope">
<soap12:Body>
<Bugs_Load xmlns="http://www.pragmaticsw.com/">
<AuthenticationData>
<AppCode>agSP</AppCode>
<DeptId>7154</DeptId>
<ProjId>1032</ProjId>
<UserId>25315</UserId>
<PassCode>p@ssword</PassCode>
</AuthenticationData>
<BugId>5</BugId>
</Bugs_Load>
</soap12:Body>
</soap12:Envelope>

La respuesta contendrá un código de estado HTTP y un objeto Bug que contiene información sobre el error necesario. Se escribirá en XML. El siguiente ejemplo muestra un código de estado HTTP 200 que indica que la solicitud se realizó correctamente, así como la información del error en XML:

 
HTTP/1.1 200 OK
Content-Type: application/soap+xml; charset=utf-8
Content-Length: 2244 {The server returns an appropriate value here}
<?xml version="1.0" encoding="utf-8"?>
<soap12:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap12="http://www.w3.org/2003/05/soap-envelope">
<soap12:Body>
<Bugs_LoadResponse xmlns="http://www.pragmaticsw.com/">
<Bugs_LoadResult>
<CustomFields>
<string>0.9.19</string>
<string>1.0.24</string>
</CustomFields>
<CustomFieldNames>
<string>Found in build</string>
<string>Fixed in build</string>
</CustomFieldNames>
<BugId>13254</BugId>
<Title>Floating toolbar improvements</Title>
<StatusCode>Resolved</StatusCode>
<PriorityCode>2-Fix Soon</PriorityCode>
<HowFoundCode>Test-Ad hoc</HowFoundCode>
<ResolutionCode>Fixed</ResolutionCode>
<AssigneeUserId>27942</AssigneeUserId>
<OpenedBy>27568</OpenedBy>
<ClosedBy>27942</ClosedBy>
<ResolvedBy>27568</ResolvedBy>
<Description><![CDATA[The design of the floating toolbar needs improvement so that it’s clearer what the user needs to do.]]></Description>
<Resolution>Resolved by Susan McLaren on 24-Jun-2014 at 03:55 PM</Resolution>
<OwnerUserId>27572</OwnerUserId>
<TestCaseId>0</TestCaseId>
<FolderId>52359</FolderId>
<EstHrs>0.000</EstHrs>
<EstStart>2014-06-10T10:00:00</EstStart>
<EstFinish>2014-06-13T10:00:00</EstFinish>
<PctComplete>100</PctComplete>
<ActHrs>0.000</ActHrs>
<ActualStart>2014-06-17T00:00:00</ActualStart>
<ActFinish>2014-06-31T00:00:00</ActFinish>
<EstHrsRemaining>0.000</EstHrsRemaining>
<DateOpened>2014-05-26T15:54:21.093</DateOpened>
<DateResolved>2014-06-24T15:55:25</DateResolved>
<DateClosed>0001-01-01T00:00:00</DateClosed>
<DateUpdated>2014-06-31T05:54:22</DateUpdated>
<ProjId>17823</ProjId>
<DateCreated>2014-05-26T15:54:21.093</DateCreated>
<UpdateUserId>27534</UpdateUserId>
<OriginalId>0</OriginalId>
<ImportId>0</ImportId>
<AssignedToName>Doe, John</AssignedToName>
<OpenedByName>McLaren, Susan</OpenedByName>
<OpenedByEmail>susan@example.com</OpenedByEmail>
<OpenedByCompany>Edgar Solutions</OpenedByCompany>
<ResolvedByName>McLaren, Susan</ResolvedByName>
<UserName>Fry, Alex</UserName>
<OwnerName>Davis, Eugeny</OwnerName>
<NbrFiles>0</NbrFiles>
<NbrNotes>1</NbrNotes>
<NbrEvents>0</NbrEvents>
<NbrTasks>2</NbrTasks>
<FolderName>FamilyAlbum/Release 1.1/Iteration 1</FolderName>
</Bugs_LoadResult>
</Bugs_LoadResponse>
</soap12:Body>
</soap12:Envelope>

Tenga en cuenta que este mensaje SOAP contiene un sobre, un encabezado y un elemento de cuerpo, todos los cuales son obligatorios.

Ejemplo de DESCANSO

Las solicitudes REST son solicitudes HTTP a la URL del punto final de la API REST de QAComplete, que tiene el siguiente formato: http (s): // {su-servidor} / rest-api / servicio / api / {versión} / {recurso}. Esta API utiliza los métodos HTTP GET, POST, PUT, PATCH y DELETE.

los ejemplo de código a continuación solicitudes para descargar un defecto de acuerdo con su ID de proyecto en QAComplete usando la API REST de QAComplete. El fragmento de código está escrito en JSON y utiliza el método HTTP, GET:

 
GET http://yourserver.com/rest-api/service/api/v1/projects/11873/defects/17 HTTP/1.1
Host: yourserver.com
Connection: keep-alive
Accept: application/json
Authorization: Basic am9obkBleGFtcGxlLmNvbTpwQHNzd29yZA==