Voleu enllaçar la vostra aplicació a Facebook perquè pugui generar publicacions automàticament, o a Instagram perquè pugueu tornar a publicar fotos amb determinats hashtags?
També podeu incloure vídeos de YouTube al vostre lloc web. Les interfícies de programació d'aplicacions us permeten realitzar totes aquestes tasques i més (API).
Les diferents aplicacions poden "parlar" entre elles d'una manera segura i estandarditzada gràcies a API com l'API d'Instagram, l'API de Facebook i l'API de YouTube.
En altres paraules, un programa pot agafar característiques o dades d'un altre programari i utilitzar-les per millorar les seves pròpies funcions o experiència d'usuari. Però, com poden les aplicacions fer aquestes peticions, processar-les i respondre-hi d'una manera que els altres puguin entendre?
Això depèn de com es va crear l'API. Quan es parla dels dissenys d'API (interfície de programació d'aplicacions), és habitual comparar SOAP amb REST, dos dels paradigmes d'API més destacats.
Tan bon punt les API SOAP (Simple Object Access Protocol) es van convertir en l'estàndard d'or per a empreses com Oracle, Sun i PayPal, hi va haver una resposta igual i oposada un any més tard cap a les API REST de Google, Amazon i eBay.
En aquesta publicació, compararem i contrastarem les API SOAP amb les API REST perquè pugueu decidir quina és la millor per als vostres propòsits.
Començarem definint l'API.
Què és l'API?
La interfície de programació d'aplicacions s'anomena API. Les API són essencialment una col·lecció de mètodes i funcions que permeten el desenvolupament d'aplicacions. Tenen accés a la informació i funcions de diferents programes, serveis o sistemes operatius.
Serveixen com una mena d'intermediari entre diversos sistemes de programari. Permeten "parlar" entre dos programes no connectats.
Prenguem l'exemple d'un corredor de borsa que participa activament en el comerç i els mercats financers. Una col·lecció d'automàtics algorismes comercials es pot connectar a la plataforma de corredor de comerç preferida del comerciant mitjançant una API. Això us permet, el comerciant, executar transaccions electròniques o veure cotitzacions i dades de preus en temps real.
Què és REST?
Les veritables API de "serveis web" inclouen REST (Representational State Transfer). Les API REST es basen en URI (identificadors uniformes de recursos, dels quals un URL és un tipus especial), el protocol HTTP i el format de dades JSON increïblement compatible amb el navegador.
El protocol SOAP, com ja hem dit, també es podria utilitzar. Les API REST poden ser fàcils de crear i fer créixer, però també poden ser enormes i difícils; tot depèn de com es creïn, s'ampliïn i com es pretenguin fer.
Les restriccions de recursos, els requisits de seguretat reduïts, la compatibilitat amb el client del navegador, la descoberta, la salut de les dades i l'escalabilitat són alguns dels motius pels quals voldríeu desenvolupar una API perquè sigui RESTful, coses que s'apliquen realment als serveis web.
REST ofereix una opció més lleugera. SOAP era difícil d'utilitzar i pesat per a molts desenvolupadors. Per exemple, utilitzar SOAP amb JavaScript requereix escriure molt de codi per completar operacions senzilles, ja que s'ha de crear l'estructura XML necessària cada vegada.
REST (normalment) utilitza un URL senzill en lloc d'una sol·licitud XML. Tot i que hi ha rares circumstàncies en què heu d'oferir més detalls, la majoria dels serveis web RESTful només utilitzen la tècnica d'URL.
Els quatre verbs HTTP 1.1 GET, POST, PUT i DELETE els pot utilitzar REST per dur a terme operacions. A diferència de SOAP, REST no necessita que la resposta estigui en XML.
Els serveis web basats en REST que generen dades en formats de valor separat de comandaments (CSV), JavaScript Object Notation (JSON) i Really Simple Syndication (RSS) estan disponibles (RSS).
L'objectiu és que pugueu obtenir els resultats que necessiteu en un format fàcil d'analitzar dins de l'idioma que feu servir per a la vostra aplicació.
Característiques
- REST posa l'accent en la simplicitat per sobre de tot, a causa dels protocols HTTP.
- El web és el més adequat per a REST. És compatible amb els navegadors perquè s'utilitza JSON com a format de dades.
- REST és conegut per la seva excel·lent escalabilitat i velocitat.
- Les connexions client-servidor i les arquitectures són més accessibles per les API REST. Si és RESTful, es construeix utilitzant aquest model client-servidor, amb viatges d'anada i tornada entre les dues parts passant càrregues de dades.
- Les API REST utilitzen una interfície estàndard solitària. Assegurar que totes les aplicacions es connectin de manera uniforme i mitjançant la mateixa passarel·la, racionalitza la manera com les aplicacions es comuniquen amb l'API.
Què és el SABÓ?
El seu propi protocol, anomenat SOAP (Simple Object Access Protocol), és una mica més complicat que REST ja que especifica més estàndards, inclosos els relacionats amb la seguretat i el lliurament de missatges.
Aquestes normes inherents vénen amb una mica de sobrecàrrega addicional. No obstant això, poden ser un factor decisiu per a les empreses que necessiten capacitats de seguretat, transaccions i compliment d'ACID (atomicitat, coherència, aïllament i durabilitat) més àmplies.
Pel bé d'aquesta comparació, és important tenir en compte que molts dels avantatges de SOAP no s'apliquen sovint a les aplicacions de serveis web, cosa que les fa més adequades per a escenaris de tipus empresarial.
Graus més alts de seguretat (com quan a aplicació mòbil interactua amb un banc), les aplicacions de missatgeria que requereixen una comunicació fiable, la interacció amb sistemes heretats o el compliment d'ACID són alguns dels motius pels quals voldríeu dissenyar una aplicació utilitzant una API SOAP.
Les capacitats de missatgeria que ofereix SOAP es basen completament en XML. Tecnologies antigues incompatibles amb Internet, com el model d'objectes de components distribuïts (DCOM) i l'arquitectura d'intermediari de sol·licitud d'objectes comuns, van ser substituïdes per SOAP quan va ser creat per Microsoft (CORBA).
La dependència de les comunicacions binàries fa que aquests sistemes fallin. A Internet, la missatgeria XML com la que utilitza SOAP funciona millor.
Característiques
- La seguretat de SOAP és significativament més estricta. WS-Security és un estàndard integrat que ofereix capacitats de seguretat addicionals a nivell empresarial SOAP si cal, a més del suport SSL.
- Raonament correcte/reintent per obtenir un rendiment de missatgeria fiable. Com que REST no té un mecanisme de missatge estandarditzat, només pot tornar a intentar-ho quan la comunicació falla. Fins i tot quan s'utilitzen intermedis SOAP, SOAP ofereix fiabilitat d'extrem a extrem a causa de la seva lògica integrada d'èxit/reintent.
- SOAP ja compleix amb els estàndards ACID. En dictar com les transaccions poden interactuar amb la base de dades, el compliment d'ACID minimitza les anomalies i salvaguarda la consistència d'una base de dades. Com que ACID és més prudent que altres models de coherència de dades, s'utilitza amb freqüència quan es gestionen transaccions sensibles, ja siguin financeres o no.
- És fàcil d'entendre per als programadors, ja que SOAP és una comunicació totalment basada en XML.
- El protocol de missatgeria XML és una addició al protocol HTTP.
- Les comunicacions d'un ordinador a un altre ordinador es poden difondre mitjançant missatgeria SOAP.
- També es pot implementar l'arquitectura client-servidor. El client pot utilitzar un missatge de protocol SOAP per trucar a una trucada de procediment remot que es troba al costat del servidor.
Diferències REST vs SOAP
1. arquitectura
Una API està pensada per mostrar principalment components específics de la lògica de negoci d'una aplicació en un servidor. Tot i que REST fa ús d'URI per a la mateixa finalitat, SOAP utilitza una interfície de servei per a això.
Les API REST es creen després de les dades, mentre que les API SOAP es desenvolupen després de les funcionalitats que il·lustra l'API. En comparació amb SOAP, que està més basat en funcions, REST és un disseny més basat en dades.
2. Caching
Les dades que s'han marcat com a cacheable es poden tornar a utilitzar pels navegadors sense requerir que facin una nova sol·licitud al servidor. L'estalvi de temps i esforç és un avantatge d'això.
Les respostes no s'emmagatzemaran a la memòria cau a nivell HTTP, ja que les consultes SOAP s'envien mitjançant sol·licituds POST, que l'estàndard HTTP considera no idempotent. Si voleu utilitzar la memòria cau, encara heu de crear les tècniques necessàries, ja que les API REST no inclouen aquesta implementació.
3. Recursos i amplada de banda
A causa de la transferència de càrrega útil d'estil sobre que utilitza SOAP, hi ha un augment modest de les despeses generals, que requereix una amplada de banda addicional. La naturalesa lleugera de REST és un avantatge en aquestes situacions perquè s'utilitza generalment per a serveis web.
4. Seguretat
La seguretat WS, que admet SOAP i és una mica més completa que SSL a nivell de transport, és desitjable. Incorporar-hi mesures de seguretat a nivell empresarial també s'adapta perfectament.
El xifratge d'extrem a extrem mitjançant SSL és compatible amb SOAP i REST, i REST pot utilitzar HTTPS, la variant segura del protocol HTTP.
5. Manipulació de càrregues útils
Les dades transmeses a través d'Internet s'anomenen càrrega útil. Una càrrega útil que es considera "pesada" necessita recursos addicionals. En comparació amb SOAP, que utilitza XML, REST sovint utilitza JSON i HTTP per ajudar a reduir la càrrega útil.
Normalment, el client ha d'utilitzar una biblioteca de client especialitzada amb codi generat per accedir a les API SOAP a causa del seu contracte de comunicació extremadament estricte.
Com a resultat, SOAP ofereix un nivell d'abstracció menor que REST i està més estretament connectat amb el servidor.
Quan utilitzar REST?
- Creació d'API públiques: Les API REST són preferides per crear serveis web públics perquè es veu que són més senzilles d'utilitzar i adoptar que les API de SOAP. A més, SOAP ofereix diverses mesures de seguretat integrades que REST no té, encara que aquestes característiques no són necessàries quan es treballa amb dades i serveis oberts.
- Construcció d'aplicacions mòbils: REST és perfecte per crear aplicacions mòbils, ja que és petit, efectiu, sense estat i es pot guardar en memòria cau.
- Utilitzant els escassos recursos del servidor i ample de banda: Totes les sol·licituds a una API REST han de ser sense estat, el que significa que cada interacció és independent i cada sol·licitud i resposta conté totes les dades necessàries per completar aquesta interacció. El servidor no guarda registres de sol·licituds anteriors, ja que tracta cadascuna com una sol·licitud nova. Com a resultat, el servidor requereix molta menys memòria i funciona més ràpidament perquè una sol·licitud no requereix més accions ni la recuperació de dades històriques.
Quan utilitzar SOAP?
- Creació d'API privades, especialment per a grans empreses: SOAP és perfecte per a aplicacions corporatives, ja que permet el flux de dades en un entorn descentralitzat i distribuït i conté diverses funcions de seguretat en línia.
- Utilitzant un protocol de transport que no sigui HTTP com a capa subjacent: SOAP no depèn d'HTTP com a capa subjacent. Depenent de la vostra aplicació, podeu utilitzar SMTP (Simple Mail Transfer Protocol), JMS (Java Messaging Service) o un altre protocol de transport.
- Treballar amb operacions amb estat: A diferència de les sol·licituds a les API REST, les sol·licituds a les API SOAP tenen estat, és a dir, el servidor desa informació sobre el client i l'utilitza en una cadena de peticions o operacions. Tot i que això utilitza més ample de banda i recursos del servidor, és crucial per dur a terme accions rutinàries o vinculades, com ara transferències bancàries.
Conclusió
La comparació entre les API REST i SOAP fa força evident que REST és preferible a SOAP. Tot i així, hi ha situacions en què es requereix l'API SOAP. En determinats casos, els serveis web es creen combinant les API REST i SOAP.
Per tant, el cas d'ús determinarà quin estil d'API funcionarà millor.
Deixa un comentari