什么是REST API

REST API响应

响应的有效负载可以是任何实用的东西：数据、HTML、图像、音频文件等等。数据响应通常是JSON编码，但也可以使用XML，CSV，简单字符串或任何其他格式。你可以允许在请求中指定返回格式。比如说，/user/123?format=json 或者 /user/123?format=xml 。

还应该在响应头中设置适当的HTTP状态码。200 OK用于成功的请求，尽管当记录被创建时也可以返回201 Created 。当发生错误时应该返回适当的状态码，比如说400 Bad Request，404 Not Found，401 Unauthorized等等。

其他HTTP头部可以被设置包括Cache-Control或Expires，以指定响应在被视为过期之前可以缓存多长时间。

然而，并没有严格的规则。端点URL、HTTP方法、body对象和响应类型可以随心所欲地实现。例如，POST、PUT和PATCH通常可以互换使用，如有必要任何一个都可以用来创建或更新记录。

Hello World示例

下面的Node.js代码使用Express框架创建了一个RESTful网络服务。一个单一的/hello/端点对HTTP GET请求作出响应。

确保已安装Node.js，创建名为restapi的新文件夹。在该文件夹中创建一个新的package.json文件，内容如下：

{

"name": "restapi",

"version": "1.0.0",

"description": "REST test",

"scripts": {

"start": "node ./index.js"

},

"dependencies": {

"express": "4.18.1"

}

}

在命令行中运行npm install 来拉取依赖，然后创建index.js文件，包括以下代码：

// simple Express.js RESTful API

'use strict';

// initialize

const

port = 8888,

express = require('express'),

app = express();

// /hello/ GET request

app.get('/hello/:name?', (req, res) =>

res.json(

{ message: `Hello ${req.params.name || 'world'}!` }

)

);

// start server

app.listen(port, () =>

console.log(`Server started on port ${port}`);

);

使用npm start从命令行启动该应用程序，并在浏览器中打开http://localhost:8888/hello/。响应GET请求时，会显示以下JSON：

{

"message": "Hello world!"

}

API也允许自定义名字，因此http://localhost:8888/hello/everyone/会返回：

{

"message": "Hello everyone!"

}

客户端REST请求和CORS

考虑在浏览器中启动以下HTML页面，URL是http://localhost:8888/ ：

fetch调用发出同样的API请求，浏览器控制台显示{ message: "Hello world!" }，正如你所期望的那样。

然而，假设你的RESTful网络服务现在被放在网络上，域名是http://mydomain.com/hello/。页面的JavaScript fetch()URL也相应地改变了，但在浏览器中打开http://localhost:8888/，现在会返回控制台错误Cross-Origin Request Blocked。

为了安全起见，浏览器只允许客户端的XMLHttpRequest和Fetch API 调用页面所在的同域请求。

幸运的是，跨源资源共享（CORS）使我们能够规避这一安全限制。设置Access-Control-Allow-OriginHTTP响应头来告诉浏览器允许该请求。它可以设置为一个特定的域，或者设置为所有的域*。

可以更改网络服务器API代码，以允许运行在任何域名的任何客户端脚本进行访问：

// /hello/ GET request

app.get('/hello/:name?', (req, res) =>

res

.append('Access-Control-Allow-Origin', '*')

.json(

{ message: `Hello ${req.params.name || 'world'}!` }

)

);

或者，Express.js中间件函数可以将头部附加到每个端点请求：

// enable CORS

app.use((req, res, next) => {

res.append('Access-Control-Allow-Origin', '*');

next();

});

// /hello/ GET request

// ...

注意，浏览器向REST API发出两个请求：

对同一URL的HTTP OPTIONS请求确定Access-Control-Allow-Origin HTTP响应头是否有效。

实际的REST调用。

当你的服务器收到一个OPTIONS请求方法时，它可以设置Access-Control-Allow-Origin HTTP响应头返回一个假的空响应，以确保工作不被重复。

REST API挑战

REST的成功很大程度上归功于它的简单性。开发人员可以自由地实现RESTful API，但这可能会导致进一步的挑战。要深入了解实现策略，请看13个构建RESTful API的最佳实践。

端点共识

考虑下面的端点：

/user/123

/user/id/123

/user/?id=123

所有这些都是为用户123获取数据的有效选项。当你有更复杂的操作时，组合的数量会进一步增加。

归根结底，你如何格式化URL并不重要，但整个API的一致性很重要。这对有许多开发人员的大型代码库来说是个挑战。

REST API版本控制

API的变化是不可避免的，但端点的URL永远不应该失效，否则会破坏使用它们的应用程序。

为了避免兼容性问题，API通常是有版本的。例如，/2.0/user/123取代了/user/123。新的和旧的端点都可以保持活跃。不幸的是，这样就有必要维护多个历史API。旧的版本最终可以被废弃，但整个过程需要仔细规划。

REST API认证

上面显示的测试API是开放的：任何系统都可以在未经授权的情况下获取数据。这对于访问私有数据或允许更新和删除请求的API是不可行的。

与RESTful API处于同域的客户端应用程序将像其他HTTP请求一样发送和接收cookies。(请注意，旧版浏览器中的Fetch()需要设置credentials初始选项）。因此，一个API请求可以被验证，以确保一个用户已经登录并拥有适当的权限。

第三方应用程序必须使用替代的授权方法。常见的认证选项包括：

HTTP基本身份验证。在请求头中传递一个包含base64编码的username:password字符串的 HTTPAuthorization头。因为base64很容易被解码，基本（Basic）认证应该只和其他安全机制一起使用，比如HTTPS/SSL。

API密钥。第三方应用程序通过发布一个密钥来获得使用API的许可，这个密钥可能有特定的权限或被限制在一个特定的域。密钥在每个请求中的HTTP头或查询字符串中被传递。

OAuth。在发出任何请求之前，通过向OAuth服务器发送一个客户ID和可能的客户秘密，获得一个令牌。然后，OAuth令牌会随每个API请求一起发送，直到过期。

JSON Web Tokens (JWT)。数字签名的认证令牌在请求和响应头中安全地传输。JWT允许服务器对访问权限进行编码，因此不需要调用数据库或其他授权系统。

API身份验证将根据使用上下文而有所不同：

在某些情况下，第三方应用程序被视为像任何其他具有特定权利和权限的登录用户。例如，一个地图API可以将两点之间的方向返回给调用的应用程序。它必须确认该应用程序是一个有效的客户端，但不需要检查用户凭证。

在其他情况下，第三方应用程序正在请求用户的私有数据，如电子邮件内容。REST API必须识别用户和他们的权利，但它可能不关心哪个应用程序在调用API。

REST API安全性

RESTful API提供了另一种访问和操作你的应用程序的途径。即使它不是一个引人注目的黑客目标，一个行为不良的客户端也可能每秒发送数以千计的请求，并使你的服务器崩溃。

安全性超出了本文的范围，但常见的最佳实践包括：

使用HTTPS。

使用健壮的身份验证方法。

使用CORS来限制客户端对特定域的调用。

提供最少的功能，也就是不要创建不需要的DELETE选项。

验证所有端点URL和body对象。

避免在客户端JavaScript中暴露API令牌。

阻止来自未知域名或IP地址的访问。

阻止意外的大型有效负载。

考虑速率限制，也就是使用同一API令牌或IP地址的请求被限制在每分钟N个以内。

以适当的HTTP状态代码和缓存头进行响应。

记录请求并调查失败情况。

多个请求和不必要的数据

RESTful APIs受到其实现的限制。响应可能包含比你需要的更多的数据，或者需要进一步的请求来访问所有数据。

考虑一个RESTful API，它提供对作者和书籍数据的访问。为了显示前10名畅销书的数据，客户端可以：

请求按销售量数量订购的前10/book/的详细信息（最畅销的在前）。响应包含有每个作者ID的书籍列表。

最多组成10个/author/{id}请求以获取每个作者的详细信息。

这被称为N+1问题；必须为父请求中的每个结果提出N个API请求。

为了避免不必要的大的响应，可以调整API使作者的细节是可选的。例如，?author_details=full。API作者需要满足的选项的数量可能会变得令人困惑。

GraphQL是否更好？

REST的难题导致Facebook创建了GraphQL--一种网络服务查询语言。把它看作是网络服务的SQL：一个单一的请求定义了你所需要的数据以及你希望它如何返回。

GraphQL解决了RESTful APIs带来的一些挑战，尽管它引入了其他挑战。例如，很难对GraphQL响应进行缓存。

你的客户不太可能有与Facebook类似的问题，所以一旦RESTful API发展到超出其实际限制时，GraphQL可能值得考虑。

REST API链接和开发工具

有许多工具可以帮助所有语言的RESTful API开发。值得注意的选项包括：

Swagger：帮助设计、记录、模拟、测试和监控REST APIs的各种工具。

Postman：一个RESTful API测试应用程序。

Hoppscotch：一个开源的、基于web的Postman替代品。

还有大量的公共REST API，集合了笑话、货币转换、地理编码、政府数据以及你能想到的每一个主题。许多是免费的，尽管有些需要你注册一个API密钥或使用其他认证方法。分类列表包括：

Any API

API list

Public APIs

Google APIs Explorer

在实现你自己的网络服务之前，在你自己的项目中尝试使用一些RESTful API。或者考虑跟随Facebook、GitHub、Google和其他许多巨头的脚步，建立一个属于自己的RESTful API。

下一篇文章中，会翻译分享13个构建RESTful API的最佳实践，欢迎关注。

以上就是全部内容，如果对你有所帮助，欢迎点赞收藏转发~