Unha API, interface de aplicaci\u00f3n de programa, define as regras que se deben seguir para comunicarse con outros programas ou sistemas de software. Os desenvolvedores crean, e expo\u00f1en, unha API para que outras aplicaci\u00f3ns, mediante programaci\u00f3n, poidan comunicarse coa(s) s\u00faa(s) aplicaci\u00f3n(s). Por exemplo, unha aplicaci\u00f3n que controle as horas de traballo dunha empresa exp\u00f3n unha API que solicita o nome completo dun empregado e un intervalo de datas. Cando recibe esta informaci\u00f3n, procesa internamente o rexistro de horas do empregado e devolve o n\u00famero de horas traballadas durante o intervalo de datas dado.<\/p>\n\n\n\n
Unha API pode desenvolverse para unha entorna pechada – intranet, extranet – o para que se aplique entre aplicaci\u00f3ns web. Neste caso, p\u00f3demos imaxinar \u00e1 API como unha pasarela entre clientes e recursos na web.<\/p>\n\n\n\n
Os clientes son usuarios que queren acceder \u00e1 informaci\u00f3n. O cliente pode ser unha persoa ou un sistema de software<\/em> que utilice a API. Por exemplo, p\u00f3dense escribir aplicaci\u00f3ns que accedan a datos meteorol\u00f3xicos desde un sistema meteorol\u00f3xico. E tam\u00e9n se pode acceder aos mesmos datos desde o navegador cando se visita directamente o sitio web do tempo.<\/p>\n\n\n\n Os recursos son a informaci\u00f3n que as diferentes aplicaci\u00f3ns proporcionan aos seus clientes. Os recursos poden ser imaxes, v\u00eddeos, texto, n\u00fameros ou calquera tipo de dato. O servidor \u00e9 a m\u00e1quina encargada de entregar o recurso ao cliente. As organizaci\u00f3ns usan API para compartir recursos e proporcionar servizos web, mantendo a seguridade, o control e a autenticaci\u00f3n. Ademais, as API ax\u00fadanlles a determinar que clientes te\u00f1en acceso a recursos internos espec\u00edficos.<\/p>\n\n\n\n API RESTful \u00e9 unha interface de intercambio de informaci\u00f3n de forma segura a trav\u00e9s de Internet que usan, entre eles, dous sistemas inform\u00e1ticos. Moitas aplicaci\u00f3ns empresariais precisan comunicarse con outras aplicaci\u00f3ns, internas ou de terceiros, para completar as s\u00faas 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\u00f3n, xerar n\u00f3minas,… e comunicarse coa aplicaci\u00f3n interna de contabilidade ou coas follas de rexistro de horas traballadas. API RESTful admite este intercambio de informaci\u00f3n, pois segue est\u00e1ndares seguros, fiables e eficientes de comunicaci\u00f3n entre distinto software.<\/p>\n\n\n\n Representational State Transfer (REST) \u200b\u200b\u00e9 unha arquitectura de software que imp\u00f3n condici\u00f3ns sobre como deber\u00eda funcionar unha API. REST creouse orixinalmente como unha gu\u00eda para xestionar a comunicaci\u00f3n nunha rede complexa como Internet. P\u00f3dese usar unha arquitectura baseada en REST para soportar comunicaci\u00f3ns fiables e de alto rendemento a escala. E calquera API p\u00f3dese po\u00f1er en funcionamento e modificar facilmente, proporcionandolle visibilidade e portabilidade multiplataforma.<\/p>\n\n\n\n Os desenvolvedores poden dese\u00f1ar API usando varias arquitecturas diferentes. As API que seguen o estilo arquitect\u00f3nico REST ch\u00e1manse API REST. Os servizos web que implementan unha arquitectura REST ch\u00e1manse servizos web RESTful. O termo API RESTful adoita facer referencia \u00e1s API web RESTful. Ademais, os termos API REST e API RESTful poden usarse indistintamente.<\/p>\n\n\n\n Alg\u00fans dos principios da arquitectura REST soen ser:<\/p>\n\n\n\n A interface uniforme \u00e9 fundamental para o dese\u00f1o de calquera servizo web RESTful. Esa interface \u00e9 a que indica que o servidor transfire efectivamente a informaci\u00f3n nun formato est\u00e1ndar. O resultado formateado da consulta ch\u00e1mase representaci\u00f3n en REST. Isto permite que o formato poida ser diferente da representaci\u00f3n interna do recurso na aplicaci\u00f3n do servidor. Por exemplo, o servidor pode almacenar os datos como texto, pero envialos nun formato de renderizado HTML.<\/p>\n\n\n\n A interface uniforme imp\u00f3n catro restrici\u00f3ns arquitect\u00f3nicas:<\/p>\n\n\n\n Na arquitectura REST, sen estado ref\u00edrese a un m\u00e9todo de comunicaci\u00f3n 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\u00f3n de dese\u00f1o da API REST significa que o servidor pode comprender e cumprir a solicitude en todo momento. <\/p>\n\n\n\n Nunha arquitectura de sistema en capas, o cliente pode conectarse con outros intermediarios autorizados entre o cliente e o servidor e a\u00ednda recibir\u00e1 respostas do servidor. Os servidores tam\u00e9n poden pasar solicitudes a outros servidores. O servizo web RESTful p\u00f3dese dese\u00f1ar para executarse en varios servidores con varias capas, como a seguridade, a aplicaci\u00f3n e a l\u00f3xica empresarial que traballan xuntos para satisfacer as solicitudes dos clientes. Estas capas permanecen invisibles para o cliente.<\/p>\n\n\n\n Os servizos web RESTful admiten a cach\u00e9, que \u00e9 o proceso de almacenar algunhas respostas na cach\u00e9 do cliente ou do intermediario para mellorar o tempo de resposta do servidor. Por exemplo, supo\u00f1a que visita un sitio web que ten imaxes com\u00fans na cabeceira e no p\u00e9 de p\u00e1xina en todas as p\u00e1xinas. Cada vez que visita unha p\u00e1xina nova no sitio web, o servidor debe volver enviar as mesmas imaxes. Para evitalo, o cliente almacena en cach\u00e9 ou almacena estas imaxes despois da primeira resposta e, a continuaci\u00f3n, utiliza as imaxes directamente da cach\u00e9. Os servizos web RESTful controlan o almacenamento na cach\u00e9 mediante respostas da API que poden ou non almacenarse na cach\u00e9.<\/p>\n\n\n\n No estilo de arquitectura REST, os servidores poden ampliar ou personalizar temporalmente a funcionalidade do cliente pasando c\u00f3digo de programaci\u00f3n de software ao cliente<\/em> . Por exemplo, cando enche un formulario de rexistro en calquera sitio web, o seu navegador destaca inmediatamente calquera erro que comete, como un n\u00famero de tel\u00e9fono incorrecto. O navegador pode facelo grazas ao c\u00f3digo enviado polo servidor.<\/p>\n\n\n\n As API RESTful incl\u00faen as seguintes vantaxes:<\/p>\n\n\n\n Os sistemas que implementan API REST poden escalar de forma eficiente porque REST optimiza as interacci\u00f3ns cliente-servidor. A tecnolox\u00eda sen estado elimina a carga do servidor porque o servidor non ten que reter informaci\u00f3n das solicitudes anteriores dos clientes. O cach\u00e9 ben xestionado elimina algunhas ou todas as interacci\u00f3ns cliente-servidor. Todas estas funci\u00f3ns admiten a escalabilidade, sen causar pescozos de botella na comunicaci\u00f3n que reduzan o rendemento.<\/p>\n\n\n\n Os servizos web RESTful admiten unha separaci\u00f3n completa entre o cliente e o servidor. Simplifican e desacoplan varios compo\u00f1entes do servidor para que cada parte poida evolucionar de forma independente. Os cambios na plataforma ou na tecnolox\u00eda na aplicaci\u00f3n do servidor non afectan \u00e1 aplicaci\u00f3n cliente. A capacidade de capas de funci\u00f3ns da aplicaci\u00f3n aumenta a\u00ednda m\u00e1is a flexibilidade. Por exemplo, os desenvolvedores poden facer cambios na capa de base de datos sen ter que reescribir a l\u00f3xica da aplicaci\u00f3n.<\/p>\n\n\n\n As API REST son independentes da tecnolox\u00eda que se utilice. Podes escribir aplicaci\u00f3ns do lado do cliente e do servidor nunha variedade de linguaxes de programaci\u00f3n, sen afectar o dese\u00f1o da API. Tam\u00e9n pode cambiar a tecnolox\u00eda subxacente a calquera lado sen afectar \u00e1 comunicaci\u00f3n.<\/p>\n\n\n\n A funci\u00f3n b\u00e1sica dunha API RESTful \u00e9 a mesma que navegar por Internet. Cando require un recurso, o cliente contacta co servidor a trav\u00e9s da API. Os desenvolvedores da API explican como o cliente debe usar a API REST na documentaci\u00f3n da API da aplicaci\u00f3n do servidor. Os seguintes son os pasos xerais para calquera chamada \u00e1 API REST:<\/p>\n\n\n\n Os detalles da solicitude e resposta da API REST var\u00edan algo dependendo de como a dese\u00f1aron os desenvolvedores da API.<\/p>\n\n\n\n As API RESTful requiren que as solicitudes conte\u00f1an os seguintes compo\u00f1entes principais:<\/p>\n\n\n\n O servidor identifica cada recurso con identificadores de recursos \u00fanicos. Nos servizos REST, o servidor normalmente identifica os recursos mediante un Localizador uniforme de recursos (URL). O URL especifica o cami\u00f1o ao recurso. Un URL \u00e9 semellante ao enderezo dun sitio web que se introduce nun navegador para visitar calquera p\u00e1xina web. O URL tam\u00e9n se denomina punto final de solicitude e especifica claramente ao servidor o que precisa o cliente.<\/p>\n\n\n\n Os desenvolvedores adoitan implementar API RESTful mediante o protocolo de transferencia de hipertexto (HTTP). Un m\u00e9todo HTTP indica ao servidor que facer co recurso. Aqu\u00ed tes catro m\u00e9todos HTTP com\u00fans:<\/p>\n\n\n\n GET<\/em><\/strong><\/p>\n\n\n\n Os clientes usan GET para acceder aos recursos que se atopan no URL especificado no servidor. Poden almacenar na cach\u00e9 solicitudes GET e enviar par\u00e1metros na solicitude da API RESTful para indicarlle ao servidor que filtre os datos antes de envialos.<\/p>\n\n\n\n POST<\/strong><\/em><\/p>\n\n\n\n Os clientes usan POST para enviar datos ao servidor. Inclu\u00edr a representaci\u00f3n dos datos coa solicitude. Enviar a mesma solicitude POST varias veces ten o efecto secundario de crear o mesmo recurso varias veces.<\/p>\n\n\n\n PUT<\/strong><\/em><\/p>\n\n\n\n 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\u00e1 o mesmo resultado.<\/p>\n\n\n\n DELETE<\/strong><\/em><\/p>\n\n\n\n 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\u00f3n adecuada, a solicitude fallar\u00e1.<\/p>\n\n\n\n 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\u00f3n sobre o estado da solicitude, etc.<\/p>\n\n\n\n datos<\/strong><\/em><\/p>\n\n\n\n As solicitudes da API REST poden inclu\u00edr datos para que funcionen correctamente os m\u00e9todos POST, PUT e outros HTTP.<\/p>\n\n\n\n par\u00e1metros<\/strong><\/em><\/p>\n\n\n\n As solicitudes de API RESTful poden inclu\u00edr par\u00e1metros que proporcionan ao servidor m\u00e1is detalles sobre o que debe facer. Aqu\u00ed tes alg\u00fans tipos diferentes de par\u00e1metros:<\/p>\n\n\n\n Un servizo web RESTful debe autenticar as solicitudes antes de poder enviar unha resposta. A autenticaci\u00f3n \u00e9 o proceso de verificaci\u00f3n dunha identidade. Por exemplo, pode acreditar a s\u00faa identidade mostrando unha tarxeta de identificaci\u00f3n ou carn\u00e9 de conducir. Do mesmo xeito, os clientes dos servizos RESTful deben demostrar a s\u00faa identidade ao servidor para establecer a confianza.<\/p>\n\n\n\n A API RESTful ten catro m\u00e9todos de autenticaci\u00f3n com\u00fans:<\/p>\n\n\n\n HTTP define alg\u00fans esquemas de autenticaci\u00f3n que se poden usar directamente cando se implementa a API REST. Aqu\u00ed tes dous esquemas deste tipo:<\/p>\n\n\n\n autenticaci\u00f3n b\u00e1sica<\/strong><\/em><\/p>\n\n\n\n Na autenticaci\u00f3n b\u00e1sica, o cliente env\u00eda o nome e o contrasinal do usuario na cabeceira da solicitude. Codificaos con base64, que \u00e9 unha t\u00e9cnica de codificaci\u00f3n que converte o par nun conxunto de 64 caracteres para unha transmisi\u00f3n segura.<\/p>\n\n\n\n autenticaci\u00f3n de portador<\/strong><\/em><\/p>\n\n\n\n O termo autenticaci\u00f3n do portador ref\u00edrese ao proceso de proporcionar control de acceso ao portador do token<\/em> . O token<\/em> do portador \u00e9 normalmente unha cadea cifrada que \u00e9 xerada polo servidor en resposta a unha solicitude de inicio de sesi\u00f3n. O cliente env\u00eda o token<\/em> nas cabeceiras da solicitude para acceder aos recursos.<\/p>\n\n\n\n As claves API son outra opci\u00f3n para a autenticaci\u00f3n da API REST. Neste enfoque, o servidor asigna un valor xerado \u00fanico a un cliente por primeira vez. Cada vez que o cliente tenta acceder aos recursos, utiliza a clave API \u00fanica para a verificaci\u00f3n. As claves da API son menos seguras porque o cliente debe transmitir a chave, polo que \u00e9 vulnerable ao roubo da rede.<\/p>\n\n\n\n OAuth combina contrasinais e tokens<\/em> para un acceso de inicio de sesi\u00f3n altamente seguro a calquera sistema. O servidor pide primeiro un contrasinal e despois un token<\/em> adicional para completar o proceso de autorizaci\u00f3n. Podes verificar o token en calquera momento, e tam\u00e9n ao longo do tempo, cun alcance e duraci\u00f3n especificados.<\/p>\n\n\n\n Os principios REST requiren que a resposta do servidor conte\u00f1a os seguintes compo\u00f1entes principais:<\/p>\n\n\n\n A li\u00f1a de estado cont\u00e9n un c\u00f3digo de estado de tres d\u00edxitos que indica se a solicitude foi procesada correctamente ou non. Por exemplo, os c\u00f3digos 2XX indican un procesamento exitoso, pero os c\u00f3digos 4XX e 5XX indican erros. Os c\u00f3digos 3XX indican a redirecci\u00f3n de URL.<\/p>\n\n\n\n A continuaci\u00f3n m\u00f3stranse alg\u00fans c\u00f3digos de estado com\u00fans:<\/p>\n\n\n\n O corpo de resposta cont\u00e9n a representaci\u00f3n do recurso. O servidor selecciona un formato de renderizaci\u00f3n adecuado en funci\u00f3n do contido nas cabeceiras da solicitude. Os clientes poden solicitar informaci\u00f3n 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\u00f3n JSON como a seguinte:<\/p>\n\n\n\n ‘{“nome”:”Xi\u00e1n”, “idade”:20}’<\/p>\n\n\n\n A resposta tam\u00e9n cont\u00e9n cabeceiras ou metadatos sobre a resposta. Estes proporcionan m\u00e1is contexto sobre a resposta e incl\u00faen informaci\u00f3n como o servidor, a codificaci\u00f3n, a data e o tipo de contido.<\/p>\n","protected":false},"excerpt":{"rendered":" Que \u00e9 unha API? Unha API, interface de aplicaci\u00f3n de programa, define as regras que se deben seguir para comunicarse con outros programas ou sistemas de software. Os desenvolvedores crean, e expo\u00f1en, unha API para que outras aplicaci\u00f3ns, mediante programaci\u00f3n, poidan comunicarse coa(s) s\u00faa(s) aplicaci\u00f3n(s). Por exemplo, unha aplicaci\u00f3n que controle as horas de traballo dunha empresa […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_monsterinsights_skip_tracking":false,"_monsterinsights_sitenote_active":false,"_monsterinsights_sitenote_note":"","_monsterinsights_sitenote_category":0,"_uf_show_specific_survey":0,"_uf_disable_surveys":false,"ocean_post_layout":"","ocean_both_sidebars_style":"","ocean_both_sidebars_content_width":0,"ocean_both_sidebars_sidebars_width":0,"ocean_sidebar":"0","ocean_second_sidebar":"0","ocean_disable_margins":"enable","ocean_add_body_class":"","ocean_shortcode_before_top_bar":"","ocean_shortcode_after_top_bar":"","ocean_shortcode_before_header":"","ocean_shortcode_after_header":"","ocean_has_shortcode":"","ocean_shortcode_after_title":"","ocean_shortcode_before_footer_widgets":"","ocean_shortcode_after_footer_widgets":"","ocean_shortcode_before_footer_bottom":"","ocean_shortcode_after_footer_bottom":"","ocean_display_top_bar":"default","ocean_display_header":"default","ocean_header_style":"","ocean_center_header_left_menu":"0","ocean_custom_header_template":"0","ocean_custom_logo":0,"ocean_custom_retina_logo":0,"ocean_custom_logo_max_width":0,"ocean_custom_logo_tablet_max_width":0,"ocean_custom_logo_mobile_max_width":0,"ocean_custom_logo_max_height":0,"ocean_custom_logo_tablet_max_height":0,"ocean_custom_logo_mobile_max_height":0,"ocean_header_custom_menu":"0","ocean_menu_typo_font_family":"0","ocean_menu_typo_font_subset":"","ocean_menu_typo_font_size":0,"ocean_menu_typo_font_size_tablet":0,"ocean_menu_typo_font_size_mobile":0,"ocean_menu_typo_font_size_unit":"px","ocean_menu_typo_font_weight":"","ocean_menu_typo_font_weight_tablet":"","ocean_menu_typo_font_weight_mobile":"","ocean_menu_typo_transform":"","ocean_menu_typo_transform_tablet":"","ocean_menu_typo_transform_mobile":"","ocean_menu_typo_line_height":0,"ocean_menu_typo_line_height_tablet":0,"ocean_menu_typo_line_height_mobile":0,"ocean_menu_typo_line_height_unit":"","ocean_menu_typo_spacing":0,"ocean_menu_typo_spacing_tablet":0,"ocean_menu_typo_spacing_mobile":0,"ocean_menu_typo_spacing_unit":"","ocean_menu_link_color":"","ocean_menu_link_color_hover":"","ocean_menu_link_color_active":"","ocean_menu_link_background":"","ocean_menu_link_hover_background":"","ocean_menu_link_active_background":"","ocean_menu_social_links_bg":"","ocean_menu_social_hover_links_bg":"","ocean_menu_social_links_color":"","ocean_menu_social_hover_links_color":"","ocean_disable_title":"default","ocean_disable_heading":"default","ocean_post_title":"","ocean_post_subheading":"","ocean_post_title_style":"","ocean_post_title_background_color":"","ocean_post_title_background":0,"ocean_post_title_bg_image_position":"","ocean_post_title_bg_image_attachment":"","ocean_post_title_bg_image_repeat":"","ocean_post_title_bg_image_size":"","ocean_post_title_height":0,"ocean_post_title_bg_overlay":0.5,"ocean_post_title_bg_overlay_color":"","ocean_disable_breadcrumbs":"default","ocean_breadcrumbs_color":"","ocean_breadcrumbs_separator_color":"","ocean_breadcrumbs_links_color":"","ocean_breadcrumbs_links_hover_color":"","ocean_display_footer_widgets":"default","ocean_display_footer_bottom":"default","ocean_custom_footer_template":"0","omw_enable_modal_window":"enable","ocean_post_oembed":"","ocean_post_self_hosted_media":"","ocean_post_video_embed":"","ocean_link_format":"","ocean_link_format_target":"self","ocean_quote_format":"","ocean_quote_format_link":"post","ocean_gallery_link_images":"off","ocean_gallery_id":[],"footnotes":""},"categories":[1],"tags":[],"class_list":["post-1102","post","type-post","status-publish","format-standard","hentry","category-blog","entry"],"aioseo_notices":[],"_links":{"self":[{"href":"https:\/\/bitsolto.com\/bitacora\/wp-json\/wp\/v2\/posts\/1102","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/bitsolto.com\/bitacora\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/bitsolto.com\/bitacora\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/bitsolto.com\/bitacora\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/bitsolto.com\/bitacora\/wp-json\/wp\/v2\/comments?post=1102"}],"version-history":[{"count":4,"href":"https:\/\/bitsolto.com\/bitacora\/wp-json\/wp\/v2\/posts\/1102\/revisions"}],"predecessor-version":[{"id":1144,"href":"https:\/\/bitsolto.com\/bitacora\/wp-json\/wp\/v2\/posts\/1102\/revisions\/1144"}],"wp:attachment":[{"href":"https:\/\/bitsolto.com\/bitacora\/wp-json\/wp\/v2\/media?parent=1102"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/bitsolto.com\/bitacora\/wp-json\/wp\/v2\/categories?post=1102"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/bitsolto.com\/bitacora\/wp-json\/wp\/v2\/tags?post=1102"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}Recursos<\/h3>\n\n\n\n
Que \u00e9 API RESTful?<\/h2>\n\n\n\n
Que \u00e9 REST?<\/h2>\n\n\n\n
– interface uniforme<\/h3>\n\n\n\n
\n
– tecnolox\u00eda sen estado<\/h3>\n\n\n\n
– sistema en capas<\/h3>\n\n\n\n
– cach\u00e9<\/h3>\n\n\n\n
– c\u00f3digo baixo demanda<\/h3>\n\n\n\n
Que vantaxes ofrece API RESTful?<\/h2>\n\n\n\n
– escalabilidade<\/h3>\n\n\n\n
– flexibilidade<\/h3>\n\n\n\n
– independencia<\/h3>\n\n\n\n
Como funciona unha API RESTful?<\/h2>\n\n\n\n
\n
Que cont\u00e9n a solicitude do cliente da API RESTful?<\/h2>\n\n\n\n
– identificador \u00fanico de recurso<\/h3>\n\n\n\n
– m\u00e9todo<\/h3>\n\n\n\n
Cabeceiras HTTP<\/h3>\n\n\n\n
\n
Cales son os m\u00e9todos de autenticaci\u00f3n da API RESTful?<\/h2>\n\n\n\n
Autenticaci\u00f3n HTTP<\/h3>\n\n\n\n
Claves API<\/h3>\n\n\n\n
OAuth<\/h3>\n\n\n\n
Que cont\u00e9n a resposta do servidor da API RESTful?<\/h2>\n\n\n\n
Li\u00f1a de estado<\/h3>\n\n\n\n
\n
Corpo da mensaxe<\/h3>\n\n\n\n
Cabeceiras<\/h3>\n\n\n\n