Que é unha API?
Unha API, interface de aplicación de programa, define as regras que se deben seguir para comunicarse con outros programas ou sistemas de software. Os desenvolvedores crean, e expoñen, unha API para que outras aplicacións, mediante programación, poidan comunicarse coa(s) súa(s) aplicación(s). Por exemplo, unha aplicación que controle as horas de traballo dunha empresa expón unha API que solicita o nome completo dun empregado e un intervalo de datas. Cando recibe esta información, procesa internamente o rexistro de horas do empregado e devolve o número de horas traballadas durante o intervalo de datas dado.
Unha API pode desenvolverse para unha entorna pechada - intranet, extranet - o para que se aplique entre aplicacións web. Neste caso, pódemos imaxinar á API como unha pasarela entre clientes e recursos na web.
Clientes
Os clientes son usuarios que queren acceder á información. O cliente pode ser unha persoa ou un sistema de software que utilice a API. Por exemplo, pódense escribir aplicacións que accedan a datos meteorolóxicos desde un sistema meteorolóxico. E tamén se pode acceder aos mesmos datos desde o navegador cando se visita directamente o sitio web do tempo.
Recursos
Os recursos son a información que as diferentes aplicacións proporcionan aos seus clientes. Os recursos poden ser imaxes, vídeos, texto, números ou calquera tipo de dato. O servidor é a máquina encargada de entregar o recurso ao cliente. As organizacións usan API para compartir recursos e proporcionar servizos web, mantendo a seguridade, o control e a autenticación. Ademais, as API axúdanlles a determinar que clientes teñen acceso a recursos internos específicos.
Que é API RESTful?
API RESTful é unha interface de intercambio de información de forma segura a través de Internet que usan, entre eles, dous sistemas informáticos. Moitas aplicacións empresariais precisan comunicarse con outras aplicacións, internas ou de terceiros, para completar as súas tarefas. Por exemplo, o sistema de contabilidade interno dunha empresa debe compartir datos co sistema bancario de cada empregado e/ou cliente para automatizar a facturación, xerar nóminas,... e comunicarse coa aplicación interna de contabilidade ou coas follas de rexistro de horas traballadas. API RESTful admite este intercambio de información, pois segue estándares seguros, fiables e eficientes de comunicación entre distinto software.
Que é REST?
Representational State Transfer (REST) é unha arquitectura de software que impón condicións sobre como debería funcionar unha API. REST creouse orixinalmente como unha guía para xestionar a comunicación nunha rede complexa como Internet. Pódese usar unha arquitectura baseada en REST para soportar comunicacións fiables e de alto rendemento a escala. E calquera API pódese poñer en funcionamento e modificar facilmente, proporcionandolle visibilidade e portabilidade multiplataforma.
Os desenvolvedores poden deseñar API usando varias arquitecturas diferentes. As API que seguen o estilo arquitectónico REST chámanse API REST. Os servizos web que implementan unha arquitectura REST chámanse servizos web RESTful. O termo API RESTful adoita facer referencia ás API web RESTful. Ademais, os termos API REST e API RESTful poden usarse indistintamente.
Algúns dos principios da arquitectura REST soen ser:
- interface uniforme
A interface uniforme é fundamental para o deseño de calquera servizo web RESTful. Esa interface é a que indica que o servidor transfire efectivamente a información nun formato estándar. O resultado formateado da consulta chámase representación en REST. Isto permite que o formato poida ser diferente da representación interna do recurso na aplicación do servidor. Por exemplo, o servidor pode almacenar os datos como texto, pero envialos nun formato de renderizado HTML.
A interface uniforme impón catro restricións arquitectónicas:
- As solicitudes deben identificar os recursos. Fano usando un identificador de recurso uniforme.
- Os clientes dispoñen da información suficiente na representación do recurso para modificalo ou eliminalo se así o desexan. O servidor cumpre esta condición enviando os metadatos que describen o recurso con máis detalle.
- Os clientes reciben información sobre como seguir procesando a representación. O servidor consegue isto enviando mensaxes autodescritivas que conteñen metadatos sobre como o cliente pode usalos mellor.
- Os clientes reciben información sobre todos os outros recursos relacionados que necesitan para completar unha tarefa. O servidor consegue isto enviando hipervínculos na representación para que os clientes poidan descubrir de forma dinámica máis recursos.
- tecnoloxía sen estado
Na arquitectura REST, sen estado refírese a un método de comunicación no que o servidor completa todas as solicitudes do cliente independentemente de todas as solicitudes anteriores. Os clientes poden solicitar recursos en calquera orde e todas as solicitudes son sen estado ou illadas do resto. Esta limitación de deseño da API REST significa que o servidor pode comprender e cumprir a solicitude en todo momento.
- sistema en capas
Nunha arquitectura de sistema en capas, o cliente pode conectarse con outros intermediarios autorizados entre o cliente e o servidor e aínda recibirá respostas do servidor. Os servidores tamén poden pasar solicitudes a outros servidores. O servizo web RESTful pódese deseñar para executarse en varios servidores con varias capas, como a seguridade, a aplicación e a lóxica empresarial que traballan xuntos para satisfacer as solicitudes dos clientes. Estas capas permanecen invisibles para o cliente.
- caché
Os servizos web RESTful admiten a caché, que é o proceso de almacenar algunhas respostas na caché do cliente ou do intermediario para mellorar o tempo de resposta do servidor. Por exemplo, supoña que visita un sitio web que ten imaxes comúns na cabeceira e no pé de páxina en todas as páxinas. Cada vez que visita unha páxina nova no sitio web, o servidor debe volver enviar as mesmas imaxes. Para evitalo, o cliente almacena en caché ou almacena estas imaxes despois da primeira resposta e, a continuación, utiliza as imaxes directamente da caché. Os servizos web RESTful controlan o almacenamento na caché mediante respostas da API que poden ou non almacenarse na caché.
- código baixo demanda
No estilo de arquitectura REST, os servidores poden ampliar ou personalizar temporalmente a funcionalidade do cliente pasando código de programación de software ao cliente . Por exemplo, cando enche un formulario de rexistro en calquera sitio web, o seu navegador destaca inmediatamente calquera erro que comete, como un número de teléfono incorrecto. O navegador pode facelo grazas ao código enviado polo servidor.
Que vantaxes ofrece API RESTful?
As API RESTful inclúen as seguintes vantaxes:
- escalabilidade
Os sistemas que implementan API REST poden escalar de forma eficiente porque REST optimiza as interaccións cliente-servidor. A tecnoloxía sen estado elimina a carga do servidor porque o servidor non ten que reter información das solicitudes anteriores dos clientes. O caché ben xestionado elimina algunhas ou todas as interaccións cliente-servidor. Todas estas funcións admiten a escalabilidade, sen causar pescozos de botella na comunicación que reduzan o rendemento.
- flexibilidade
Os servizos web RESTful admiten unha separación completa entre o cliente e o servidor. Simplifican e desacoplan varios compoñentes do servidor para que cada parte poida evolucionar de forma independente. Os cambios na plataforma ou na tecnoloxía na aplicación do servidor non afectan á aplicación cliente. A capacidade de capas de funcións da aplicación aumenta aínda máis a flexibilidade. Por exemplo, os desenvolvedores poden facer cambios na capa de base de datos sen ter que reescribir a lóxica da aplicación.
- independencia
As API REST son independentes da tecnoloxía que se utilice. Podes escribir aplicacións do lado do cliente e do servidor nunha variedade de linguaxes de programación, sen afectar o deseño da API. Tamén pode cambiar a tecnoloxía subxacente a calquera lado sen afectar á comunicación.
Como funciona unha API RESTful?
A función básica dunha API RESTful é a mesma que navegar por Internet. Cando require un recurso, o cliente contacta co servidor a través da API. Os desenvolvedores da API explican como o cliente debe usar a API REST na documentación da API da aplicación do servidor. Os seguintes son os pasos xerais para calquera chamada á API REST:
- O cliente envía unha solicitude ao servidor. O cliente segue a documentación da API para formatar a solicitude dun xeito que o servidor entenda.
- O servidor autentica o cliente e confirma que o cliente ten dereito a realizar tal solicitude.
- O servidor recibe a solicitude e procesa internamente.
- A continuación, devolve unha resposta ao cliente. Esta resposta contén información que lle indica ao cliente se a solicitude foi procesada correctamente. A resposta tamén inclúe calquera información que o cliente solicitou.
Os detalles da solicitude e resposta da API REST varían algo dependendo de como a deseñaron os desenvolvedores da API.
Que contén a solicitude do cliente da API RESTful?
As API RESTful requiren que as solicitudes conteñan os seguintes compoñentes principais:
- identificador único de recurso
O servidor identifica cada recurso con identificadores de recursos únicos. Nos servizos REST, o servidor normalmente identifica os recursos mediante un Localizador uniforme de recursos (URL). O URL especifica o camiño ao recurso. Un URL é semellante ao enderezo dun sitio web que se introduce nun navegador para visitar calquera páxina web. O URL tamén se denomina punto final de solicitude e especifica claramente ao servidor o que precisa o cliente.
- método
Os desenvolvedores adoitan implementar API RESTful mediante o protocolo de transferencia de hipertexto (HTTP). Un método HTTP indica ao servidor que facer co recurso. Aquí tes catro métodos HTTP comúns:
GET
Os clientes usan GET para acceder aos recursos que se atopan no URL especificado no servidor. Poden almacenar na caché solicitudes GET e enviar parámetros na solicitude da API RESTful para indicarlle ao servidor que filtre os datos antes de envialos.
POST
Os clientes usan POST para enviar datos ao servidor. Incluír a representación dos datos coa solicitude. Enviar a mesma solicitude POST varias veces ten o efecto secundario de crear o mesmo recurso varias veces.
PUT
Os clientes usan PUT para actualizar os recursos existentes no servidor. A diferenza de POST, enviar a mesma solicitude PUT varias veces nun servizo web RESTful dá o mesmo resultado.
DELETE
Os clientes usan a solicitude DELETE para eliminar o recurso. Unha solicitude DELETE pode cambiar o estado do servidor. Non obstante, se o usuario non ten unha autenticación adecuada, a solicitude fallará.
Cabeceiras HTTP
As cabeceiras de solicitude son os metadatos que se intercambian entre o cliente e o servidor. Por exemplo, a cabeceira da solicitude indica o formato da solicitude e da resposta, ofrece información sobre o estado da solicitude, etc.
datos
As solicitudes da API REST poden incluír datos para que funcionen correctamente os métodos POST, PUT e outros HTTP.
parámetros
As solicitudes de API RESTful poden incluír parámetros que proporcionan ao servidor máis detalles sobre o que debe facer. Aquí tes algúns tipos diferentes de parámetros:
- Os parámetros da ruta especifican os detalles do URL.
- Os parámetros de consulta solicitan máis información sobre o recurso.
- Os parámetros das cookies autentican os clientes rapidamente.
Cales son os métodos de autenticación da API RESTful?
Un servizo web RESTful debe autenticar as solicitudes antes de poder enviar unha resposta. A autenticación é o proceso de verificación dunha identidade. Por exemplo, pode acreditar a súa identidade mostrando unha tarxeta de identificación ou carné de conducir. Do mesmo xeito, os clientes dos servizos RESTful deben demostrar a súa identidade ao servidor para establecer a confianza.
A API RESTful ten catro métodos de autenticación comúns:
Autenticación HTTP
HTTP define algúns esquemas de autenticación que se poden usar directamente cando se implementa a API REST. Aquí tes dous esquemas deste tipo:
autenticación básica
Na autenticación básica, o cliente envía o nome e o contrasinal do usuario na cabeceira da solicitude. Codificaos con base64, que é unha técnica de codificación que converte o par nun conxunto de 64 caracteres para unha transmisión segura.
autenticación de portador
O termo autenticación do portador refírese ao proceso de proporcionar control de acceso ao portador do token . O token do portador é normalmente unha cadea cifrada que é xerada polo servidor en resposta a unha solicitude de inicio de sesión. O cliente envía o token nas cabeceiras da solicitude para acceder aos recursos.
Claves API
As claves API son outra opción para a autenticación da API REST. Neste enfoque, o servidor asigna un valor xerado único a un cliente por primeira vez. Cada vez que o cliente tenta acceder aos recursos, utiliza a clave API única para a verificación. As claves da API son menos seguras porque o cliente debe transmitir a chave, polo que é vulnerable ao roubo da rede.
OAuth
OAuth combina contrasinais e tokens para un acceso de inicio de sesión altamente seguro a calquera sistema. O servidor pide primeiro un contrasinal e despois un token adicional para completar o proceso de autorización. Podes verificar o token en calquera momento, e tamén ao longo do tempo, cun alcance e duración especificados.
Que contén a resposta do servidor da API RESTful?
Os principios REST requiren que a resposta do servidor conteña os seguintes compoñentes principais:
Liña de estado
A liña de estado contén un código de estado de tres díxitos que indica se a solicitude foi procesada correctamente ou non. Por exemplo, os códigos 2XX indican un procesamento exitoso, pero os códigos 4XX e 5XX indican erros. Os códigos 3XX indican a redirección de URL.
A continuación móstranse algúns códigos de estado comúns:
- 200: Resposta xenérica de procesamento de éxito
- 201 - Resposta de procesamento satisfactoria do método POST
- 400: resposta incorrecta que o servidor non pode procesar
- 404: recurso non atopado
Corpo da mensaxe
O corpo de resposta contén a representación do recurso. O servidor selecciona un formato de renderización adecuado en función do contido nas cabeceiras da solicitude. Os clientes poden solicitar información en formato XML ou JSON, que define como se escriben os datos en texto plano. Por exemplo, se o cliente solicita o nome e a idade dunha persoa chamada John, o servidor devolve unha representación JSON como a seguinte:
'{"nome":"Xián", "idade":20}'
Cabeceiras
A resposta tamén contén cabeceiras ou metadatos sobre a resposta. Estes proporcionan máis contexto sobre a resposta e inclúen información como o servidor, a codificación, a data e o tipo de contido.
