Queres vincular a túa aplicación a Facebook para que poida xerar publicacións automaticamente ou a Instagram para que poidas volver publicar fotos con determinados hashtags?
Tamén podes incluír vídeos de YouTube no teu sitio web. As interfaces de programación de aplicacións permítenche realizar todas estas tarefas e máis (API).
As diferentes aplicacións poden "falarse" entre elas de forma segura e estandarizada grazas a API como a API de Instagram, a API de Facebook e a API de YouTube.
Noutras palabras, un programa pode tomar funcións ou datos doutro software e utilizalos para mellorar as súas propias funcións ou a experiencia do usuario. Pero como poden as aplicacións facer estas solicitudes, procesalas e responder a elas dun xeito que outros poidan entender?
Isto depende de como se creou a API. Cando se fala de deseños de API (interface de programación de aplicacións), é habitual comparar SOAP con REST, dous dos paradigmas de API máis destacados.
Tan pronto como as API SOAP (Simple Object Access Protocol) se converteron no estándar de ouro para empresas como Oracle, Sun e PayPal, houbo unha resposta igual e oposta aproximadamente un ano máis tarde cara ás API REST de Google, Amazon e eBay.
Nesta publicación, compararemos e contrastaremos as API SOAP coas API REST para que poidas decidir cal é o mellor para os teus propósitos.
Comezaremos definindo a API.
Que é a API?
A interface de programación de aplicacións denomínase API. As API son esencialmente unha colección de métodos e funcións que permiten o desenvolvemento de aplicacións. Teñen acceso á información e funcións de diferentes programas, servizos ou sistemas operativos.
Serven como unha especie de intermediario entre varios sistemas de software. Permiten "falar" entre dous programas non conectados.
Poñamos o exemplo dun corredor de bolsa que participa activamente no comercio e nos mercados financeiros. Unha colección de automatizados algoritmos de negociación pódese conectar á plataforma de corredor de negociación favorita do comerciante a través dunha API. Isto permítelle, o comerciante, executar transaccións electrónicas ou ver cotizacións e datos de prezos en tempo real.
Que é REST?
As verdadeiras API de "servizos web" inclúen REST (Representational State Transfer). As API REST están construídas sobre URI (identificadores uniformes de recursos, dos cales un URL é un tipo especial), o protocolo HTTP e o formato de datos JSON incriblemente compatible co navegador.
É posible que tamén se use o protocolo SOAP, como xa dixemos. As API REST poden ser fáciles de crear e facer crecer, pero tamén poden ser enormes e difíciles; todo depende de como se crean, amplían e do que pretendan facer.
As limitacións de recursos, os requisitos de seguridade reducidos, a compatibilidade do cliente do navegador, a capacidade de detección, a saúde dos datos e a escalabilidade son algúns dos motivos polos que desexa desenvolver unha API para que sexa RESTful, cousas que realmente se aplican aos servizos web.
REST ofrece unha opción máis lixeira. SOAP era difícil de usar e era oneroso para moitos desenvolvedores. Por exemplo, usar SOAP con JavaScript require escribir moito código para completar operacións sinxelas xa que a estrutura XML necesaria debe ser creada cada vez.
REST (normalmente) usa un URL sinxelo en lugar dunha solicitude XML. Aínda que hai raras circunstancias nas que debes ofrecer máis detalles, a maioría dos servizos web RESTful só usan a técnica de URL.
Os catro verbos HTTP 1.1 GET, POST, PUT e DELETE poden ser usados por REST para realizar operacións. A diferenza de SOAP, REST non precisa que a resposta estea en XML.
Están dispoñibles servizos web baseados en REST que saen datos en formatos de valor separado por comandos (CSV), JavaScript Object Notation (JSON) e Really Simple Syndication (RSS).
O obxectivo é que poidas obter os resultados que necesitas nun formato fácil de analizar no idioma que estás a usar para a túa aplicación.
características
- REST enfatiza a sinxeleza por encima de todo, debido aos protocolos HTTP.
- A web é máis adecuada para REST. É compatible cos navegadores porque se usa JSON como formato de datos.
- REST é coñecido pola súa excelente escalabilidade e velocidade.
- As conexións cliente-servidor e as arquitecturas fanse máis accesibles polas API REST. Se é RESTful, constrúese usando este modelo cliente-servidor, con viaxes de ida e volta entre as dúas partes que pasan cargas de datos.
- As API REST empregan unha interface estándar solitaria. Ao garantir que todas as aplicacións se conectan de forma uniforme e a través da mesma pasarela, simplifica a forma en que as aplicacións se comunican coa API.
Que é SOAP?
O seu propio protocolo, chamado SOAP (Simple Object Access Protocol), é un pouco máis complicado que REST xa que especifica máis estándares, incluídos os relacionados coa seguridade e a entrega de mensaxes.
Estas normas inherentes veñen con un pouco de sobrecarga adicional. Non obstante, poden ser un factor decisivo para as empresas que necesitan capacidades máis amplas de seguridade, transacción e conformidade con ACID (atomicidade, coherencia, illamento e durabilidade).
Para esta comparación, é importante ter en conta que moitas das vantaxes de SOAP non adoitan aplicarse ás aplicacións de servizos web, polo que son máis adecuadas para escenarios de tipo empresarial.
Graos máis altos de seguridade (como cando a aplicación móbil interactúa cun banco), aplicacións de mensaxería que requiren unha comunicación fiable, interactuar con sistemas legados ou o cumprimento de ACID son algunhas das razóns polas que desexa deseñar unha aplicación utilizando unha API SOAP.
As capacidades de mensaxería que ofrece SOAP están totalmente baseadas en XML. As tecnoloxías máis antigas incompatibles con Internet, como o modelo de obxectos de compoñentes distribuídos (DCOM) e a arquitectura de corredor de solicitudes de obxectos comúns, foron substituídas por SOAP cando foi creada por Microsoft (CORBA).
A dependencia das comunicacións binarias fai que estes sistemas fallen. A través de Internet, as mensaxes XML como a que usa SOAP funcionan mellor.
características
- A seguridade de SOAP é significativamente máis estrita. WS-Security é un estándar integrado que ofrece capacidades de seguridade adicionais a nivel empresarial de SOAP, se é necesario, ademais do soporte SSL.
- Razonamento correcto/reintento para un rendemento de mensaxería fiable. Debido a que REST carece dun mecanismo de mensaxe estandarizado, só pode tentar de novo cando a comunicación falla. Mesmo cando se usan intermedios SOAP, SOAP ofrece fiabilidade de extremo a extremo debido á súa lóxica integrada de éxito/reintento.
- SOAP xa cumpre coas normas ACID. Ao ditar como as transaccións poden interactuar coa base de datos, o cumprimento de ACID minimiza as anomalías e salvagarda a coherencia dunha base de datos. Debido a que ACID é máis cauteloso que outros modelos de coherencia de datos, úsase con frecuencia cando se xestionan transaccións sensibles, sexan financeiras ou doutro tipo.
- É sinxelo de entender para os programadores xa que SOAP é unha comunicación totalmente baseada en XML.
- O protocolo de mensaxería XML é unha adición ao protocolo HTTP.
- As comunicacións dun ordenador a outro pódense difundir mediante mensaxes SOAP.
- Tamén se pode implementar a arquitectura cliente-servidor. O cliente pode usar unha mensaxe de protocolo SOAP para chamar a unha chamada de procedemento remoto que está situada no lado do servidor.
Diferenzas REST vs SOAP
1. arquitectura
Unha API está destinada a mostrar principalmente compoñentes específicos da lóxica empresarial dunha aplicación nun servidor. Aínda que REST fai uso de URI para o mesmo propósito, SOAP emprega unha interface de servizo para iso.
As API REST créanse despois dos datos, mentres que as API SOAP desenvólvense despois das funcionalidades que a API ilustra. En comparación con SOAP, que está máis orientado a funcións, REST é un deseño máis baseado en datos.
2. Almacenamento en caché
Os navegadores poden volver utilizar os datos que se marcaron como cachés sen necesidade de que fagan unha nova solicitude ao servidor. Aforrar tempo e esforzo é un beneficio disto.
As respostas non se almacenarán na memoria caché a nivel HTTP xa que as consultas SOAP envíanse mediante solicitudes POST, que o estándar HTTP considera non idempotentes. Se queres empregar o caché, aínda debes crear as técnicas necesarias xa que as API REST non inclúen esta implementación.
3. Recursos e ancho de banda
Debido á transferencia de carga útil de tipo sobre utilizada por SOAP, hai un modesto aumento da sobrecarga, o que require un ancho de banda adicional. A natureza lixeira de REST é un beneficio nestas situacións porque xeralmente se utiliza para servizos web.
4. Seguridade
A seguridade WS, que admite SOAP e é un pouco máis completa que SSL a nivel de transporte, é desexable. A incorporación de medidas de seguridade a nivel empresarial con ela tamén é perfecta.
O cifrado de extremo a extremo mediante SSL é compatible con SOAP e REST, e REST pode usar HTTPS, a variante segura do protocolo HTTP.
5. Manexo de cargas útiles
Os datos transmitidos a través de Internet denomínanse carga útil. Unha carga útil que se considera "pesada" necesita recursos adicionais. En comparación con SOAP, que utiliza XML, REST adoita usar JSON e HTTP para axudar a diminuír a carga útil.
Normalmente, o cliente debe utilizar unha biblioteca de cliente especializada co código xerado para acceder ás API de SOAP debido ao seu contrato de comunicación extremadamente estricto.
Como resultado, SOAP ofrece un nivel de abstracción menor que REST e está máis estreitamente conectado co servidor.
Cando usar REST?
- Creación de API públicas: As API REST son preferidas para crear servizos web públicos porque se considera que son máis sinxelas de usar e adoptar que as API de SOAP. Ademais, SOAP ofrece varias medidas de seguridade incorporadas que REST non ten, aínda que estas características non son necesarias cando se traballa con datos e servizos abertos.
- Construción de aplicacións móbiles: REST é perfecto para crear aplicacións móbiles xa que é pequeno, eficaz, sen estado e caché.
- Utilizando escasos recursos do servidor e ancho de banda: todas as solicitudes a unha API REST deben ser sen estado, o que significa que cada interacción é separada e cada solicitude e resposta contén todos os datos necesarios para completar esa interacción. O servidor non garda rexistros de solicitudes anteriores xa que trata cada unha como unha nova solicitude. Como resultado, o servidor require moita menos memoria e funciona máis rápido porque unha solicitude non require máis accións nin a recuperación de datos históricos.
Cando usar SOAP?
- Creación de API privadas, especialmente para grandes empresas: SOAP é perfecto para aplicacións corporativas xa que permite o fluxo de datos nun ambiente descentralizado e distribuído e contén varias funcións de seguridade en liña.
- Usando un protocolo de transporte distinto de HTTP como capa subxacente: SOAP non depende de HTTP como capa subxacente. Dependendo da súa aplicación, pode utilizar SMTP (Simple Mail Transfer Protocol), JMS (Java Messaging Service) ou outro protocolo de transporte.
- Traballar con operacións con estado: A diferenza das solicitudes ás API REST, as solicitudes ás API SOAP teñen estado, o que significa que o servidor garda información sobre o cliente e utilízaa nunha cadea de solicitudes ou operacións. Aínda que este usa máis ancho de banda e recursos do servidor, é fundamental para levar a cabo accións rutineiras ou vinculadas, como transferencias bancarias.
Conclusión
A comparación entre as API REST e SOAP fai bastante evidente que REST é preferible a SOAP. Aínda así, hai situacións nas que se require a API SOAP. Nalgúns casos, os servizos web créanse combinando as API REST e SOAP.
Polo tanto, o caso de uso determinará que estilo de API funcionará mellor.
Deixe unha resposta