部署Nginx Plus作为API网关：Nginx

HTTP API和基于浏览器的流量之间的主要区别之一是如何将错误传达给客户端。当NGINX Plus作为API网关部署时，我们将其配置为以最适合API客户端的方式返回错误。

# Error responses 
 error_page 404 = @400; # Invalid paths are treated as bad requests 
 proxy_intercept_errors on; # Do not send backend errors to the client 
 include api_json_errors.conf; # API client friendly JSON error responses 
 default_type application/json; # If no content-type then assume JSON 

顶级API网关配置包括一个定义如何处理错误响应的部分。

第27行的指令指定当请求与任何API定义都不匹配时，NGINX Plus会返回错误而不是默认错误。此(可选)行为要求API客户端仅向API文档中包含的有效URI发出请求，并防止未经授权的客户端发现通过API网关发布的API的URI结构。

第28行指的是后端服务本身产生的错误。未处理的异常可能包含我们不希望发送到客户端的堆栈跟踪或其他敏感数据。此配置通过向客户端发送标准化错误来进一步提供保护。

完整的错误响应列表在第29行的include伪指令引用的单独配置文件中定义，其前几行如下所示。如果首选不同的错误格式，并且通过更改第30行上的default_type值以匹配，则可以修改此文件。您还可以在每个API的策略部分中使用单独的include指令来定义一组覆盖默认值的错误响应。

error_page 400 = @400; 
location @400 { return 400 '{"status":400,"message":"Bad request"}n'; } 
  
error_page 401 = @401; 
location @401 { return 401 '{"status":401,"message":"Unauthorized"}n'; } 
  
error_page 403 = @403; 
location @403 { return 403 '{"status":403,"message":"Forbidden"}n'; } 
  
error_page 404 = @404; 
location @404 { return 404 '{"status":404,"message":"Resource not found"}n'; } 

有了这种配置，客户端对无效URI的请求就会收到以下响应。

$ curl -i https://api.example.com/foo  
HTTP/1.1 400 Bad Request  
Server: nginx/1.13.10  
Content-Type: application/json  
Content-Length: 39  
Connection: keep-alive  
  
{"status":400,"message":"Bad request"} 

实施身份验证

（编辑：云计算网_韶关站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!