技术领域

[0001] 本申请要求 2018年 4月 4日递交、 发明名称为“网页访问方法及装置”的中国专 利 申请 CN 201810295338.2的优先权， 在此通过引用将其全部内容合并于此。

[0002] 本申请涉及计算机技术领域， 尤其涉及一种网页访问方法及装置。

背景技术

[0003] 随着互联网的兴起， 互联网应用应运而生。 所谓的互联网应用采用前端 （用户 端） /后端 （服务器端） 通信模式， 为客户提供多样化需求。

[0004] 具体而言， 后端为前端存储相关网页的网页资源， 只要前端与后端之间进行数 据传输， 便能够通过前端所存储的网页链接地址 （URL） ， 得到存储于后端中 对应网页链接地址的网页资源， 由此实现对网页的在线访问， 从而使得用户借 由互联网应用享受该网页所提供的各种线上服 务。

[0005] 然而， 就前端与后端之间进行的数据传输而言， 前端与后端耦合性很高， 维护 成本高。

[0006] 举例来说， 前端接收到的数据不够纯净， 即还包含了部分本应该由后端处理的 数据 （下文简称为后端数据） ， 为此， 前端需要将该后端数据进行数据格式转 换， 形成前端能够支持的转换数据之后， 方可进行后续处理。 同理， 后端接收 到的数据也不够纯净， 还包含了部分本应该由前端处理的数据 （下文简称为前 端数据） ， 在进行处理前也需要数据格式转换。

[0007] 基于此， 发明人意识到， 对于开发阶段来说， 由于前端进行处理的数据不仅包 含前端数据， 还涉及部分后端数据， 导致前端的开发必须依赖于后端的开发， 反过来也可以说后端的开发取决于前端的开发 ， 即前后端耦合性很高， 这势必 造成网页访问过程中数据格式转换的复杂度， 进而导致网页访问效率低下。 发明概述

技术问题

问题的解决方案 技术解决方案

[0008] 为了解决上述技术问题， 本申请的一个目的在于提供一种网页访问方法 及装置

[0009] 其中， 本申请所采用的技术方案为：

[0010] 一方面， 一种网页访问方法， 包括： 前端获取互联网应用向后端发起的网页访 问请求； 根据所述网页访问请求中的网页链接地址在后 端中进行网页资源定位 ， 接收所述后端返回的网页资源， 所述网页资源仅包含前端数据； 通过与后端 分离的表现层对仅包含前端数据的网页资源在 所述互联网应用中进行网页显示

[0011] 另一方面， 一种网页访问装置， 包括： 请求发起模块， 配置为前端获取互联网 应用向后端发起的网页访问请求； 资源接收模块， 配置为根据所述网页访问请 求中的网页链接地址在后端中进行网页资源定 位， 接收所述后端返回的网页资 源， 所述网页资源仅包含前端数据； 网页显示模块， 配置为通过与后端分离的 表现层对仅包含前端数据的网页资源在所述互 联网应用中进行网页显示。

[0012] 另一方面， 一种网页访问装置， 包括处理器及存储器， 所述存储器上存储有计 算机可读指令， 所述计算机可读指令被所述处理器执行时实现 如上所述的网页 访问方法。

[0013] 另一方面， 一种计算机可读存储介质， 其上存储有计算机程序， 所述计算机程 序被处理器执行时实现如上所述的网页访问方 法。

[0014] 在上述技术方案中， 由于后端返回的网页资源仅包含前端数据， 使得前端接收 到纯净数据， 并且用于网页显示的表现层与后端分离， 以此避免前后端耦合性 过高， 有效地降低了网页访问过程中的复杂度， 进而解决了现有技术中因前后 端耦合性过高而导致网页访问效率低下的问题 。

[0015] 应当理解的是， 以上的一般描述和后文的细节描述仅是示例性 和解释性的， 并 不能限制本申请。

发明的有益效果

对附图的简要说明

附图说明 [0016] 此处的附图被并入说明书中并构成本说明书的 一部分， 示出了符合本申请的实 施例， 并于说明书一起用于解释本申请的原理。

[0017] 图 1是根据本申请所涉及的实施环境的示意图。

[0018] 图 2是根据一示例性实施例示出的一种终端的硬� �结构框图。

[0019] 图 3是根据一示例性实施例示出的一种服务器的� �件结构框图。

[0020] 图 4是根据一示例性实施例示出的一种网页访问� �法的流程图。

[0021] 图 5是根据一示例性实施例示出的另一种网页访� �方法的流程图。

[0022] 图 6是图 5对应实施例中步骤 430在一个实施例的流程图。

[0023] 图 7是图 5对应实施例中步骤 430在另一个实施例的流程图。

[0024] 图 8是图 4对应实施例中步骤 350在一个实施例的流程图。

[0025] 图 9是根据一示例性实施例示出的一种网页访问� �置的框图。

[0026] 图 10是根据一示例性实施例示出的一种网页访问� ��置的结构框图。

[0027] 通过上述附图， 已示出本申请明确的实施例， 后文中将有更详细的描述， 这些 附图和文字描述并不是为了通过任何方式限制 本申请构思的范围， 而是通过参 考特定实施例为本领域技术人员说明本申请的 概念。

发明实施例

本发明的实施方式

[0028] 这里将详细地对示例性实施例执行说明， 其示例表示在附图中。 下面的描述涉 及附图时， 除非另有表示， 不同附图中的相同数字表示相同或相似的要素 。 以 下示例性实施例中所描述的实施方式并不代表 与本申请相一致的所有实施方式 。 相反， 它们仅是与如所附权利要求书中所详述的、 本申请的一些方面相一致 的装置和方法的例子。

[0029] 图 1为一种网页访问方法所涉及的实施环境的示� �图。 该实施环境包括终端 （ 即前端） 100和服务器端 （即后端） 200。

[0030] 其中， 终端 100可以是笔记本电脑、 平板电脑、 智能手机、 台式电脑或者其他 可供互联网应用运行的电子设备， 在此不进行限定。

[0031] 终端 100与服务器端 200之间建立通信连接， 该通信连接包括但不限于无线网络 连接、 有线网络连接等， 进而通过所建立的通信连接进行数据传输， 例如， 通 过通信连接传输网页资源等。

[0032] 具体地， 终端 100利用运行的互联网应用， 向服务器端 200发起网页访问请求， 以获取服务器端 200中的网页资源， 进而控制该网页资源在互联网应用中进行网 页显示。

[0033] 请参阅图 2， 图 2是根据一示例性实施例示出的一种终端的框� �。

[0034] 需要说明的是， 该终端 100只是一个适配于本申请的示例， 不能认为是提供了 对本申请的使用范围的任何限制。 该终端 100也不能解释为需要依赖于或者必须 具有图 2中示出的示例性的终端 100中的一个或者多个组件。

[0035] 如图 2所示， 终端 100包括存储器 101、 存储控制器 103、 一个或多个 （图 2中仅 示出一个） 处理器 105、 外设接口 107、 射频模块 109、 定位模块 111、 摄像模块 1 13、 音频模块 115、 触控屏幕 117以及按键模块 119。 这些组件通过一条或多条通 讯总线 /信号线 121相互通讯。

[0036] 其中， 存储器 101可用于存储计算机程序以及模块， 如本申请示例性实施例中 的基于移动终端的客户数据安全访问方法及装 置对应的计算机可读指令及模块 ， 处理器 105通过运行存储在存储器 101内的计算机可读指令， 从而执行各种功 能以及数据处理， 即完成基于移动终端的客户数据安全访问方法 。

[0037] 存储器 101作为资源存储的载体， 可以是随机存储器、 例如高速随机存储器、 非易失性存储器， 如一个或多个磁性存储装置、 闪存、 或者其它固态存储器。 存储方式可以是短暂存储或者永久存储。

[0038] 外设接口 107可以包括至少一有线或无线网络接口、 至少一串并联转换接口、 至少一输入输出接口以及至少一 USB接口等， 用于将外部各种输入 /输出装置稱 合至存储器 101以及处理器 105， 以实现与外部各种输入 /输出装置的通信。

[0039] 射频模块 109用于收发电磁波， 实现电磁波与电信号的相互转换， 从而通过通 讯网络与其他设备进行通讯。 通信网络包括蜂窝式电话网、 无线局域网或者城 域网， 上述通信网络可以使用各种通信标准、 协议及技术。

[0040] 定位模块 111用于获取终端 100的当前所在的地理位置。 定位模块 111的实例包 括但不限于全球卫星定位系统 （GPS） 、 基于无线局域网或者移动通信网的定位 技术。 [0041] 摄像模块 113隶属于摄像头， 用于拍摄图片或者视频。 拍摄的图片或者视频可 以存储至存储器 101内， 还可以通过射频模块 109发送至上位机。

[0042] 音频模块 115向用户提供音频接口， 其可包括一个或多个麦克风接口、 一个或 多个扬声器接口以及一个或多个耳机接口。 通过音频接口与其它设备进行音频 数据的交互。 音频数据可以存储至存储器 101内， 还可以通过射频模块 109发送

[0043] 触控屏幕 117在终端 100与用户之间提供一个输入输出界面。 具体地， 用户可通 过触控屏幕 117进行输入操作， 例如点击、 触摸、 滑动等手势操作， 以使终端 10 0对该输入操作进行响应。 终端 100则将文字、 图片或者视频任意一种形式或者 组合所形成的输出内容通过触控屏幕 117向用户显示输出。

[0044] 按键模块 119包括至少一个按键， 用以提供用户向终端 100进行输入的接口， 用 户可以通过按下不同的按键使终端 100执行不同的功能。 例如， 声音调节按键可 供用户实现对终端 100播放的声音音量的调节。

[0045] 可以理解， 图 2所示的结构仅为示意， 终端 100还可包括比图 2中所示更多或更 少的组件， 或者具有与图 2所示不同的组件。 图 2中所示的各组件可以采用硬件 、 软件或者其组合来实现。

[0046] 图 3是根据一示例性实施例示出的一种服务器 200的硬件结构框图。 需要说明的 是， 该服务器 200只是一个适配于本申请的示例， 不能认为是提供了对本申请的 使用范围的任何限制。 该服务器 200也不能解释为需要依赖于或者必须具有图 3 中示出的示例性的服务器 200中的一个或者多个组件。

[0047] 该服务器 200的硬件结构可因配置或者性能的不同而产生 较大的差异， 如图 3所 示， 服务器 200包括： 电源 210、 接口 230、 至少一存储器 250、 以及至少一中央 处理器 (CPU, Central Processing Units) 270。

[0048] 其中， 电源 210用于为服务器 200上的各硬件设备提供工作电压。

[0049] 接口 230包括至少一有线或无线网络接口 231、 至少一串并转换接口 233、 至少 一输入输出接口 235以及至少一 USB接口 237等， 用于与外部设备通信。

[0050] 存储器 250作为资源存储的载体， 可以是只读存储器、 随机存储器、 磁盘或者 光盘等， 其上所存储的资源包括操作系统 251、 应用程序 253及数据 255等， 存储 方式可以是短暂存储或者永久存储。 其中， 操作系统 251用于管理与控制服务器 200上的各硬件设备以及应用程序 253， 以实现中央处理器 270对海量数据 255的 计算与处理， 其可以是 Windows ServerTM、 Mac OS XTM、 UnixTM、 LinuxTM 、 FreeBSDTM等。 应用程序 253是基于操作系统 251之上完成至少一项特定工作 的计算机程序， 其可以包括至少一模块 （图 3中未示出） ， 每个模块都可以分别 包含有对服务器 200的一系列计算机可读指令。 数据 255可以是存储于磁盘中的 照片、 图片等。

[0051] 中央处理器 270可以包括一个或多个以上的处理器， 并设置为通过总线与存储 器 250通信， 用于运算与处理存储器 250中的海量数据 255。

[0052] 如上面所详细描述的， 适用本申请的服务器 200将通过中央处理器 270读取存储 器 250中存储的一系列计算机可读指令的形式来完 成网页访问方法。

[0053] 此外， 通过硬件电路或者硬件电路结合软件也能同样 实现本申请， 因此， 实现 本申请并不限于任何特定硬件电路、 软件以及两者的组合。

[0054] 请参阅图 4, 在一示例性实施例中， 一种网页访问方法适用于图 1所示实施环境 的终端， 该终端的结构可以如图 2所示。

[0055] 该种网页访问方法可以由终端 （即前端） 执行， 可以包括以下步骤：

[0056] 步骤 310, 前端获取互联网应用向后端发起的网页访问请 求。

[0057] 如前所述， 互联网应用采用前端 /后端通信模式， 为客户提供多样化需求。 例 如， 后端为前端存储相关网页的网页资源， 只要前端与后端交互， 便能够获得 后端中的网页资源， 由此实现用户对网页的在线访问， 进而使得用户借由互联 网应用享受网页所提供的各种线上服务。

[0058] 由此， 网页访问请求， 是用户为了对网页进行在线访问而控制运行于 前端的互 联网应用向后端发起的。 该网页访问请求指示了互联网应用所请求访问 的网页 ， 以便于后续能够后端返回互联网应用所请求访 问网页的网页资源。 例如， 互 联网应用可以是保险营销应用， 则网页可以是保单销售网页或者保单售后网页 等等。

[0059] 应当理解， 后端所存储网页的网页资源是海量的， 不同网页资源的存储位置各 不相同。 因此， 网页访问请求是根据网页资源的存储位置生成 的， 也可以理解 为， 网页访问请求中携带了网页资源的存储位置。

[0060] 网页链接地址， 即指示了网页资源的存储位置， 被用于在后端中进行网页资源 的定位。 也就是说， 不同的网页资源具有不同的网页链接地址， 即网页链接地 址实现了对网页资源在后端中的存储位置的唯 一标识， 由此， 便能够基于网页 链接地址唯一地得到后端中存储的网页资源。

[0061] 步骤 330, 根据网页访问请求中的网页链接地址在后端中 进行网页资源定位， 接收后端返回的网页资源。

[0062] 对于后端而言， 在接收到前端所发送的网页访问请求之后， 将从该网页访问请 求中提取得到网页链接地址， 进而便能够根据网页链接地址对网页资源进行 定 位。

[0063] 定位， 即是指针对后端中存储的海量网页资源所对应 的存储位置， 按照网页链 接地址指示的网页资源的存储位置进行查找， 以获得存储于该存储位置的网页 资源。

[0064] 对于前端而言， 当后端返回网页资源， 便相应地接收到该网页资源。 其中， 该 网页资源仅包含前端数据。

[0065] 网页资源仅包含前端数据， 是指前端所接收到的数据是纯净的， 即不包含后端 数据， 也可以理解为， 前端接收到的数据不存在本应该由后端处理的 数据， 以 此达到前后端分离的目的。

[0066] 步骤 350, 通过与后端分离的表现层对仅包含前端数据的 网页资源在互联网应 用中进行网页显示。

[0067] 其中， 所谓的表现层指示了表现网页资源的形式。

[0068] 举例来说， 网页资源是文本， 则表现层所指示的网页资源的表现形式可以是 txt 格式， 使得互联网应用中通过 txt格式进行文本显示， 或者， 网页资源是图片， 则表现层所指示的网页资源的表现形式可以是 jpg格式， 使得互联网应用中通过 j pg格式进行图片显示。

[0069] 可以理解， 网页显示主要是在前端中进行， 因此， 本实施例中， 表现层与后端 分离。

[0070] 具体地， 在前端独立于后端进行的数据开发中， 由于所开发数据可能会传输至 后端， 则将所开发数据与用于网页显示的表现层解耦 合， 以形成与后端分离的 表现层。

[0071] 换而言之， 与后端分离的表现层完全由前端进行维护， 而不需要依赖于后端， 相应地， 后端接收到的由前端独立开发的数据将不存在 本应该由前端处理的数 据 （例如表现层相关数据） ， 以此进一步地达到前后端分离的目的。

[0072] 在上述实现过程中， 通过仅包含前端数据的网页资源、 以及与后端分离的表现 层， 实现了前后端的解耦合， 使得网页访问过程中复杂度有效地降低， 从而解 决了现有技术中因前后端耦合性过高而导致网 页访问效率低下的问题。

[0073] 请参阅图 5， 在一示例性实施例中， 步骤 330之前， 上述方法还可以包括以下步 骤：

[0074] 步骤 410, 后端独立于前端进行数据开发， 生成网页资源。

[0075] 其中， 网页资源仅包含符合标准数据格式的前端数据 。

[0076] 步骤 430, 在进行数据独立开发的后端中部署通信接口， 以通过通信接口进行 网页资源的传输。

[0077] 也就是说， 在后端独立于前端进行的数据开发中， 由于网页资源被用于前端中 进行网页显示而需要传输至前端， 则生成的网页资源仅包含前端数据， 进而使 得前端所接收到的数据是纯净的， 以此达到前后端分离的目的。

[0078] 可选地， 由于前后端分离， 前端与后端之间的数据交互通过统一的通信接 口实 现， 不仅降低了数据传输的复杂度， 而且有利于后续数据格式转换， 进而有利 于进一步地提高网页访问效率。

[0079] 标准数据格式由通信接口配置， 即不同通信接口所支持的标准数据格式不同， 则为前端数据配置的标准数据格式也有所区别 。 例如， 通信接口为 API接口， 相 应地， 为前端数据所配置的标准数据格式可以是 JSON、 XML等。

[0080] 在一实施例的具体实现中， 对于后端而言， API接口为 restful风格。

[0081] 如图 6所示， 步骤 430可以包括以下步骤：

[0082] 步骤 431， 进行 API接口的通信协议配置。

[0083] 在前后端分别部署了统一的 API接口之后， 将为该统一的 API接口配置通信协议 ， 使得该统一的 API接口进行数据传输时符合所配置的通信协议 ， 从而实现高效 的数据传输。

[0084] 例如， 通信协议为 http协议或者 https协议。

[0085] 步骤 433， 对配置了通信协议的 API接口进行域名部署。

[0086] 域名， 是对后端所在的位置 （电子位置 /地理位置） 进行唯一地标识， 例如， 前端通过域名直接访问到后端。

[0087] 域名部署， 即是指在域名中部署配置了通信协议的 API接口， 使得访问是基于 该域名中部署的 API接口， 例如， 前端通过域名所部署的 API接口直接访问到后 端的该 API接口。

[0088] 具体而言， 域名部署， 将配置了通信协议的 API接口部署于主域名， 或者， 针 对不进行扩展的 API接口， 还可以将配置了通信协议的 API接口部署于主域名的 下一级中。

[0089] 例如， 对于 https://apil.example.com来说， API接口为 apil接口， 为 apil接口所配 置的通信协议是 https协议， 该配置了 https协议的 apil接口部署于主域名 example.c 0111中 _°

[0090] 针对 http://example.org/api2/而言， API接口为 api2接口， 为 api2接口所配置的通 信协议是 http协议， 该配置了 http协议的 api2接口则部署于主域名的下一级中。

[0091] 在此补充说明的是， API接口， 本质上是操作系统提供给应用程序的接口， 进 而使得应用程序通过调用 API接口而触发操作系统去执行应用程序指令， 由此， 根据应用程序指令的不同， API接口所提供的调用服务也随之变化， 如果 API接 口所提供的调用服务相对简单且较为固定， 即视该 API接口为不进行扩展的 API 接口。

[0092] 步骤 435， 在部署了 API接口的域名中添加网页资源的路径和操作类 型。

[0093] 其中， 网页资源的路径即表示网页资源在后端中的存 储位置， 使得前端能够通 过域名中网页资源的路径访问到存储于后端的 相应网页资源。

[0094] 操作类型是指后端对网页资源可执行的操作， 包括但不限于： 资源提取、 资源 新建、 资源更新、 资源删除等操作。

[0095] 可选地， 如图 7所示， 步骤 430还可以包括以下步骤：

[0096] 步骤 437， 在部署了 API接口的域名中添加过滤信息。 [0097] 如果网页资源过多， 后端不可能将所有网页资源返回给前端， 为此， 过滤信息 是用于进行网页资源的过滤， 该过滤信息包括但不限于： 返回数量、 筛选条件 、 返回网页资源所开始位置、 返回网页资源的排序顺序等等。

[0098] 步骤 439， 在部署了 API接口的域名中添加状态码信息。

[0099] 状态码信息包括后端向前端返回的状态码， 以此指示后端对网页资源所执行操 作和 /或操作执行结果。

[0100] 例如， 状态码为 200, 则表示后端向前端返回所请求的网页资源成功 ， 或者， 状态码为 400, 则表示后端未进行网页资源的新建操作或者更 新操作。

[0101] 通过上述实施例的配合， 实现了后端中 restful风格的 API接口部署， 进而为前端 进行网页访问提供了依据， 即前端通过包含了该 restful风格的 API接口的域名便 能够请求后端返回网页相应的网页资源。

[0102] 需要说明的是， 步骤 437〜步骤 439的执行顺序可以调整， 本实施例并非对此加 以限定。

[0103] 在一示例性实施例中， 步骤 350之前， 上述方法还可以包括以下步骤：

[0104] 前端独立于后端进行的数据开发中， 将所开发数据与用于网页显示的表现层解 耦合， 形成与后端分离的表现层。

[0105] 解耦合， 是指将用于网页显示的表现层与前端所开发数 据分离， 进而使得传输 至后端的数据不会包含用于网页显示的表现层 相关数据， 从而使得后端所接收 到的数据是纯净的， 即不存在本应该由前端进行处理的数据， 例如， 用于网页 显示的表现层所相关的数据。

[0106] 解耦合所采用的软件架构， 包括但不限于： MVC (Model- View-Controller) 、 MVP (Model-View-Presenter) 、 MVVM ( Model- View- Vie wModel) 模式。

[0107] 在一示例性实施例中， 步骤 350之前， 上述方法还可以包括以下步骤：

[0108] 前端对与后端分离的表现层进行组件封装。

[0109] 应当理解， 网页显示过程中， 除了网页资源的展示， 还涉及界面元素的展示， 例如， 界面元素包括菜单栏、 任务栏、 视图按钮等等。 相应地， 与后端分离的 表现层， 除了指示网页资源的表现形式， 还将指示界面元素的显示风格。

[0110] 由此， 本实施例中， 表现层所进行的组件封装， 是指进行界面元素的组件化， 使得相同界面元素通过表现层进行网页显示过 程中具有统一的显示风格， 不仅 简化了表现层开发的复杂度， 而且有利于增强界面元素的灵活性、 美观性， 进 而有利于提升用户的访问体验。

[0111] 在一应用场景中， 将保单销售页面和保单售后页面中相同的软电 话拨打按钮统 一封装为组件 A， 该组件 A以电话图标进行显示， 进而使得保单销售页面和保单 售后页面中的软电话拨打按钮在网页显示过程 中均显示为电话图标。

[0112] 请参阅图 8， 在一示例性实施例中， 步骤 350可以包括以下步骤：

[0113] 步骤 351， 前端通过自身所部署的通信接口进行网页资源 接收， 获得仅包含符 合标准数据格式前端数据的网页资源。

[0114] 如前所述， 由于前后端分离， 前端与后端之间的数据交互通过统一的通信接 口 实现， 不仅降低了数据传输的复杂度， 而且有利于后续数据格式转换， 进而有 利于进一步地提高网页访问效率。

[0115] 由此， 前端所部署的通信接口与后端保持一致， 例如， 通信接口为 API接口， 相应地， 标准数据格式由该 API接口所配置， 包括但不限于： JSON、 XML等等

[0116] 在一实施例的具体实现中， 对于前端而言， 在后端通过 restful风格的 API接口返 回了网页资源之后， 便能够接收到符合 JSON格式的前端数据。

[0117] 步骤 353， 对网页资源中符合标准数据格式的前端数据进 行数据格式转换， 得 到转换数据。

[0118] 数据格式转换， 即是指将前端数据的标准数据格式转换为前端 实际处理时所支 持的数据格式。

[0119] 步骤 355 , 在互联网应用中调用与后端分离的表现层根据 转换数据进行网页显

[0120] 在上述过程中， 接收到的网页资源仅包含符合标准数据格式的 前端数据， 即不 存在本应该由后端进行处理的数据， 也可以理解为， 前端接收到的数据是纯净 的， 因此， 与后端分离的表现层所进行的网页显示过程中 ， 前端仅需要处理前 端数据， 避免处理后端数据， 进而有利于提高前端处理效率， 从而加速网页显 示过程， 有利于提升用户的访问体验。 [0121] 下述为本申请装置实施例， 可以用于执行本申请所涉及的基于移动终端的 客户 数据安全访问方法。 对于本申请装置实施例中未披露的细节， 请参照本申请所 涉及的基于移动终端的客户数据安全访问方法 的方法实施例。

[0122] 请参阅图 9， 在一示例性实施例中， 一种网页访问装置 900包括但不限于： 请求 发起模块 910 资源接收模块 930和网页显示模块 950。

[0123] 其中， 请求发起模块 910用于前端获取互联网应用向后端发起的网页 访问请求

[0124] 资源接收模块 930用于根据网页访问请求中的网页链接地址在 后端中进行网页 资源定位， 接收后端返回的网页资源， 网页资源仅包含前端数据。

[0125] 网页显示模块 950用于通过与后端分离的表现层对仅包含前端 数据的网页资源 在互联网应用中进行网页显示。

[0126] 需要说明的是， 上述实施例所提供的网页访问装置在进行网页 访问处理时， 仅 以上述各功能模块的划分进行举例说明， 实际应用中， 可以根据需要而将上述 功能分配由不同的功能模块完成， 即网页访问装置的内部结构将划分为不同的 功能模块， 以完成以上描述的全部或者部分功能。

[0127] 另外， 上述实施例所提供的网页访问装置与网页访问 方法的实施例属于同一构 思， 其中各个模块执行操作的具体方式已经在方法 实施例中进行了详细描述， 此处不再赘述。

[0128] 请参阅图 10， 在一示例性实施例中， 一种网页访问装置 1000， 包括处理器 1001 及存储器 1004。 所述装置 1000还包括通信接口 1002和通信总线 1003。 所述处理 器 1001通过通信总线 1003读取所述存储器 1004中存储的计算机可读指令。

[0129] 其中， 存储器 1004上存储有计算机可读指令， 该计算机可读指令被处理器 1001 执行时实现上述各实施例中的网页访问方法。

[0130] 在一示例性实施例中， 一种计算机可读存储介质， 其上存储有计算机程序， 该 计算机程序被处理器执行时实现上述各实施例 中的网页访问方法。

[0131] 上述内容， 仅为本申请的较佳示例性实施例， 并非用于限制本申请的实施方案 ， 本领域普通技术人员根据本申请的主要构思和 精神， 可以十分方便地进行相 应的变通或修改， 故本申请的保护范围应以权利要求书所要求的 保护范围为准 