当前位置:首页 » 网页前端 » web服务器与app
扩展阅读
webinf下怎么引入js 2023-08-31 21:54:13
堡垒机怎么打开web 2023-08-31 21:54:11

web服务器与app

发布时间: 2022-12-08 13:22:18

A. app和web的区别是什么

基于网络平台的应用和需要下载客户端的区别,也就是相当于网页版qq和客户端安装包版qq的区别

B. 手机app应用的服务器与网页web的服务器区别大吗用java写服务器的话适合共用吗谢谢

web服务器是网站、邮件系统、ftp等功能用的。应用服务器是公司办公系统用的,主要支持文件传输、打印、OA系统运行等。java开发入门和提高这个问题先确定想学的话,买几本书好好看看。看两本书你就都明白了这种编程方面的事情,聊天是说不明白的。

C. App测试与Web测试的区别是什么

App测试和web测试都属于软件测试,它们在整个测试流程上没有太大的区别,主要的区别体现在以下几个方面: 功能、性能、兼容性、专项测试、操作方式 等,下面我们一一举例说明。

1、功能方面:
App和web基于不同的网络架构,App是C/S架构(即客户端/服务端),web是B/S架构(即浏览器/服务器),对于web来说,一般情况下如果服务端发生了更新,那么浏览器端也会随着更新,这个更新是即时的,不需要用户额外操作的,用户只需要打开浏览器访问具体的服务器地址便可以完成这个过程;而App端则首先需要用户在自己的终端上安装一个应用,当服务端发生了变更时,不能保证每个客户端的内容都获得更新,除非用户自己手动选择更新。

2、性能方面:
App和web在性能上都会关注响应时间以及负载情况等,但App还需要额外考虑应用的耗电情况、流量、CPU和内存占用情况、后台进程等。

3、兼容性方面:
Web是基于浏览器架构,在兼容性方面,一般只需要考虑所使用的浏览器版本,如Google Chrome、edge、Firefox等,而App就复杂一些,除了要关注终端系统,如iOS、macOS或Android等移动操作系统,还需要测试不同的硬件设备型号,比如iPhone系列、华为、小米、OPPO、vivo等厂商,每一家在设备的CPU、屏幕尺寸、分辨率等硬件系统上都是有差别的,App测试需要确保在软件和硬件系统上的兼容性。

4、专项测试:
正如我们前面所说的,App是基于C/S架构,所以App测试需要关注某些专项测试,比如客户端的安装、卸载和更新,而web是基于B/S架构是不需要考虑这些的。
此外,App还要考虑一些特殊场景,比如系统和应用的优先级、操作权限、应用奔溃、后台进程、中断、重启、以及网络专项测试等,网络专项又包括网络切换(如2/3/4/5G/WIFI等)、网络中断以及弱网测试等。

5、操作方式:
Web端在操作方式上是基于鼠标点击和键盘输入实现的,一般来说相对简单,而App端是基于屏幕,一般是通过触摸屏幕或者功能设备(如触摸笔)来实现具体步骤的,由于操作方式的不同,App测试时要留意屏幕的旋转和缩放、多点触控、特殊事件触发区域、应用层等。

小结
随着软件和技术的不断发展,App和web端测试在具体细分领域的区别会越来越明显,有效地加深二者异同的认识对于我们的测试能力的提升具有良好的指引作用,或许测试在具体领域还会进一步细分,但是对于测试工程师能力的要求会不断地提高,如何提高对于不同分支的认知情况值得我们去思考。

D. app的服务器可以用web服务器吗

服务器分为虚拟主机 vps 云服务器 独立服务器
所有服务器都能用作web服务器,但是一般是用虚拟主机,节约成本
但是APP的话 就不能用虚拟主机 其它服务器都可以使用

E. web server与app server有什么不同

1,web server(web服务器):

web服务器处理HTTP协议。当收到一个HTTP请求之后,web服务器会返回一个HTTP响应,比如一个HTML页面。为了处理请求,它可能响应一个静态的HTML页面、图片、重定向,或者代理(delegate)其他动态响应。

这些动态响应可以由其他程序生成,包括CGI脚本,JSPs,servlets,ASPs,服务器端的Javascript,或者其他服务器端技术。而这些服务器端程序响应,大多数时候都表现为HTML页面,供浏览器访问。

2,app server(App服务器):

根据我们的定义,app服务器可以基于各种不同的协议(可能包含HTTP协议),为客户端程序提供应用逻辑的处理。不同于web服务器主要发送用来展示在浏览器上的HTML页面,app服务器为客户端程序处理应用逻辑方面问题。应用程序使用这些逻辑,就如同调用一个对象的方法(或者面向过程编程中的函数)一样简单。

web服务器提供页面给浏览器,而app服务器提供客户端可以调用的接口。

具体而言,我们可以说:Web服务器处理HTTP请求,而app服务器基于多种不同的协议,处理应用程序的逻辑问题。

(5)web服务器与app扩展阅读:

解析

Web服务器可以解析(handles)HTTP协议。当Web服务器接收到一个HTTP请求(request),会返回一个HTTP响应(response),例如送回一个HTML页面。

为了处理一个请求(request),Web服务器可以响应(response)一个静态页面或图片,进行页面跳转(redirect)。

或者把动态响应(dynamic response)的产生委托(delegate)给一些其它的程序例如CGI脚本,JSP(JavaServer Pages)脚本,servlets,ASP(Active Server Pages)脚本。

服务器端(server-side)JavaScript,或者一些其它的服务器端(server-side)技术。无论它们(译者注:脚本)的目的如何,这些服务器端(server-side)的程序通常产生一个HTML的响应(response)来让浏览器可以浏览。


web服务

通俗的讲,Web服务器传送(serves)页面使浏览器可以浏览,然而应用程序服务器提供的是客户端应用程序可以调用(call)的方法(methods)。

确切一点,你可以说:Web服务器专门处理HTTP请求(request),但是应用程序服务器是通过很多协议来为应用程序提供(serves)商业逻辑(business logic)。

F. 手机APP和web服务端 跨域问题

跨域问题来源于JavaScript的同源策略,即只有 协议+主机名+端口号 (如存在)相同,则允许相互访问。也就是说JavaScript只能访问和操作自己域下的资源,不能访问和操作其他域下的资源。
在以前,前端和后端混杂在一起, 比如JavaScript直接调用同系统里面的一个Httphandler,就不存在跨域的问题,但是随着现代的这种多种客户端的流行,比如一个应用通常会有Web端,App端,以及WebApp端,各种客户端通常会使用同一套的后台处理逻辑,即API, 前后端分离的开发策略流行起来,前端只关注展现,通常使用JavaScript,后端处理逻辑和数据通常使用WebService来提供json数据。一般的前端页面和后端的WebService API通常部署在不同的服务器或者域名上。这样,通过ajax请求WebService的时候,就会出现同源策略的问题。
需要说明的是,同源策略是JavaScript里面的限制,其他的编程语言,比如在C#,Java或者iOS等其他语言中是可以调用外部的WebService,也就是说,如果开发Native应用,是不存在这个问题的,但是如果开发Web或者Html5如WebApp,通常使用JavaScript ajax对WebService发起请求然后解析返回的值,这样就可能存在跨域的问题。
一般的,很容易想到,将外部的资源搬到同一个域上就能解决同源策略的限制的。即在Web网站上同时开发一个Http服务端页面,所有JavaScript的请求都发到这个页面上来,这个页面在内部使用其他语言去调用外部的WebService。即添加一个代理层。这种方式可以解决问题,但是不够直接和高效。
目前,比较常见的跨域解决方案包括JSONP (JSON with padding)和CORS (Cross-origin resource sharing )。一些解决方案需要客户端和服务端配合如JSOP,一些则只需要服务端配合处理比如CORS。下面分别介绍这两种跨域方案,以及服务端WebService如何支持这两种跨域方案。
JSONP以及WebService的支持
同源策略下,某个服务器是无法获取到服务器以外的数据,但是html里面的img,iframe和script等标签是个例外,这些标签可以通过src属性请求到其他服务器上的数据。而JSONP就是通过script节点src调用跨域的请求。
当我们向服务器提交一个JSONP的请求时,我们给服务传了一个特殊的参数,告诉服务端要对结果特殊处理一下。这样服务端返回的数据就会进行一点包装,客户端就可以处理。
举个例子,服务端和客户端约定要传一个名为callback的参数来使用JSONP功能。比如请求的参数如下:
http://www.example.net/sample.aspx?callback=mycallback

如果没有后面的callback参数,即不使用JSONP的模式,该服务的返回结果可能是一个单纯的json字符串,比如:
{ foo : 'bar' }

如果和服务端约定jsonp格式,那么服务端就会处理callback的参数,将返回结果进行一下处理,比如处理成:
mycallback({ foo : 'bar' })

可以看到,这其实是一个函数调用,比如可以实现在页面定义一个名为mycallback的回调函数:
mycallback = function(data)
{
alert(data.foo);
};

现在,请求的返回值回去触发回调函数,这样就完了了跨域请求。
如果使用ServiceStack创建WebService的话,支持Jsonp方式的调用很简单,只需要在AppHost的Configure函数里面注册一下对响应结果进行过滤处理即可。
/// <summary>
/// Application specific configuration
/// This method should initialize any IoC resources utilized by your web service classes.
/// </summary>
/// <param name="container"></param>
public override void Configure(Container container)
{
ResponseFilters.Add((req, res, dto) =>
{
var func = req.QueryString.Get("callback");
if (!func.isNullOrEmpty())
{
res.AddHeader("Content-Type", ContentType.Html);
res.Write("<script type='text/javascript'>{0}({1});</script>"
.FormatWith(func, dto.ToJson()));
res.Close();
}
});
}

JSONP跨域方式比较方便,也支持各种较老的浏览器,但是缺点很明显,他只支持GET的方式提交,不支持其他Post的提交,Get方式对请求的参数长度有限制,在有些情况下可能不满足要求。所以下面就介绍一下CORS的跨域解决方案。
CORS跨域及WebService的支持
先来看一个例子,我们新建一个基本的html页面,在里面编写一个简单的是否支持跨域的小脚本,如下:
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>AJAX跨域请求测试</title>
</head>
<body>
<input type='button' value='开始测试' onclick='crossDomainRequest()' />
<div id="content"></div>

<script type="text/javascript">
//<![CDATA[
var xhr = new XMLHttpRequest();
var url = 'http://localhost:8078/json/ShopUserLogin';
function crossDomainRequest() {
document.getElementById("content").innerHTML = "开始……";
if (xhr) {
xhr.open('POST', url, true);
xhr.onreadystatechange = handler;
xhr.send();
} else {
document.getElementById("content").innerHTML = "不能创建 XMLHttpRequest";
}
}

function handler(evtXHR) {
if (xhr.readyState == 4) {
if (xhr.status == 200) {
var response = xhr.responseText;
document.getElementById("content").innerHTML = "结果:" + response;
} else {
document.getElementById("content").innerHTML = "不允许跨域请求。";
}
}
else {
document.getElementById("content").innerHTML += "<br/>执行状态 readyState:" + xhr.readyState;
}
}
//]]>
</script>

</body>
</html>

然后保存为本地html文件,可以看到,这个脚本中,对本地的服务http://localhost:1337/json/Hello 发起了一个请求, 如果使用chrome 直接打开,会看到输出的结果,不允许跨域请求。 在javascript控制台程序中同样可以看到错误提示:

那么如果在返回响应头header中注入Access-Control-Allow-Origin,这样浏览器检测到header中的Access-Control-Allow-Origin,则就可以跨域操作了。
同样,如果使用ServcieStack,在很多地方可以支持CORS的跨域方式。最简单的还是在AppHost的Configure函数里面直接写入:
/// <summary>
/// Application specific configuration
/// This method should initialize any IoC resources utilized by your web service classes.
/// </summary>
/// <param name="container"></param>
public override void Configure(Container container)
{
this.AddPlugin(new CorsFeature());
}

这样就可以了,相当于使用默认的CORS配置:
CorsFeature(allowedOrigins:"*",
allowedMethods:"GET, POST, PUT, DELETE, OPTIONS",
allowedHeaders:"Content-Type",
allowCredentials:false);

如果仅仅允许GET和POST的请求支持CORS,则只需要改为:
Plugins.Add(new CorsFeature(allowedMethods: "GET, POST"));

当然也可以在AppHost的Config里面设置全局的CORS,如下:
/// <summary>
/// Application specific configuration
/// This method should initialize any IoC resources utilized by your web service classes.
/// </summary>
/// <param name="container"></param>
public override void Configure(Container container)
{

base.SetConfig(new EndpointHostConfig
{
GlobalResponseHeaders = {
{ "Access-Control-Allow-Origin", "*" },
{ "Access-Control-Allow-Methods", "GET, POST, PUT, DELETE, OPTIONS" },
{ "Access-Control-Allow-Headers", "Content-Type" },
},
});
}

现在运行WebService,使用postman或者Chrome调用这个请求,可以看到返回的值头文件中,已经加上了响应头,并且可以正常显示返回结果了:

CORS使用起来简单,不需要客户端的额外处理,而且支持Post的方式提交请求,但是CORS的唯一一个缺点是对客户端的浏览器版本有要求,支持CORS的浏览器机器版本如下:

总结
本文介绍了JavaScript中的跨域基本概念和产生的原因,以及如何解决跨域的两种方法,一种是JSONP 一种是 CORS,在客户端Javascript调用服务端接口的时候,如果需要支持跨域的话,需要服务端支持。JSONP的方式就是服务端对返回的值进行回调函数包装,他的优点是支持众多的浏览器, 缺点是仅支持Get的方式对服务端请求。另一种主流的跨域方案是CORS,他仅需要服务端在返回数据的时候在相应头中加入标识信息。这种方式非常简便。唯一的缺点是需要浏览器的支持,一些较老的浏览器可能不支持CORS特性。
跨域支持是创建WebService时应该考虑的一个功能点,希望本文对您在这边面有所帮助,文中是使用ServiceStack来演示跨域支持的,如果您用的WCF的话,知道跨域原理的前提下,实现跨域应该不难。

参考资料:
https://github.com/ServiceStack/ServiceStack/wiki/Customize-HTTP-Responses
https://github.com/ServiceStack/ServiceStack/wiki/Request-and-response-filters
http://stackoverflow.com/questions/8211930/servicestack-rest-api-and-cors
http://stackoverflow.com/questions/15224038/rename-callback-parameter-for-jsonp

G. web服务器和应用服务器的区别

一、指代不同

1、web服务器:叫网页服务器或web服务器。WEB服务器也称为WWW(WORLD WIDE WEB)服务器,主要功能是提供网上信息浏览服务。

2、应用服务器:指通过各种协议把商业逻辑曝露给客户端的程序。

二、功能不同

1、web服务器:可以解析(handles)HTTP协议。当Web服务器接收到一个HTTP请求(request),会返回一个HTTP响应(response),例如送回一个HTML页面。

2、应用服务器:提供了访问商业逻辑的途径以供客户端应用程序使用。应用服务器使用此商业逻辑就像调用对象的一个方法一样。


三、特点不同

1、web服务器:传送(serves)页面使浏览器可以浏览。

2、应用服务器:应用程序服务器是通过很多协议来为应用程序提供(serves)商业逻辑(business logic)。


H. 手机网站和手机app的有什么区别

首先手机网站和手机APP肯定不是同一产品,但是在某些功能上会有吻合之处,那么手机网站和手机app相比之下又有什么具体区别呢?\x0d\x0a第一:成本上\x0d\x0aapp:需要投入客户端和服务端开发,以及耗费开销支持多平台和多设备。\x0d\x0a移动Web:仅需H5页面开发,使用响应式设计的移动Web可到处运行。\x0d\x0a第二:就是用户使用门槛上\x0d\x0a\x0d\x0aapp:需要下载并等待安装,占用手机容量,无Wi-Fi下流量耗费大。\x0d\x0a移动Web:支持跨平台,无安装成本,用户门槛较低。\x0d\x0a第三:就是在追踪数据方面\x0d\x0a\x0d\x0aapp:下载来源无法追踪,对渠道细分统计能力有限。\x0d\x0a移动Web:方便追踪用户来源,媲美PC浏览器下常规站点统计。\x0d\x0a第四:能否快速做出调整\x0d\x0a\x0d\x0aapp:伤不起的审核周期,遇到紧急问题无法快速处理。\x0d\x0a移动Web:站点服务器自己可控,利于快速更新迭代。\x0d\x0a尽管移动Web有如上诸多优势,但不可否认的是,浏览的体验短期内还无法超越原生应用。那么,对于生长在移动Web上的业务和服务,如何做好设计确提升用户体验将尤为重要。移动Web并不是把PC端内容直接搬到手机上来显示,而是需要结合移动端用户的使用场景,突出最核心的功能给用户,并保持界面简洁。

I. 服务器APP服务器与WEB服务器有什么区别

场景不一样呗。web就是提供一种服务就行了。 app服务器需要提供多种服务模式。

J. app服务器的配置和web服务器配置是一样的嘛的吗

web服务器处理HTTP协议。当收到一个HTTP请求之后,web服务器会返回一个HTTP响应,比如一个HTML页面。为了处理请求,它可能响应一个静态的HTML页面、图片、重定向,或者代理(delegate)其他动态响应。这些动态响应可以由其他程序生成,包括CGI脚本,JSPs,servlets,ASPs,服务器端的Javascript,或者其他服务器端技术。而这些服务器端程序响应,大多数时候都表现为HTML页面,供浏览器访问。