2024年七大最佳免费货币转换API
REST API 示例
在集成时代,跨多个平台的数据交换比以往任何时候都更加重要。设想一个没有集成功能的在线商店。你的网站除了管理产品列表外,还得开发系统管理用户账户、电子邮件订阅、支付处理、发货以及其他任务。由于这种方式不具备可扩展性,将这些职责外包给其他服务提供商会更加高效。
软件程序之间沟通所用的工具就是应用程序编程接口,或称为Web API。PI为两个程序之间的数据交换提供了统一的协议。借助Web API,你的在线商店可以与配送软件、客户端应用程序、支付应用程序以及任何其他必要的连接进行通信。
创建API有多种方式,但如果你想为你的服务添加软件连接,有一种独特的技术你应该有所了解:REST API网络服务。本文将讨论REST API的示例、REST API是什么、REST API如何工作、REST API的用途、历史、元素等内容。
REST API究竟是什么?
表述性状态转移(REST API网络服务)是微服务框架中连接组件的最标准做法,因为它提供了一种灵活、便携的方式来整合应用程序。REST 是一种流行的 API 设计,我们采用它以标准化和可预测的方式与内部和外部利益相关者进行交互。
Web应用用户经常利用REST API网络服务进行相互通信。例如,在社交媒体程序中获取和查看账户详情。REST API可以被视为浏览器的网页语法。随着云计算使用的增加,在线客户利用Web API来提供和管理对数字操作的访问。
设计Web API,使客户能够在分布式环境中动态地连接、管理和参与数字Web服务,是一个明智的选择。Google、eBay、Facebook、Amazon 和 Twitter 等网站都使用 RESTful Web 服务。现在,客户端应用程序可以使用REST来访问这些网络服务。
REST技术相较于其他相关技术更受欢迎。这是因为REST网络服务消耗的带宽更少,使其成为高效在线活动的理想选择。RESTful Web 服务也可以使用 JavaScript 或 Python 等编程语言进行开发。
REST API 的工作原理是什么?
要了解 REST API 的工作原理,我们必须定义一些关键术语:
客户端
API 用户称为客户端。客户端向 Web API 发送查询以获取数据或对程序进行修改。你的互联网浏览器就是一个客户端,它与各种Web API进行通信以获取页面内容。你的计算机接收到所需信息后,将其显示在屏幕上。
以下是最流行的 HTTP 方法:
- 使用GET请求返回请求的数据或资源。
- 使用POST请求创建新资源。
- 使用PUT指令修改或持续更新现有资源。
- 使用DELETE命令删除资源。
例如,对 Youtube API 的 HTTP 请求可以是特定视频或帖子的 GET 请求资源,也可以是发布新照片的 POST 请求。您可以使用 POST 请求方法发布新文章。相应地,与自动应答实现集成的客户网络服务平台可能会使用PUT指令来更新或删除自定义问候语。
GET请求
- GET 请求缓存是可能的。浏览器的历史记录包括 GET 请求。
- 可以为 GET 请求添加书签。
- 在处理关键材料时,切勿使用 GET 请求。
- GET 请求有长度限制。
- 仅通过 GET 请求进行数据查询
POST 方法
POST请求是一种向服务器发送信息以添加或更新资源的方法。HTTP请求的请求体中包含发布到服务器端的数据:
- POST请求的发布方法永远不会进入缓存。
- POST请求不会存储在浏览器的历史记录中。
- POST请求无法被书签收藏。
响应体
响应体是RESTful API的重要元素之一。请求的数据包含在响应体中。响应体可能包括与输出和输出逻辑端口相关的数据。
资源
Web API能够提供给用户的任何数据都被视为资源。例如,在Facebook API中,个人、页面、图片或评论都可能被视为资源。每个资源都有一个特定的术语,即资源标识符。
Web服务器
Web服务器是一个程序,它接受客户端的请求体,并存储消费者请求的资源。服务器可以通过 API 与客户端通信,而无需为客户提供直接访问其数据库中存储的信息的权限。当用户通过RESTful网络服务提交请求体时,服务器会向浏览器发送资源的状态的标准化描述。
这意味着服务器不会直接将确切的资源提交给客户端,而是反映其状态,即在特定时间戳下资源的状况。为了提高可读性,响应会以轻量级格式返回。
JSON(JavaScript对象表示法)因其既易于人类阅读又易于机器解析),并且在促进网络可访问性方面表现出色而得到广泛使用。JSON主要用于在Web应用程序和客户端应用程序中发送请求体。它与多种编程语言兼容。除了JSON之外,API的数据格式还包括XML、YAML、CSV、HTML和纯文本。API用户可以通过使用自定义媒体类型来选择他们希望的任何数据格式。
REST API 的历史
在REST之前,许多程序员不得不使用SOAP来整合API。构建、使用和调试SOAP是出了名的困难任务。幸运的是,在罗伊·菲尔德林(Roy Fielding)的指导下,一群程序员开发了REST,从而永远改变了API环境。
以下是REST API随时间发展的历史脉络:
REST 之前
程序员需要手动编写一个包含远程过程调用(RPC)的XML文件,以便使用SOAP连接Web API。之后,设计师会将他们的SOAP数据包发送到指定的端点。
2000 年
由 Roy Fielding 领导的程序员团队选择开发一个框架,使任何服务器都可以与其他服务器通信。他制定了REST API的规范。由于这些规范具有普遍性,因此软件开发变得更加容易。
2002 年
eBay 在 2002 年开发了 RESTful API,向其可能受益的任何网站开放其市场。正因为如此,另一家电子商务巨头 Amazon 对它产生了兴趣,并于 2002 年发布了其 RESTful API。
在 2004-2006 年
Flickr 的 RESTful Web 服务于 2004 年发布,允许作者快速将照片添加到他们的网站和社交媒体帖子中。当 Twitter 和 Facebook 注意到大量程序员正在扫描网站并制作“Frankenstein”API 时,它们在大约两年后都公开了他们的 API。
2006 年至今
RESTful Web 服务现在已被程序员广泛接受,他们使用这些 RESTful Web 服务来提高其应用程序和网站的性能。AppMaster促进了合作,并简化了API的构建,使您能够更快地完成构建)。
REST API 有什么用途?
RESTful网络服务的主要优势之一是它提供了极大的灵活性,使您能够更有效地使用这种RESTful API。以下是REST API用途的一些示例。
基于云的应用程序
由于其调用的无状态性,REST API 在云应用程序中具有优势。如果出现问题,无状态模块可以轻松重新安装和扩展以满足容量要求。结合了本地和基于互联网组件的软件程序是云应用程序。这种范式使用由Web浏览器访问的远程服务器和持续的互联网网络服务来执行指令。
云应用程序主机的传统位置是由第三方云计算网络运营商运行的远程计算机系统。邮件、文档共享和存储、订单输入、库存控制、Microsoft Word、客户关系管理 (CRM)、信息收集以及财务和会计是使用基于云的应用程序执行的工作示例。
REST 应用程序编程接口 (API) 可用于连接外部信息源和存储资源。程序员可以使用 REST API 将数据传输到其他程序以处理或分析计算,并将结果返回给软件程序,从而使云应用程序变得更小。经过测试的 API 强制实施主动一致性,这可以加快生产速度并产生实际结果。
一个典型的云应用程序实例就是Google Docs或Office 365。要使用Google Docs或Office 365,您只需要一台能够运行搜索引擎和互联网网络服务的电脑。计算机网络提供用户界面和操作,包括信息存储。您的公司可以使用云应用程序主机托管许多不同的云应用程
云服务
由于您需要通过API管理URL的处理方式来连接到资源,因此REST API对于云网络服务也同样有用。由于云应用程序的普及,RESTful网络服务架构未来很可能会成为标准。程序员使用RESTful网络服务通过互联网连接到云服务。开发人员编写代码,使用互联网提供商的API,提供必要的输入和变量,然后检查结果以确保操作按预期工作。
云服务是一种允许用户通过互联网访问客户端应用程序或网络服务的云计算形式,如计算基础设施、存储系统或跟踪系统。API(应用程序编程接口)定义了应用程序的功能和操作以及执行这些操作所需的具体细节)。为了维护客户端隐私和安全,API 通常依赖于 REST 或简单对象访问协议 (SOAP) 互操作性和权限机制,如 OAuth 2.0。
各种网络服务被称为“云服务”,它们在线提供给企业和消费者使用。这些网络服务旨在提供快速、经济的对工具和应用程序的访问,而无需硬件或基础设施。大多数员工使用云网络服务处理从电子邮件到文档协作的各种事务。
网络应用
这些网络API可以来自用户网络项目、iPhone应用、物联网设备或Windows Mobile,因为REST不依赖于客户端功能。您可以为您的业务创建架构,而不受特定客户端框架的限制。
REST API 示例
让我们讨论一个 REST API 示例。点击下面的链接向Open Trivia Database提出一个随机智力问题:此类 RESTful Web 服务用于提供公共 Web API。您的计算机将以 JSON 格式显示单独的测验问题及其回答。
使用任何 HTTP 浏览器(如 url),您可以发出以下查询并在响应正文中收到响应:https://opentdb.com/api.php?amount=1&category=18
网络服务的XML文件的响应体将包含所有员工的信息。
所有广泛使用的编程方言和开发者工具都有 HTTP 客户端库,例如 JavaScript 中的 retrieve、Node.js 和 Deno 以及 PHP 中的 file get contents()。由于JSON是机器可读的,因此可以在HTML或其他样式中显示之前读取和使用JSON响应。
Rest API 和 REST API
随着时间的推移,已经发展出许多数据传输方法。您可能遇到过 CORBA、SOAP 或 XML-RPC 等选项。大多数方法制定了严格的消息准则。Roy Fielding在2000年首次概述了REST,它比其他方法更简单。
它是一组针对RESTful网络服务的建议和限制,而不是一个规范。这些包括以下架构约束:
客户端-服务器分区
在 REST 架构下,客户端和网络服务器只能单向通信:客户端请求域控制器,控制器或服务器响应请求。网络服务器无法提交请求,客户也无法响应;客户启动所有连接。
RESTful网络服务通过简化它们之间的交互来保持客户和服务器的隔离。客户端计算机可以在不影响托管的情况下开发,服务器材料可以在不影响客户的情况下更改。
统一接口
根据此策略,所有查询和反应都必须遵循标准的 proweb 程序或设置其消息的样式。应用程序和服务器是用各种编程语言开发的,这些语言彼此之间表现不佳。统一接口是任何客户都可以用来与任何 REST API 交互的方言。
只有通过规范化的交互来翻译应用程序之间的请求和响应才成为可能。微小的差异会导致混乱和信息丢失,当网络API修改其请求程序时,解决方案将不得不升级它们的请求程序。一致的界面消除了这种可能性。
获取 https://www.googleapis.com/youtube/v3/channels?part=contentDetails 的访问权限
像所有REST客户端应用一样,这个请求包含两个数据。HTTP 技术是 GET。这描述了客户端希望对资源执行的操作。用户可以使用 4 种基本的 HTTP 方法:
HTTP 或超文本传输协议是大多数 REST API 的通用语言。HTTP并不是为REST而设计的。此外,REST 接受此数据传输作为 REST 感知应用程序的标准。对于将 HTTP 与 REST API 结合使用,客户端会以您可能熟悉的格式提交请求。例如,向 YouTube API 发出的视频信号请求如下所示:
- 使用 GET 命令获取资源。
- 使用 POST 命令创建新资源
- 使用 PUT 指令更改或持续更新现有资源
- 使用 DELETE 请求删除资源。
HTTP 方法指定要对特定资源采取的预期操作。HTTP 方法也称为 HTTB 动词。
URL 为 HTTP
统一资源标识符(URI),它标识了预期的资源)包含在 URL 中。在此方案中,URL 也是一个端点,因为它是 RESTful API 与服务用户接触的地方。
Query string(查询字符串):URL 包含查询字符串。查询字符串用于定义参数,这些参数被赋予值。
在接收并验证请求后,网络服务器返回有关目标资源的数据。通常,数据以称为JSON(JavaScript对象表示法)的结构返回。JSON以一种人类可以轻松阅读的可移植格式呈现资源的所有组件。
统一接口的原则
uniform 接口必须遵循以下参数:
- HATEOAS:超媒体作为应用程序状态的引擎超媒体是 RESTful Web 服务背后的引擎。这表明超媒体是客户想要理解以识别提供商的答案的全部。
- 只需向客户端提供客户端应用程序的第一个 URI。客户端应用程序应使用超链接持续驱动所有其他材料和活动。
- RESTful Web 服务不需要输入查询语言 (IDL),这与其他 API 不同
媒体类型是表示的数据格式的名称。媒体类型标识一个定义,该定义概述了应如何处理描述。使用REST的网络API就像超文本一样。可以解决的每个数据项都有一个位置,无论是直接的(如通过链接和标识属性)还是隐式的(例如,从媒体类型描述结构推导)。
- 自描述消息
- 客户端和服务器端之间的每个通信都应提供足够的数据来执行通信。因此,从客户端到服务器端的请求需要指定它尝试访问的资源及其特定目标。
此外,资源描述必须是自描述的;用户无需知道资源是一个人还是一件设备。相反,它应该按照关联的帮助的媒体类型做出响应。
因此,我们无疑会开发许多独特的媒体类型,通常每个资源一个媒体类型。每种形式的媒体都指定了一个标准的生产模式。例如,HTML定义了如何显示超文本以及浏览器如何处理每个组件。 - 识别资源
- 在客户和服务器之间的后续通信中提到的资源必须使用描述进行识别。为此,采用了统一资源标识符(URI)系统。换句话说,从服务器到客户的通信可能包括文档的HTML版本和一些信息,而不是服务器存储中的实际文件。
使用者可以很容易地理解 HTML 版本,因为它遵循 URI 模式。客户必须通过向服务器提供资源最终应如何显示来修改资源。这将使用户能够构建、检索、修改和删除资源。如果客户具有更改数据所需的授权,服务器应该满足查询。
无状态
使用 RESTful API 时,所有客户端请求都必须是临时的。因此,每个查询和响应正文都包含签订合同所需的所有数据,使得每个连接都是独立的。服务器不保留以前的HTTP请求记录;它将客户端发出的每个请求视为全新的查询。
由于服务器不必执行任何额外的任务来获取历史数据,因此无状态传输可以显著减少服务器所需的存储量,并增加响应可接受的可能性。这保证了这些交互的可扩展性:当他们的软件扩展并发出 HTTP 请求时,程序员不必担心使用更多的存储空间或给服务器带来负担。
分层的
到目前为止,我们已经将 Web API 查询定义为简单的客户端-服务器交换,尽管这有点过于简单化了。在这两个组织之间,通常有更多的服务器。这些平台或层用于管理和分散流量、添加保护以及执行各种其他关键任务。
根据此概念,无论中间存在多少层,发送给用户和目标服务器之间的消息必须以相似的方式结构化和处理。额外的层次应该与客户互动兼容。遵循这一规则的程序员可以更改服务器系统,而不会影响基本请求-响应过程。
可缓存
当客户浏览网站时,当内容保存在客户的计算机上时,就会发生缓存。当用户稍后再次访问该站点时,缓存材料会从内部存储器中快速加载,而不是再次从服务器下载。大多数大型网站都使用缓存来减少页面加载时间,同时节省服务器空间和带宽。
在开发 REST API 时,会考虑数据缓存。服务器给客户的响应应该说明给定资源是否可以存储以及可以存储多久。
按需代码
最后一个 REST 原则是不必要的。如果请求,API 的响应可以包含供客户端使用的软件代码。因此,客户可以在其后端执行客户端应用程序或程序。
如果 API 符合这组准则,则 API 被视为 RESTful API。但是,这些准则为程序员提供了很大的自由来修改其 RESTful API 的功能。REST API 与另一种流行的 Web API 技术简单对象访问协议的不同之处在于它们更灵活 (SOAP)。
端点共识
请考虑以下端点:
- /user/123\s
- /user/id/123\s
- /user/123\s
- /user/id/123\s
- /user/?id=123
所有这些都是客户端 123 检索数据的合法方法。当有更复杂的程序时,可能性的数量就会增加。例如,从条目 51 开始,按相反顺序显示 10 个姓氏以“A”开头并为公司运营的人员。
最后,您如何构建URL并不重要;您的RESTful API中的一致性很重要。在拥有许多程序员的大型软件系统中,这并不容易实现。RESTful API修改是不可避免的,但绝不能拒绝端点URL,因为这将导致依赖它们的应用程序停止工作。
REST API 版本控制
版本控制API是一种常见做法,以防止不兼容性。例如,/2.0/user/123替换了/user/123。旧端点和新端点都可以继续运行。因此,这迫使需要维护过去的重要APIs。旧版本最终可以被退役,但这个过程需要仔细考虑。
REST API 身份验证
任何设备都可以使用查询 API 在未经授权的情况下下载 quip。读取私有信息或允许编辑和删除查询的 API 不支持此功能。与 RESTful Web 服务位于同一域中的客户端程序的发送和接收 Cookie 的方式与 HTTP 请求相同。(请注意,必须在早期站点中为 Fetch() 指定 privileges restart 选项。可以验证 API 查询以确认用户已登录并具有所需的权限。
HTTP 基本身份验证:第三方程序必须使用不同的审批方案。一些流行的身份验证方法是:
- HTTP。在查询字段中给出一个base64编码的用户名:密码字符串作为HTTP Approval头的一部分。 API密钥:通过提供一个可能具有特殊权限或限制在一个站点上的RESTful
- API密钥,使得API可供第三方应用程序使用。每条消息都在查询字符串或HTTP头中包含密钥。(查询字符串是URL的一部分)。
- OAuth:在发出任何请求之前,向OAuth服务器发送一个客户ID和可能是一个客户密钥以获取凭据。OAuth身份随后在每个API请求中传递,直到它过期为止。
- JSON中的Internet令牌(JWT):查询头和响应头安全地传达数字签名的用户凭据。JWT允许服务器加密访问权限,无需查询数据库或使用其他身份验证机制。
使用场景会影响API的认证方式:
- 有时,第三方程序像其他已登录客户端一样处理,具有相同的权限和权利。例如,地图API可能会为请求的程序提供两个地点之间的路线指示。它必须验证该程序是合法用户,但不必验证客户端的凭据。
- 在其他情况下,第三方程序会向特定用户询问个人信息,例如邮件内容。REST APIs必须识别客户及其权限,但它们不需要关心调用程序。
REST API 安全性
RESTful网络服务为与您的软件互动并影响其行为提供了另一种方式。即使您的主机不是高等黑客攻击目标,行为不端的用户也可以每秒提交数百个请求并将其折叠。本文不涉及安全性,但标准的最佳程序包括:
- 使用 HTTPS
- 采用强身份验证机制
- CORS 可用于将客户呼叫限制到特定区域。
- 提供功能的必要性 — 即,不要
- 生成不必要的 DELETE 选项;验证所有 Endpoint URL 和正文信息。
- 通过在客户端 JavaScript 中不设置 API 凭证来阻止来自未识别扇区或 IP 地址的链接。
- 异常大的数据包被阻止。
- 考虑速率限制,其中来自同一 IP 地址或 API 凭证的请求限制为每分钟 N 个查询。
- 具有正确 HTTP 状态代码、缓存标头日志查询和不成功调查的响应
多个请求和不必要的数据
RESTful Web 服务的部署存在限制。响应可能包含比您请求的更多信息,或者需要多个请求才能获取所有信息。考虑一下允许用户访问创作者和书籍信息的 RESTful Web 服务;客户可以:
- 询问前 10 本书的信息,按购买顺序列出(畅销书优先)。答案中包含一组书籍以及每个作者的 ID。
- 要检索每个编写器的信息,请构建最多 10 个 /author/id 查询。应为父查询的每个响应生成 N 个 API 查询,其特征为“N+1 问题”。
如果这种情况经常使用,则可以修改 RESTful Web 服务以包含其生成的每本书的所有作者信息,包括姓名、性别、国籍、传记等。可能会提供关于他们以前书籍的更多信息,尽管这样做会大大增加响应负担。API可以被修改为使作者信息成为可选的。Author details=full以避免不必要的大答案。API设计者必须支持的选项数量可能是压倒性的。
结束语
现在,您全面了解了 REST API、REST API 的运行方式、REST API 示例、REST API 的用途、架构约束以及本教程中介绍的其他主题。程序员可能会觉得学习 API 既困难又令人生畏,但无代码平台 AppMaster 创建了一个新的可访问的 REST API 库,您可以在其中加深对一系列 REST API 的认识,以支持您进一步的专业发展。
在 AppMaster,我们试图提高 API 的可访问性和可用性。我们希望您了解、试验并意识到在您的职业和个人生活中使用 API 软件的好处。为了帮助您更快地设计更好的 Web API,AppMaster提高了协作效率并自动化了API生命周期的每个阶段。继续创造、进步并拓宽你对REST APIs的理解。