页面请求的处理方法、装置、电子设备和存储介质与流程

本申请涉及计算机技术领域，具体涉及计算机通信技术领域，尤其涉及一种页面请求的处理方法、装置、电子设备和存储介质。

背景技术：

目前，人们的生活、工作等方面已经离不开互联网，无论是个人、企业、学校或其他单位等，都能够使用网络发布最新动态，从而使得网络信息随时随地都会更新，用户可以通过刷新当前页面，来获取最新动态信息。

在浏览器向服务器发起页面请求时，若出现网络不稳以及服务器端短暂故障等原因，往往会导致页面请求失败，影响服务正常使用，在页面请求失败时，会在页面前端显示页面请求失败提示信息，用户根据该提示信息手动刷新页面，实现对页面的重新请求，有的时候，用户需要多次手动刷新页面，导致操作繁琐，从而影响用户和产品的粘性。

技术实现要素：

本申请提供了一种用于页面请求的处理方法、装置、电子设备和存储介质，用于解决相关技术中当发生暂时性的网络波动或者服务器端接口超时等情况时，导致页面请求失败，用户需要手动刷新页面，使得用户的产品体验较差的问题。

根据第一方面，提供了一种页面请求的处理方法，包括：

获取浏览器类应用程序向服务器发送的页面请求消息；

接收所述服务器反馈的状态码；以及

当所述服务器反馈的状态码属于预设重试码值时，创建新的页面请求消息并再次向所述服务器发送。

根据第二方面，提供了一种页面请求的处理装置，包括：

第一获取模块，用于获取浏览器类应用程序向服务器发送的页面请求消息；

第一接收模块，用于接收所述服务器反馈的状态码；

创建模块，用于在所述服务器反馈的状态码属于预设重试码值时，创建新的页面请求消息并再次向所述服务器发送。

根据第三方面，提供了一种电子设备，包括：

至少一个处理器；以及

与所述至少一个处理器通信连接的存储器；其中，

所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够执行上述的页面请求的处理方法。

根据第四方面，提供了一种存储有计算机指令的非瞬时计算机可读存储介质，所述计算机指令用于使所述计算机执行上述的页面请求的处理方法。

本申请提供的技术方案，至少具有如下技术效果：

当服务器根据应用程序发送的页面请求消息，反馈的状态码属于预设重试码值时，浏览器类应用程序并不在前端显示页面请求失败消息，而是在后端再次向服务器再次发送页面请求消息，解决了相关技术中当发生暂时性的网络波动或者服务器端接口超时等情况时，页面会显示异常，用户需要手动刷新，导致用户的产品体验较差的问题，通过对前端页面请求自动进行多次重试操作，避免了用户层对请求异常的感知，同时也减少了用户手动刷新页面的环节，从而提升服务的用户体验。

应当理解，本部分所描述的内容并非旨在标识本公开的实施例的关键或重要特征，也不用于限制本公开的范围。本公开的其它特征将通过以下的说明书而变得容易理解。

附图说明

附图用于更好地理解本方案，不构成对本申请的限定。其中：

图1为本申请实施例提供的一种页面请求的处理方法的流程示意图；

图2为本申请实施例提供的另一种页面请求的处理方法的流程示意图；

图3为本申请实施例提供的另一种页面请求的处理方法的流程示意图；

图4为本申请实施例提供的一种页面请求的处理装置的结构示意图；

图5为本申请实施例提供的另一种页面请求的处理装置的结构示意图；

图6为本申请实施例提供的另一种页面请求的处理装置的结构示意图；

图7为本申请实施例提供的另一种页面请求的处理装置的结构示意图；

图8为本申请实施例提供的另一种页面请求的处理装置的结构示意图；

图9为用来实现本申请实施例的页面请求的处理方法的电子设备的框图。

具体实施方式

以下结合附图对本申请的示范性实施例做出说明，其中包括本申请实施例的各种细节以助于理解，应当将它们认为仅仅是示范性的。因此，本领域普通技术人员应当认识到，可以对这里描述的实施例做出各种改变和修改，而不会背离本申请的范围和精神。同样，为了清楚和简明，以下的描述中省略了对公知功能和结构的描述。

下面参考附图描述本申请实施例的页面请求的处理方法、装置、电子设备和存储介质。

本申请实施例，针对相关技术中当发生暂时性的网络波动或者服务器端接口超时等情况时，页面会显示异常，用户需要手动刷新页面，导致用户的产品体验较差的问题，提出了一种页面请求的处理方法。

本申请实施例的页面请求的处理方法，能够在服务器反馈的状态码为预设重试码值时，对前端页面请求自动进行多次重试操作，在后端以不可视化的方式，实现了前端页面的多次请求，避免了用户层对请求异常的感知，同时也减少了用户手动刷新页面的环节，从而提升服务的用户体验。

图1为本申请实施例提供的一种页面请求的处理方法的流程示意图。

本申请实施例的页面请求的处理方法，还可由本申请实施例提供的页面请求的处理装置执行，该装置可配置于电子设备中，以实现在服务器反馈的状态码为预设重试码值时，创建新的页面请求，并再次向服务器发送，以实现对前端页面请求自动进行多次重试操作。

如图1所示，该页面请求的处理方法可以包括：

s101，获取浏览器类应用程序向服务器发送的页面请求消息。

其中，页面请求消息对应的请求页面内容可以包括文字、图片等。

在本申请实施例中，浏览器类应用程序是一种可以通过web(worldwideweb，全球广域网)访问的应用程序，浏览器应用程序基于web采用internet上标准的通信协议作为传输层协议，通常是tcp/ip(transmissioncontrolprotocol/internetprotocol，传输控制协议/网际协议)协议，实现数据在网络中传输等。

对于服务器来说，在本公开的实施例中，为浏览器类应用程序提供页面请求消息的响应服务，以获取对应的页面进行反馈。

在实际应用中，页面请求消息的实施方式在不同的场景中不同，作为一种可能的实现方式，用户在输入框中输入url(uniformresourcelocator,统一资源定位符)时，例如，http://www.baidu.com，对url进行dns解析，找出对端服务器的ip地址，在查询到域名对应的ip地址后，浏览器设置源地址和端口号等，以保证传输层的正常连接，即tcp正常连接，传输层建立完成后，认为获取到页面请求消息，从而向服务器页面请求消息。

作为另一种可能的实现方式，当获取到用户对浏览器应用程序的网页上的链接的触发操作时，认为获取到页面请求消息，从而，浏览器类应用程序向服务器发送的页面请求消息，比如，用户点击浏览器应用程序的网页链接时，认为获取到页面请求消息。

作为又一种可能的实现方式，可以预先在浏览器类应用程序的消息控制类之中设置有钩子函数，从而根据该钩子函数检测页面请求消息。在本实施例中，当触发消息发送时，会调用消息控制类函数，从而设置在消息控制类函数的钩子函数可以检测到该消息控制类函数的调用，根据当前触发消息控制类函数的消息类型可以识别页面请求消息。

s102，接收服务器反馈的状态码。

其中，状态码是用来表示浏览器类应用程序向服务器发送的页面请求消息的结果状态。该状态码体现了服务器是否对当前页面请求消息响应成功，即是否获取到对应的页面数据。

在一些可能的示例中，该状态码为状态码报文，该报文包括三位字节，状态码报文的第一位字节用于指示服务器对当前页面请求消息的响应情况，举例而言，当状态码报文为1xx时，指示页面请求消息已经接受，继续接收中；当状态码报文为2xx时，指示页面请求消息已经被成功接收、正在理解中；当状态码报文为3xx时，指示页面请求消息需要重定向，要成功要完成请求必须进行更进一步的操作；当状态码报文为4xx时，表示页面请求消息错误—请求有语法错误或请求无法实现；当状态码报文为5xx时，表示服务器端错误—服务器未能实现合法的请求。

在另一些可能的示例中，该状态码为数字编码，根据数字编码可以获知服务器对页面请求消息的响应情况，举例而言，当数字编码为400时，表示服务器不理解页面请求消息的语法；当数字编码为401时，表示服务器需要针对该页面请求消息进行身份验证，对于需要登录的网页，服务器可能返回此状态码；当数字编码为403时，表示服务器收到请求，但是拒绝提供服务；当数字编码为404时，表示服务器找不到页面请求消息对应的网页，例如，输入了错误的url等；当数字编码为408(请求超时)时，表示服务器等候页面请求消息时发生超时；当数字编码为429时，表示在一段时间内发送的页面请求消息数量超过服务器允许的数量等。

当然，该状态码也可以是字母形式、文字形式等，在此不再一一赘述。

s103，当服务器反馈的状态码属于预设重试码值时，创建新的页面请求消息并再次向服务器发送。

可以理解的是，预设重试码值是可以通过多次刷新页面来实现页面请求消息成功响应的状态码，比如，该预设重试码值可以是上述实施例中提到的状态码408等，又如，该预设重试码值可以为除了1xx和2xx之外的所有状态码。

当服务器反馈的状态码属于预设重试码值时，则表明当前服务器虽然针对页面请求消息没有响应成功，但是可以通过页面请求消息的重新发送来实现对页面请求消息没有响应成功，此时针对这种响应失败的情况，不再在前端显示给用户，而是创建新的页面请求消息并再次向服务器发送，直接在后端实现了页面请求消息的重新发送，避免了用户手动刷新，用户由于没有感知到该重发的流程，因此，用户和产品的粘性得到了保证。

其中，创建新的页面请求消息的方式可以是直接将历史发送的页面请求消息作为新的页面请求消息，也可以是控制浏览器应用程序重新响应用户的有关页面请求操作来重新生成，以避免之前发送的历史页面请求消息被篡改或者是错误等。

当然，正如以上描述的，当在一些示例中在浏览器类应用程序的消息控制类之中设置有钩子函数时，也可以充分利用钩子函数资源，由于状态码会触发浏览器类应用程序的消息控制类函数，因此，可以通过钩子函数获取触发消息控制类函数的类型，从而获取状态码，并在属于预设重试码值时，基于钩子函数创建页面请求消息并再次发送，比如钩子函数调用最近一次发送的页面请求消息作为创建的页面请求消息，或者钩子函数触发调用消息控制类函数创建的页面请求消息。

也就是说，在服务器反馈的状态码为预设重试码值时，对前端页面请求自动进行多次重试操作，可以有效解决因网络不稳定以及服务器端短暂故障等带来的影响正常使用的问题，同时，由于重试操作是在代码层执行的，所以用户是看不到页面异常的情况，避免了用户层对请求异常的感知，并且减少了用户手动刷新页面的环节，从而提升的用户体验。

进一步的，为了保证页面请求消息的成功响应，在向服务器发送页面请求消息后，还可以进行多次的重复发送。

下面结合图2进行说明，如图2所示，在上述步骤103之后，该方法还包括：

s201，判断在预设时间内是否接收到页面请求消息对应的页面响应消息。

其中，预设时间可根据页面请求消息对应的页面类型进行标定，也可根据实验数据标定，例如，预设时间可以为5*1000ms，通常在实际执行过程中，预设时间内服务器可以完成对页面请求消息的成功响应动作。

s202，如果未在预设时间内接收到页面响应消息，则创建新的页面请求消息并再次向服务器发送。

可以理解，服务器针对新的页面请求也有可能响应失败，比如，当页面请求消息是在传输过程中出错，或者是当前服务器负载过高导致响应错误等，此时可能还需要再次进行页面请求消息的发送。即在预设时间内未接收到页面响应消息时，说明很有可能出现了上述实施例中提到的在传输过程中出现错误的情况，此时自动创建新的页面请求消息并再次向服务器发送。由此，可以保证在传输过程中出现错误时，也能自动再次发送页面请求消息至服务器。

其中，上述创建新的页面请求消息的方式可以是上述钩子函数在预设时间内未收到页面响应消息时创建的，该创建方法可以参照上述实施例，也可以是由浏览器类应用程序重新生成并发送的等。

需要强调的是，本实施例中，再次发送页面响应消息依赖于预设时间，还可以对一些服务器没有收到页面请求消息从而无法响应的情况进行处理，比如，当页面请求消息在传输过程中出错时，页面请求消息还未都到服务器就已经返回，因此，服务器是不会反馈状态码的，例如，http请求错误和访问数据库错误。在出现上述错误时，服务器不会反馈状态码，此时可根据接收页面请求消息对应的页面响应消息的时间来判断是否需要重新创建新的页面请求消息。

由此，在预设时间内，即使没有出现传输过程中出错的情况，如果预设时间内未接收到服务器反馈的状态码，也自动创建新的页面请求消息并向再次向服务器发送，进一步保证了页面请求消息的成功响应。

在本申请的一个实施例中，创建新的页面请求消息并再次向服务器发送后，如果接收到服务器反馈的响应结果，则无需创建新的页面请求消息，直接将相应结果加载至浏览器类应用程序之中，以完成页面请求。由此，通过将响应结果加载在浏览器类应用程序之后，以便浏览器页面显示，响应内容，便于用户的正常使用。

本申请实施例中，根据预设时间内未接收到页面相应消息来确定自动发送新的页面请求消息，这样可以避免因网络不稳定带来的影响，使用户能够正常使用，提高用户体验。

综上，本申请实施例的页面请求的处理方法，当服务器根据应用程序发送的页面请求消息，反馈的状态码属于预设重试码值时，浏览器类应用程序并不在前端显示页面请求失败消息，而是在后端再次向服务器再次发送页面请求消息，解决了相关技术中当发生暂时性的网络波动或者服务器端接口超时等情况时，页面会显示异常，用户需要手动刷新，导致用户的产品体验较差的问题，通过对前端页面请求自动进行多次重试操作，避免了用户层对请求异常的感知，同时也减少了用户手动刷新页面的环节，从而提升服务的用户体验。

基于上述实施例，当服务器损坏或者网络故障等情况下，即使多次发送页面请求消息，也无法得到成功的响应结果，而当重发的次数较多时，在页面前端迟迟无法响应，会给用户一种卡顿的体验，因此，为了提升用户的产品体验，还对重发次数进行限定。

具体而言，如图3所示，在上述步骤202之后，该方法还包括：

s301，记录再次发送的次数。

在本申请的一个实施例中，再次发送的次数为除了首次浏览器类应用程序向服务器发送页面请求消息之外的其余重新发送的次数之和，并且，该次数为上述提到的两种情况下的重试次数之和。

在一些可能的示例中，当第一次重发页面请求消息后，即开启计数器来对页面请求消息的在此发送的次数计数，由此，可以基于计数器的技术结果来获取发送的次数。

在本示例中，再次发送页面请求消息的主体是钩子函数时，可以根据钩子函数的创建页面请求消息的次数来确定发送的次数。

s302，当再次发送的次数达到预设次数阈值时，则在浏览器类应用程序之中提示页面异常。

其中，预设重试次数阈值可根据用户个人喜好或者实验数据进行标定，例如，预设重试次数阈值为2次。

具体的，当再次发送的次数达到预设次数阈值时，为了避免用户感觉到卡顿，将不会再触发页面请求消息的重新发送，则在浏览器类应用程序之中提示页面异常，比如可以显示文字消息提示页面异常，比如，可以显示提示图像来提示页面异常，又比如，可以弹窗提示页面异常等。其中，提示页面异常时的提示消息中，可以包含异常导致的原因(比如异常的状态码)，以便于快速排除故障，恢复产品的使用。

在本申请的一个实施例中，可以预先设置异常的状态码与故障排除手段的对应关系，在接收到包含异常的状态码的页面异常提示消息后，查询该对应关系，获取对应的故障排除手段，并执行该故障排除手段。

举例而言，当异常的状态码为404时，则表明导致异常的原因是用户输入的url错误，从而，对应的故障排除手段为提示用户重新输入url等。

在本示例中，为了进一步充分利用资源，还可以通过钩子函数来判断再次发送的次数是否达到预设次数阈值，在本实施例中，可以通过装饰器对钩子函数之中的预设重试码值、预设时间和预设次数阈值进行修改，

其中，装饰器是一个对类进行处理的函数，用来修改类的行为，用户可根据实际情况在装饰器中修改页面相应消息的超时时间(预设时间)，可以修改重试的次数(创建新的页面请求消息并再次向服务器发送的次数)，可以修改预设重试码值，例如，预设重试码值可以为非2xx以外的所有状态码，也可以为修改为一些预先经过试验，重试可能成功的状态码。

举例而言，装饰器作用在类上，在进行页面加载时，装饰器会先加载钩子函数，并通过钩子函数判断是否满足重试条件，当满足重试条件时，执行ajax函数(创建新的页面请求消息)，如果不满足重试条件，则跳出钩子函数。其中，通过装饰器可对钩子函数中的判断条件进行修改，例如，对预设时间进行修改，对创建新的页面请求消息并再次向服务器发送的次数进行修改，对预设重试码值进行修改。

由此，通过设置装饰器可以实现根据实际情况对重试条件进行修改，且采用设置装饰器的方式符合当前主流开发习惯，在使用上较为便捷，利于流行。

综上，本申请实施例的页面请求的处理方法，兼顾后端重试次数和前端提示页面异常，一方面，避免前端用户出现卡顿感受，另一方面，保证后端重试次数的实施，避免用户的手动刷新。

为了实现上述实施例，本申请实施例还提出一种页面请求的处理装置。该页面请求的处理装置可设置在电子设备中。图4为本申请实施例提供的一种页面请求的处理装置的结构示意图。

如图4所示，该页面请求的处理装置400可包括：第一获取模块410、第一接收模块420和创建模块430。

其中，第一获取模块410用于获取浏览器类应用程序向服务器发送的页面请求消息。第一接收模块420用于接收服务器反馈的状态码。创建模块430用于在服务器反馈的状态码属于预设重试码值时，创建新的页面请求消息并再次向服务器发送。

图5为本申请实施例提供的另一种页面请求的处理装置的结构示意图。在本申请实施例一种可能的实现方式中，如图5所示，该装置还可包括：

第一判断模块440用于判断在预设时间内是否接收到页面请求消息对应的页面响应消息；创建模块430还用于未在预设时间内接收到页面响应消息时，创建新的页面请求消息并再次向服务器发送。

在本申请实施例一种可能的实现方式中，浏览器类应用程序的消息控制类之中设置有钩子函数，其中，第一获取模块440通过钩子函数获取页面请求消息，以及获取状态码；创建模块430用于在状态码属于预设重试码值或在预设时间内未收到页面响应消息时，创建新的页面请求消息并再次发送。

图6为本申请实施例提供的另一种页面请求的处理装置的结构示意图。在本申请实施例一种可能的实现方式中，如图6所示，该装置还可包括：

第一记录模块450，用于记录再次发送的次数。

第一提示模块460，用于在再次发送的次数达到预设次数阈值时，在浏览器类应用程序之中提示页面异常。

图7为本申请实施例提供的另一种页面请求的处理装置的结构示意图。在本申请实施例一种可能的实现方式中，如图7所示，该装置还可包括：

第一修改模块470，用于通过装饰器对钩子函数之中的预设重试码值、预设时间和预设次数阈值进行修改。

图8为本申请实施例提供的另一种页面请求的处理装置的结构示意图。在本申请实施例一种可能的实现方式中，如图8所示，该创建模块430可包括：

第二接收模块431，用于接收服务器反馈的响应结果。

第一加载模块432，用于将响应结果加载至浏览器类应用程序之中。需要说明的是，本申请实施例的页面请求的处理装置中未披露的细节，请参照本申请实施例的页面请求的处理方法中所披露的细节，具体这里不再赘述。

本申请实施例的页面请求的处理装置，通过第一获取模块获取浏览器类应用程序向服务器发送的页面请求消息，并通过第一接收模块接收服务器反馈的状态码，在服务器反馈的状态码属于预设重试码值时，创建模块创建新的页面请求消息并再次向服务器发送。由此，能够在服务器反馈的状态码为预设重试码值时，对前端页面请求自动进行多次重试操作，避免了用户层对请求异常的感知，同时也减少了用户手动刷新页面的环节，从而提升服务的用户体验。

根据本申请的实施例，本申请还提供了一种电子设备和一种可读存储介质。

如图9所示，是根据本申请实施例的页面请求的处理方法的电子设备的框图。电子设备旨在表示各种形式的数字计算机，诸如，膝上型计算机、台式计算机、工作台、个人数字助理、服务器、刀片式服务器、大型计算机、和其它适合的计算机。电子设备还可以表示各种形式的移动装置，诸如，个人数字处理、蜂窝电话、智能电话、可穿戴设备和其它类似的计算装置。本文所示的部件、它们的连接和关系、以及它们的功能仅仅作为示例，并且不意在限制本文中描述的和/或者要求的本申请的实现。

如图9所示，该电子设备包括：一个或多个处理器501、存储器502，以及用于连接各部件的接口，包括高速接口和低速接口。各个部件利用不同的总线互相连接，并且可以被安装在公共主板上或者根据需要以其它方式安装。处理器可以对在电子设备内执行的指令进行处理，包括存储在存储器中或者存储器上以在外部输入/输出装置(诸如，耦合至接口的显示设备)上显示gui的图形信息的指令。在其它实施方式中，若需要，可以将多个处理器和/或多条总线与多个存储器和多个存储器一起使用。同样，可以连接多个电子设备，各个设备提供部分必要的操作(例如，作为服务器阵列、一组刀片式服务器、或者多处理器系统)。图5中以一个处理器501为例。

存储器502即为本申请所提供的非瞬时计算机可读存储介质。其中，所述存储器存储有可由至少一个处理器执行的指令，以使所述至少一个处理器执行本申请所提供的页面请求的处理方法。本申请的非瞬时计算机可读存储介质存储计算机指令，该计算机指令用于使计算机执行本申请所提供的页面请求的处理方法。

存储器502作为一种非瞬时计算机可读存储介质，可用于存储非瞬时软件程序、非瞬时计算机可执行程序以及模块，如本申请实施例中的页面请求的处理方法对应的程序指令/模块(例如，附图4所示的第一获取模块410、第一接收模块420和创建模块430)。处理器501通过运行存储在存储器502中的非瞬时软件程序、指令以及模块，从而执行服务器的各种功能应用以及数据处理，即实现上述方法实施例中的页面请求的处理方法。

存储器502可以包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需要的应用程序；存储数据区可存储根据页面请求的处理方法的电子设备的使用所创建的数据等。此外，存储器502可以包括高速随机存取存储器，还可以包括非瞬时存储器，例如至少一个磁盘存储器件、闪存器件、或其他非瞬时固态存储器件。在一些实施例中，存储器502可选包括相对于处理器501远程设置的存储器，这些远程存储器可以通过网络连接至页面请求的处理方法的电子设备。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。

页面请求的处理方法的电子设备还可以包括：输入装置503和输出装置504。处理器501、存储器502、输入装置503和输出装置504可以通过总线或者其他方式连接，图5中以通过总线连接为例。

输入装置503可接收输入的数字或字符信息，以及产生与页面请求的处理方法的电子设备的用户设置以及功能控制有关的键信号输入，例如触摸屏、小键盘、鼠标、轨迹板、触摸板、指示杆、一个或者多个鼠标按钮、轨迹球、操纵杆等输入装置。输出装置504可以包括显示设备、辅助照明装置(例如，led)和触觉反馈装置(例如，振动电机)等。该显示设备可以包括但不限于，液晶显示器(lcd)、发光二极管(led)显示器和等离子体显示器。在一些实施方式中，显示设备可以是触摸屏。

此处描述的系统和技术的各种实施方式可以在数字电子电路系统、集成电路系统、专用asic(专用集成电路)、计算机硬件、固件、软件、和/或它们的组合中实现。这些各种实施方式可以包括：实施在一个或者多个计算机程序中，该一个或者多个计算机程序可在包括至少一个可编程处理器的可编程系统上执行和/或解释，该可编程处理器可以是专用或者通用可编程处理器，可以从存储系统、至少一个输入装置、和至少一个输出装置接收数据和指令，并且将数据和指令传输至该存储系统、该至少一个输入装置、和该至少一个输出装置。

这些计算程序(也称作程序、软件、软件应用、或者代码)包括可编程处理器的机器指令，并且可以利用高级过程和/或面向对象的编程语言、和/或汇编/机器语言来实施这些计算程序。如本文使用的，术语“机器可读介质”和“计算机可读介质”指的是用于将机器指令和/或数据提供给可编程处理器的任何计算机程序产品、设备、和/或装置(例如，磁盘、光盘、存储器、可编程逻辑装置(pld))，包括，接收作为机器可读信号的机器指令的机器可读介质。术语“机器可读信号”指的是用于将机器指令和/或数据提供给可编程处理器的任何信号。

为了提供与用户的交互，可以在计算机上实施此处描述的系统和技术，该计算机具有：用于向用户显示信息的显示装置(例如，crt(阴极射线管)或者lcd(液晶显示器)监视器)；以及键盘和指向装置(例如，鼠标或者轨迹球)，用户可以通过该键盘和该指向装置来将输入提供给计算机。其它种类的装置还可以用于提供与用户的交互；例如，提供给用户的反馈可以是任何形式的传感反馈(例如，视觉反馈、听觉反馈、或者触觉反馈)；并且可以用任何形式(包括声输入、语音输入或者、触觉输入)来接收来自用户的输入。

可以将此处描述的系统和技术实施在包括后台部件的计算系统(例如，作为数据服务器)、或者包括中间件部件的计算系统(例如，应用服务器)、或者包括前端部件的计算系统(例如，具有图形用户界面或者网络浏览器的用户计算机，用户可以通过该图形用户界面或者该网络浏览器来与此处描述的系统和技术的实施方式交互)、或者包括这种后台部件、中间件部件、或者前端部件的任何组合的计算系统中。可以通过任何形式或者介质的数字数据通信(例如，通信网络)来将系统的部件相互连接。通信网络的示例包括：局域网(lan)、广域网(wan)和互联网。

计算机系统可以包括客户端和服务器。客户端和服务器一般远离彼此并且通常通过通信网络进行交互。通过在相应的计算机上运行并且彼此具有客户端-服务器关系的计算机程序来产生客户端和服务器的关系。

根据本申请实施例的技术方案，在服务器反馈的状态码为预设重试码值时，对前端页面请求自动进行多次重试操作，避免了用户层对请求异常的感知，同时也减少了用户手动刷新页面的环节，从而提升服务的用户体验。

应该理解，可以使用上面所示的各种形式的流程，重新排序、增加或删除步骤。例如，本发申请中记载的各步骤可以并行地执行也可以顺序地执行也可以不同的次序执行，只要能够实现本申请公开的技术方案所期望的结果，本文在此不进行限制。

上述具体实施方式，并不构成对本申请保护范围的限制。本领域技术人员应该明白的是，根据设计要求和其他因素，可以进行各种修改、组合、子组合和替代。任何在本申请的精神和原则之内所作的修改、等同替换和改进等，均应包含在本申请保护范围之内。