访问页面升级访问_容器化单页面应用中RESTful API的访问

最近在工作中，需要让运行在容器中的单页面应用程序能够访问外部的RESTful API。这个需求看起来并不困难，不过实现起来还是有些曲折的。在此，我就将这部分内容总结一下。

在入正题之前，有个一问题，就是为什么要将单页面应用放在容器中运行？这个问题其实跟“为什么要将应用程序容器化”是一个问题。简单来讲，容器化的应用程序可以运行在任何具有容器执行环境的宿主平台上，比如可以在Linux系统中运行容器，也可以在MacOS或者Windows下使用Docker Desktop for Mac或者Docker for Windows来运行容器化的应用程序。无论在什么平台中运行，容器化的应用程序都可以使用统一化的配置方式(比如环境变量、虚拟磁盘路径的挂载等)，并向外界提供一致的访问端点。将应用程序容器化最重要的一点是，通过它可以非常方便地将应用程序部署在云环境中，使应用程序具有很好的横向扩展能力，而且跨云的迁移也变得非常便捷。由此可见，通过容器的使用，我们可以采用不同的技术来实现应用程序的不同部分，然后可以得到统一的部署和运维体验，这一点对于微服务架构的实践有着非常深远的意义。在工作中，我所接触的系统包含了多个团队的贡献，有的团队使用nodejs，有的团队使用Scala，有的团队使用Go，这些独立分散的项目都以一个个独立的服务进行开发和交付，最终通过容器化的途径实现了整个应用程序的一体化部署。当然，与各种软件架构风格类似，微服务架构也是有利有弊，并不是所有的项目和团队都应该采用这种架构，还是应该根据项目和团队的实际情况来决定软件系统的架构方式，这部分内容就不在此过多讨论了。

回到本文的主题，我会通过一个案例来总结在不同场景下，容器化单页面应用访问RESTful API的方式。

我们的案例是一个提供名称列表的RESTful API，外加一个显示名称列表的前端单页面应用。不必理会什么是“名称列表”，它只不过是一个字符串列表。在这里我们也不必关心这个字符串列表包含哪些内容，只要让单页面应用能够访问到这个RESTful API即可。继续阅读本文，你将了解到这个案例是多么的简单。

RESTful API

首先创建一个能够返回名称列表的RESTful API，实现方式有很多种，我选择我熟悉的ASP.NET Core Web API项目来创建RESTful API。在命令行执行以下命令以创建一个ASP.NET Core Web API的项目：

dotnet new webapi --name NameList.Service

然后，使用Visual Studio Code编辑器打开该项目，删除ValuesController，然后新增NamesController，当然也可以基于ValuesController修改，代码如下：

using System; using System.Collections.Generic; using System.Linq; using System.Threading.Tasks; using Microsoft.AspNetCore.Mvc; namespace NameList.Service.Controllers {     [Route("api/[controller]")]     [ApiController]     public class NamesController : ControllerBase     {         [HttpGet]         public ActionResultstring>> Get()             => new string[] { "Brian", "Frank", "Sunny", "Chris" };     } }

目前我们不需要启用HTTPS重定向，将其从Startup.cs中删除，同时调整launchSettings.json文件，直接侦听http://*:5000，然后使用dotnet run命令，启动RESTful API，使用cURL工具进行测试：

1 2	$ curl -s http://localhost:5000/api/names ["Brian","Frank","Sunny","Chris"]

API调用成功。为了后续的实验能够顺利进行，我们在服务端启用CORS：

public class Startup<