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

pyweb接口

发布时间: 2023-06-08 21:11:26

❶ linux下python和webpy怎么搭建

基于python的web开发,这里我们使用linux为开发环境,搭建基于nginx + web.py + fastcgi
有些基本基本概念解释下,哈哈,因为我不懂
1.wsgi为Web服务器网关接口(Python Web Server Gateway Interface,缩写为WSGI)是是为Python语言定义的Web服务器和Web应用程序或框架之间的一种简单而通用的接口。自从WSGI被开发出来以后,许多其它语言中也出现了类似接口
2.uwsgi,另一种python定义的web服务器和web应用的接口
3.REST服务,REST(Representational State Transfer表述性状态转移)是一种针对网络应用的设计和开发方式,可以降低开发的复杂性,提高系统的可伸缩性。
4.CRUD是指在做计算处理时的增加(Create)、查询(Retrieve)(重新得到数据)、更新(Update)和删除(Delete)几个单词的首字母简写。主要被用在描述软件系统中数据库或者持久层的基本操作功能

以下内容主要来自
http://webpy.org/cookbook/fastcgi-nginx
需要的软件
nginx 0.7以上版本,我使用的是nginx 0.9.2
webpy我使用的web.py-0.37
spawn-fcgi 1.6.3
flup 1.0
nginx的配置请参看官方文档
spawn-fcgi是lighttpd的一个子项目用于多进程管理
webpy和flup安装方式为解压后运行python setup.py install
安装编写index.py

点击(此处)折叠或打开
#!/usr/bin/env python

# -*- coding: utf-8 -*-

import web

urls = ("/.*", "hello")

app = web.application(urls, globals())

class hello:

def GET(self):

return 'Hello, world!'

if __name__ == "__main__":

web.wsgi.runwsgi = lambda func, addr=None: web.wsgi.runfcgi(func, addr)

app.run()
注意index.py需要使用命令chmod +x index.py加入可执行权限
将index.py放入/data/www(我所使用的目录你可以修改)
修改nginx.conf配置
index要加入index.py
Nginx的配置加入

点击(此处)折叠或打开
location / {

fastcgi_param REQUEST_METHOD $request_method;

fastcgi_param QUERY_STRING $query_string;

fastcgi_param CONTENT_TYPE $content_type;

fastcgi_param CONTENT_LENGTH $content_length;

fastcgi_param GATEWAY_INTERFACE CGI/1.1;

fastcgi_param SERVER_SOFTWARE nginx/$nginx_version;

fastcgi_param REMOTE_ADDR $remote_addr;

fastcgi_param REMOTE_PORT $remote_port;

fastcgi_param SERVER_ADDR $server_addr;

fastcgi_param SERVER_PORT $server_port;

fastcgi_param SERVER_NAME $server_name;

fastcgi_param SERVER_PROTOCOL $server_protocol;

fastcgi_param SCRIPT_FILENAME $fastcgi_script_name;

fastcgi_param PATH_INFO $fastcgi_script_name;

fastcgi_pass 127.0.0.1:9002;

}
使用Spawn-fcgi
spawn-fcgi -d /data/www -f /data/www/index.py -a 127.0.0.1 -p 9002
如果报错为126,说明index.py没有可执行权限
netstat -lnp | grep 9002参考是否启动成功
我运行的实际为
spawn-fcgi -d /data/www -f /data/www/index.py -a 127.0.0.1 -p 9002 -F 2
启动2个进程
启动nginx
浏览器输入地址

成功结束

❷ python web 怎么部署

学过PHP的都了解,php的正式环境部署非常简单,改几个文件就OK,用FastCgi方式也是分分钟的事情。相比起来,Python在web应用上的部署就繁杂的多,主要是工具繁多,主流服务器支持不足,在了解Python的生产环境部署方式之前,先明确一些概念!很重要!

CGI:

CGI即通用网关接口(Common Gateway Interface),是外部应用程序(CGI程序)与Web服务器之间的接口标准,是在CGI程序和Web服务器之间传递信息的规程。CGI规范允许Web服务器执行外部程序,并将它们的输出发送给Web浏览器,CGI将Web的一组简单的静态超媒体文档变成一个完整的新的交互式媒体。通俗的讲CGI就像是一座桥,把网页和WEB服务器中的执行程序连接起来,它把HTML接收的指令传递给服务器的执行程序,再把服务器执行程序的结果返还给HTML页。CGI的跨平台性能极佳,几乎可以在任何操作系统上实现。

CGI方式在遇到连接请求(用户请求)先要创建cgi的子进程,激活一个CGI进程,然后处理请求,处理完后结束这个子进程。这就是fork-and-execute模式。所以用cgi方式的服务器有多少连接请求就会有多少cgi子进程,子进程反复加载是cgi性能低下的主要原因。当用户请求数量非常多时,会大量挤占系统的资源如内存,CPU时间等,造成效能低下。

CGI脚本工作流程:

  • 浏览器通过HTML表单或超链接请求指向一个CGI应用程序的URL。

  • 服务器执行务器收发到请求。所指定的CGI应用程序。

  • CGI应用程序执行所需要的操作,通常是基于浏览者输入的内容。

  • CGI应用程序把结果格式化为网络服务器和浏览器能够理解的文档(通常是HTML网页)。

  • 网络服务器把结果返回到浏览器中。

  • python有cgi模块可支持原生cgi程序

    FastCGI:

    FastCGI是一个可伸缩地、高速地在HTTP server和动态脚本语言间通信的接口。多数流行的HTTP server都支持FastCGI,包括Apache、Nginx和lighttpd等,同时,FastCGI也被许多脚本语言所支持,其中就有Python。FastCGI是从CGI发展改进而来的。传统CGI接口方式的主要缺点是性能很差,因为每次HTTP服务器遇到动态程序时都需要重新启动脚本解析器来执行解析,然后结果被返回给HTTP服务器。这在处理高并发访问时,几乎是不可用的。FastCGI像是一个常驻(long-live)型的CGI,它可以一直执行着,只要激活后,不会每次都要花费时间去fork一次(这是CGI最为人诟病的fork-and-execute 模式)。CGI 就是所谓的短生存期应用程序,FastCGI 就是所谓的长生存期应用程序。由于 FastCGI 程序并不需要不断的产生新进程,可以大大降低服务器的压力并且产生较高的应用效率。它的速度效率最少要比CGI 技术提高 5 倍以上。它还支持分布式的运算, 即 FastCGI 程序可以在网站服务器以外的主机上执行并且接受来自其它网站服务器来的请求。

    FastCGI是语言无关的、可伸缩架构的CGI开放扩展,其主要行为是将CGI解释器进程保持在内存中并因此获得较高的性能。众所周知,CGI解释器的反复加载是CGI性能低下的主要原因,如果CGI解释器保持在内存中并接受FastCGI进程管理器调度,则可以提供良好的性能、伸缩性、Fail-Over特性等等。FastCGI接口方式采用C/S结构,可以将HTTP服务器和脚本解析服务器分开,同时在脚本解析服务器上启动一个或者多个脚本解析守护进程。当HTTP服务器每次遇到动态程序时,可以将其直接交付给FastCGI进程来执行,然后将得到的结果返回给浏览器。这种方式可以让HTTP服务器专一地处理静态请求或者将动态脚本服务器的结果返回给客户端,这在很大程度上提高了整个应用系统的性能。

    FastCGI的工作流程:

  • Web Server启动时载入FastCGI进程管理器(PHP-CGI或者PHP-FPM或者spawn-cgi)

  • FastCGI进程管理器自身初始化,启动多个CGI解释器进程(可见多个php-cgi)并等待来自Web Server的连接。

  • 当客户端请求到达Web Server时,FastCGI进程管理器选择并连接到一个CGI解释器。Web server将CGI环境变量和标准输入发送到FastCGI子进程php-cgi。

  • FastCGI子进程完成处理后将标准输出和错误信息从同一连接返回Web Server。当FastCGI子进程关闭连接时,请求便告处理完成。FastCGI子进程接着等待并处理来自FastCGI进程管理器(运行在Web Server中)的下一个连接。 在CGI模式中,php-cgi在此便退出。

  • FastCGI 的特点:

  • 打破传统页面处理技术。传统的页面处理技术,程序必须与 Web 服务器或 Application 服务器处于同一台服务器中。这种历史已经早N年被FastCGI技术所打破,FastCGI技术的应用程序可以被安装在服务器群中的任何一台服务器,而通过 TCP/IP 协议与 Web 服务器通讯,这样做既适合开发大型分布式 Web 群,也适合高效数据库控制。

  • 明确的请求模式。CGI 技术没有一个明确的角色,在 FastCGI 程序中,程序被赋予明确的角色(响应器角色、认证器角色、过滤器角色)。

  • WSGI:

    PythonWeb服务器网关接口(Python Web Server Gateway Interface,缩写为WSGI)是为Python语言定义的Web服务器和Web应用程序或框架之间的一种简单而通用的接口。自从WSGI被开发出来以后,许多其它语言中也出现了类似接口。WSGI是作为Web服务器与Web应用程序或应用框架之间的一种低级别的接口,以提升可移植Web应用开发的共同点。WSGI是基于现存的CGI标准而设计的。

    WSGI区分为两个部份:一为“服务器”或“网关”,另一为“应用程序”或“应用框架”。在处理一个WSGI请求时,服务器会为应用程序提供环境上下文及一个回调函数(Callback Function)。当应用程序完成处理请求后,透过先前的回调函数,将结果回传给服务器。所谓的 WSGI 中间件同时实现了API的两方,因此可以在WSGI服务和WSGI应用之间起调解作用:从WSGI服务器的角度来说,中间件扮演应用程序,而从应用程序的角度来说,中间件扮演服务器。“中间件”组件可以执行以下功能:

  • 重写环境变量后,根据目标URL,将请求消息路由到不同的应用对象。

  • 允许在一个进程中同时运行多个应用程序或应用框架。

  • 负载均衡和远程处理,通过在网络上转发请求和响应消息。

  • 进行内容后处理,例如应用XSLT样式表。

  • 以前,如何选择合适的Web应用程序框架成为困扰Python初学者的一个问题,这是因为,一般而言,Web应用框架的选择将限制可用的Web服务器的选择,反之亦然。那时的Python应用程序通常是为CGI,FastCGI,mod_python中的一个而设计,甚至是为特定Web服务器的自定义的API接口而设计的。WSGI没有官方的实现, 因为WSGI更像一个协议。只要遵照这些协议,WSGI应用(Application)都可以在任何服务器(Server)上运行, 反之亦然。WSGI就是Python的CGI包装,相对于Fastcgi是PHP的CGI包装。

    WSGI将 web 组件分为三类: web服务器,web中间件,web应用程序, wsgi基本处理模式为 : WSGI Server -> (WSGI Middleware)* -> WSGI Application 。

    uwsgi:

    uwsgi协议是一个uWSGI服务器自有的协议,它用于定义传输信息的类型(type of information),每一个uwsgi packet前4byte为传输信息类型描述,它与WSGI相比是两样东西。据称其效率是fcgi的10倍。具体的协议内容请参考:the uwsgi protocol

    以上四者都可以理解为协议!协议!协议!实现了这样的协议,就可以实现Web服务器与Web应用程序相关联的web服务!

    uWSGI:

    uWSGI项目旨在为部署分布式集群的网络应用开发一套完整的解决方案。uWSGI主要面向web及其标准服务,已经成功的应用于多种不同的语言。由于uWSGI的可扩展架构,它能够被无限制的扩展用来支持更多的平台和语言。目前,你可以使用C,C++和Objective-C来编写插件。项目名称中的“WSGI”是为了向同名的Python Web标准表示感谢,因为WSGI为该项目开发了第一个插件。uWSGI是一个Web服务器,它实现了WSGI协议、uwsgi、http等协议。uWSGI,既不用wsgi协议也不用FastCGI协议,而是自创了上文说将的uwsgi协议。

    uWSGI的主要特点如下:

  • 超快的性能。

  • 低内存占用(实测为apache2的mod_wsgi的一半左右)。

  • 多app管理。

  • 详尽的日志功能(可以用来分析app性能和瓶颈)。

  • 高度可定制(内存大小限制,服务一定次数后重启等)。

  • Gunicorn:

    和uWSGi类似的工具,从rails的部署工具(Unicorn)移植过来的。但是它使用的协议是前文所讲的WSGI,这是python2.5时定义的官方标准(PEP 333),根红苗正,而且部署比较简单,详细的使用教程请点击这里。Gunicorn采用prefork模式,Gunicorn 服务器与各种 Web 框架兼容,只需非常简单的执行,轻量级的资源消耗,以及相当迅速。它的特点是与 Django 结合紧密,部署特别方便。 缺点也很多,不支持 HTTP 1.1,并发访问性能不高,与 uWSGI,Gevent 等有一定的性能差距。

    1. Gunicorn设计

    Gunicorn 是一个 master进程,spawn 出数个工作进程的 web 服务器。master 进程控制工作进程的产生与消亡,工作进程只需要接受请求并且处理。这样分离的方式使得 reload 代码非常方便,也很容易增加或减少工作进程。 工作进程这块作者给了很大的扩展余地,它可以支持不同的IO方式,如 Gevent,Sync 同步进程,Asyc 异步进程,Eventlet 等等。master 跟 worker 进程完全分离,使得 Gunicorn 实质上就是一个控制进程的服务。

    2. Gunicorn源码结构

    从 Application.run() 开始,首先初始化配置,从文件读取,终端读取等等方式完成 configurate。然后启动 Arbiter,Arbiter 是实质上的 master 进程的核心,它首先从配置类中读取并设置,然后初始化信号处理函数,建立 socket。然后就是开始 spawn 工作进程,根据配置的工作进程数进行 spawn。然后就进入了轮询状态,收到信号,处理信号然后继续。这里唤醒进程的方式是建立一个 PIPE,通过信号处理函数往 pipe 里 write,然后 master 从 select.select() 中唤醒。

    工作进程在 spawn 后,开始初始化,然后同样对信号进行处理,并且开始轮询,处理 HTTP 请求,调用 WSGI 的应用端,得到 resopnse 返回。然后继续。

    Sync 同步进程的好处在于每个 request 都是分离的,每个 request 失败都不会影响其他 request,但这样导致了性能上的瓶颈。

    Tornado:

    Tornado即使一款python 的开发框架,也是一个异步非阻塞的http服务器,它本身的数据产出实现没有遵从上文所说的一些通用协议,因为自身就是web服务器,所以动态请求就直接通过内部的机制,输出成用户所请求的动态内容。如果把它作为一个单独服务器,想用它来配合其他的框架如Flask来部署,则需要采用WSGI协议,Tornado内置了该协议,tornado.wsgi.WSGIContainer。

    wsgiref:

    Python自带的实现了WSGI协议的的wsgi server。wsgi server可以理解为一个符合wsgi规范的web server,接收request请求,封装一系列环境变量,按照wsgi规范调用注册的wsgi app,最后将response返回给客户端。Django的自带服务器就是它了。

    以上都可以理解为实现!实现!实现!实现了协议的工具!

    注:mod_wsgi(apache的模块)其实也是实现了wsgi协议的一个模块,现在几乎不废弃了,所以也不多说了,感兴趣的自己查一下吧。

    所以如果你采用Django框架开发了应用之后,想部署到生产环境,肯定不能用Django自带的,可以用使用uwsgi协议的uWSGI服务器,也可以采用实现了WSGI协议的gunicorn或者Tornado,亦可以用FastCGI、CGI模式的Nginx、lighttpd、apache服务器。其他框架亦如此!明白了这些概念在部署的时候就可以做到心中有数,各种工具之间的搭配也就“知其然,并知其所以然”了。

    在我们组的项目中有两种框架Django和Tornado,生产环境也用到了两种部署方式。uWSGI和Gunicorn:

    Django项目用Nginx+uWSGI方式部署,Tornado项目用Nginx+Gunicorn方式部署:

    Nginx都作为负载均衡以及静态内容转发。Tornado项目用supervisord来管理Gunicorn,用Gunicorn管理Tornado。众所周知,由于Python的GIL存在,所以Python的并发都采用多进程模式,所以我们部署的方式是一个核心两个进程。

❸ Python 如何测试WebService接口

WebService是什么

简单的说WebService是一个SOAP(面向服务的编程)的架构,它是不依赖于语言,不依赖于平台,可以实现不同的语言(通过 xml 描述)间的相互调用,通过Internet进行基于Http协议的网络应用间的交互。通过SOAP在Web上提供的软件服务,使用WSDL文件进行说明,并通过UDDI进行注册。(概念性的东西大家可以自行搜索补充)


测试环境准备

python2.7 + httplib 内置库


数据准备
这里就定义了两个case:
case1是一个正向case, 根据正确的nameid查询用户信息。
case2是一个反向case, 给出一个错误老灶困的nameid 查询用户信息。
然后将辩缓这两个case 存放到一个dict 中,最后引入代码里面进行请求使用。


data.py文件内容如下:


test.py文件内容如下:

总结 :
通过以上简单的侍念几步就可以完成WebService Api的测试,对于示例中的测试数据大家可以根据Api文档的描述不断的丰富测试场景。希望对你有所帮助。

❹ Python实现WebService接口(SOAP)

Web Service是一个[平台](https://ke..com/item/平台/1064049)独立的,低耦合的,自包含的、基于可[编程](https://ke..com/item/编程)的web的应用程序,可使用开放的[XML](https://ke..com/item/XML)([标准通用标记语言](https://ke..com/item/标准通用标记语言/6805073)下的一个子集)[标准](https://ke..com/item/标准/219665)来[描述](https://ke..com/item/描述/8928757)、发布、发现、协调和配置这些应用程序,用于开发分布式的交互操作的[应用程序](https://ke..com/item/应用程序/5985445)。 [1]

Web Service技术, 能使得运行在不同机器上的不同应用无须借助附加的、专门的第三方软件或硬件, 就可相互交换数据或集成。依据Web Service规范实施的应用之间, 无论它们所使用的语言、 平台或内部协议是什么, 都可以相互交换数据。Web Service是自描述、 自包含的可用网络模块, 可以执行具体的业务功能。Web Service也很容易部署, 因为它们基于一些常规的产业标准以及已有的一些技术,诸如[标准通用标记语言](https://ke..com/item/标准通用标记语言/6805073)下的子集[XML](https://ke..com/item/XML)、HTTP。Web Service减少了应用接口的花费。Web Service为整个企业甚至多个组织之间的业务流程的集成提供了一雀激缓个通用机制。

**SOAP**

SOAP即[简单对象访问协议](https://ke..com/item/简单对象访问协议)(Simple Object Access Protocol),它是用于交换铅梁[XML](https://ke..com/item/XML)([标准通用标记语言](https://ke..com/item/标准通用标记语言)下的一个子集)编码信息的轻量级协议。它有三个主要方面:XML-envelope为描述信息内容和如何处理内容定义了框架,将程序对象编码成为XML对象的规则,执行[远程过程调用顷模](https://ke..com/item/远程过程调用)(RPC)的约定。SOAP可以运行在任何其他[传输协议](https://ke..com/item/传输协议)上。例如,你可以使用 SMTP,即因特网[电子邮件协议](https://ke..com/item/电子邮件协议)来传递SOAP消息,这可是很有诱惑力的。在[传输层](https://ke..com/item/传输层)之间的头是不同的,但XML有效负载保持相同。

Web Service 希望实现不同的系统之间能够用“[软件](https://ke..com/item/软件)-软件对话”的方式相互调用,打破了软件应用、网站和各种设备之间的格格不入的状态,实现“基于Web无缝集成”的目标。

使用Python实现服务端

service.py 服务端启动文件

app.py webservice接口

使用Python实现客户端

client.py

上面调用的客户端接口,测试结果如下:

❺ 如何利用cURL和python对服务端和web端进行接口测试

工具描述
cURL是利用URL语法在命令行方式下工作的文件传输工具,是开源爱好者编写维护的免费工具,支持包括Windows、Linux、Mac等数十个操作系统,最新版本为7.27.0,但是我推荐大家使用7.26.0,从这里可以下载7.26.0版本。
以下是官方介绍的翻译: cURL是一个使用URL语法来传输数据的命令行工具,支持DICT,FILE,FTP,FTPS,GOPHER,HTTP,HTTPS,IMAP,IMAPS,LDAP,LDAPS,POP3,POP3S,RTMP,RTSP,SCP,SFTP,SMTP,SMTPS,Telnet和TFTP。 cURL支持SSL证书,HTTP POST,HTTP PUT,FTP上传,HTTP基础表单上传,代理,cookies,用户+密码身份验证(Basic, Digest, NTLM, Negotiate, kerberos...),恢复文件传输,隧道代理等等。
Python是一种面向对象、直译式计算机程序设计语言,由Guido van Rossum于1989年底发明,它的强大和易用就无需多做说明了,在web开发中或者对开发速度要求较高的开发中应用十分广,不过因为属于脚本类语言,它的性能始终比不上C++、C等语言。
本文主要利用实例说明这两款工具的在测试中的部分用途,更多用法留待大家继续探索。
应用场景
使用cURL模拟客户端对服务端进行查询
在进行接口测试时,应该先找开发人员提供接口列表和对应参数,这样测试的时候就可以验证测试方法是否正确,不过如果可以用浏览器模拟操作的话,也可以自己先试试的,后面的例子会提到。
首先使用客户端访问需要测试的服务端接口,用wireshark抓包结果如下:

把查询字符串以multipart方式post数据到服务器的file_health_info.php接口。
Tips:
Windows版的cURL不像Linux或者Mac一样属于系统自带工具,需要下载,如果要在命令提示符下使用就需要跳转到工具所在目录下才能运行,十分麻烦,我们可以直接把这个工具文件放到Windows目录下,这样无论在哪个目录都可以直接使用“curl”命令运行工具了。
cURL默认就是以post方式发送数据的,所以只需要加入multipart方式就可以了,-F在cURL帮助中的解释是:

-F, --form CONTENT Specify HTTP multipart POST data (H)
--form-string STRING Specify HTTP multipart POST data (H)
--ftp-account DATA Account data string (F)
--ftp-alternative-to-user COMMAND String to replace "USER [name]" (F)
--ftp-create-dirs Create the remote dirs if not present (F)
--ftp-method [MULTICWD/NOCWD/SINGLECWD] Control CWD usage (F)
--ftp-pasv Use PASV/EPSV instead of PORT (F)

Specify HTTP multipart POST data正好满足我们的要求,所以模拟的语句是:
curl -F "newmd5=###25016566###d:\test.exe###1###" file_health_info.php
后面的都是参数,测试前就要找开发确认好。
不过因为服务端支持以gzip方式返回数据,所以我们还可以在请求中加入—compressed参数,即是:
curl --compressed -F "newmd5=###25016566###d:\test.exe###1###"file_health_info.php
为了更好判断服务端接口是否正常,除了对返回数据进行判断外,我们还需要对服务端返回的数据包头进行解析,所以还可以在cURL请求中加入-i参数,最终这个测试语句就变为:
curl –i --compressed -F "newmd5=###25016566###d:\test.exe###1###"file_health_info.php
模拟完成后就要考虑判断返回值的事了,我们首先在命令提示符下运行这个语句,看看返回值。
运行以上命令后,返回的数据如下:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

HTTP/1.1 100 Continue
HTTP/1.1 200 OK
Date: Fri, 24 Aug 2012 07:47:45 GMT
Content-Type: application/xml
Transfer-Encoding: chunked
Connection: keep-alive
Server: 360 web server
Content-Encoding: gzip
<?xml version="1.0" encoding="GBK" ?>
<ret>
<retinfo code="0" msg="Operation success" total="1" success="1" empty="0"
cost="999.92752075195"/>
<softs>
<soft>
<md5></md5>
<sha1></sha1>
<level>4040</level>
<e_level>40.3</e_level>
<size></size>
<soft_name><![CDATA[]]> </soft_name>
<describ><![CDATA[]]></describ>
<file_desc><![CDATA[]]></file_desc>
<upload>0</upload>
<attr_upload>2</attr_upload>
<class><![CDATA[private]]></class>
<malware><![CDATA[cloud.virus]]></malware>
<is_sys_file>0</is_sys_file>
<is_rep>0</is_rep>
<age>0</age>
<pop>0</pop>
</soft>
</softs>
</ret>

数据包包头是常见的,一般来说,我们只要判断包头中含有“HTTP/1.1 200 OK”就可以确定服务端正常返回了数据。另外从内容可以看到这是一个xml格式的数据包,我们只需要判断是否存在关键的字段即可,比如<level>,确定这些之后我们就可以在python中添加如下案例代码了:
首先运行指定的curl命令:
response = os.popen('''curl -i --compressed -F "newmd5=###25016566###d:\test.exe###1###"
然后判断返回值中是否存在我们想要的字段:
self.assertNotEqual(response.find('HTTP/1.1 200 OK'),-1)
self.assertNotEqual(response.find('<level>'),-1)
上面的内容看起来差不多可以了,但实际还不够严谨,因为服务端返回的这些数据是从数据库中获取的,所以我们还需要查询数据库获取指定值,判断是否和数据包中的一致,比如<level>:
首先使用python登录数据库服务器:
conn = MySQLdb.connect(host='172.22.54.31', user='user',passwd='test321',db='cloud')
cursor = conn.cursor()
count = cursor.execute('SELECT plevel FROM file where md5=""')
result = cursor.fetchone()
然后判断返回值中的level是否数据库中的值:
self.assertNotEqual(response.find('''<level>%s</level>'''%result[0]),-1)
测试时除了使用cURL等工具进行模拟,还可以自己用python或其他语言写代码进行post数据,不过当时简单起见所以就选择了用cURL测试。

使用cURL模拟控制台登录
说到模拟登录或者模拟点击,很多同学可能直接联想到QTP等模拟界面操作的工具,事实上这种工具有一个很大的弊端是太依赖控件,如果界面控件变了,那么可能整个脚本就无效了,现在的程序设计都倾向界面逻辑分离,这样修改界面时就不会动到底下的功能接口,开发人员可以随时修改界面控件,如果还是采取QTP等模拟点击的方法测试,结果可能是事倍功半的,如果测试时直接点用接口就可以避免这种问题。
下面的例子是模拟控制台登录的,登录URL为:
index.php?r=site/login ,首先使用浏览器登录一次,看看实际效果如何。
Tips:
测试php或其他web程序时建议使用chrome,因为它自带的Developer Tools十分好用,当然firefox或者IE9也有类似的工具,看个人习惯吧。按F12打开工具,选择Network标签页,然后输入用户名、密码点击登录,这时Network下方会显示登录过程中浏览器想控制台请求的所有数据,包括请求类型、表单数据等,这些是我们模拟操作的数据来源。

从上图可以获取几个重点信息:请求URL、请求类型、数据类型、数据内容、并且支持gzip压缩等。我们用curl模拟如下:
curl -i --compressed cloud/index.php?r=site/login -d “username=admin” -d “userpass=admin”
使用-i和—compressed的原因再上一个例子已经说了,这里不再赘述,重点是后面的-d,它在官方帮助的解释是:

-d, --data DATA HTTP POST data (H)
--data-ascii DATA HTTP POST ASCII data (H)
--data-binary DATA HTTP POST binary data (H)
--data-urlencode DATA HTTP POST data url encoded (H)
--delegation STRING GSS-API delegation permission
--digest Use HTTP Digest Authentication (H)
--disable-eprt Inhibit using EPRT or LPRT (F)
--disable-epsv Inhibit using EPSV (F)

而我们从Developer Tools返回的数据已经知道,返回数据的格式是
“application/x-www-form-urlencoded”,所以很明显需要使用-d的HTTP POST data url encoded特性。不过格式中还有关键字form,莫非也支持-F参数登录,试试:
curl -i --compressed cloud/index.php?r=site/login -F “username=admin” -F “userpass=admin”,果然成功,呵呵~
也许有同学有疑问,为何不模拟warnsetup、refer,这是因为测试时发现登录界面只需要用户名和密码就够了,refer 用于记录来源网页,在这里用处不大,warnsetup只是用于验证登录码的,这个已经去掉了。
接下来要验证数据,我们在命令提示符中运行上面的命令,返回结果如下:

1
2
3
4
5
6
7
8
9
10
11
12
13

HTTP/1.1 302 Moved Temporarily
Date: Fri, 24 Aug 2012 08:29:07 GMT
Content-Type: text/html
Transfer-Encoding: chunked
Connection: keep-alive
X-Powered-By: PHP/5.4.3
Set-Cookie: PHPSESSID=; path=/
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Set-Cookie: PHPSESSID=; path=/
Location: ./index.php
Server: 360 web server

很奇怪吧,乍一看控制台没有返回任何有用信息,不过里面那句HTTP/1.1 302 Moved Temporarily是不是特别眼熟?这个特殊的302(表示http重定向)正是我们在Developer Tools看到的状态值,看到这个已经可以80%确定我们登录已经成功了,更重要的是返回包中的内容:Location: ./index.php,这说明控制台已经通知请求端跳转到index.php,如果登录失败控制台会继续停留在当前登录界面的,我们只需要修改curl语句中的用户名或者密码就知道了,这种情况下返回包就是登录界面的php源码,这里不再赘述。
使用cURL以get方式测试控制台搜索接口
测试方法同上面差不多,首先使用chrome打开控制台进入对应页面,在搜索框中输入“test.exe”,点击搜索,使用developer tools抓包,内容如下:

cURL模拟get方式发送数据的参数是-G,了解这个后面要模拟就很简单了:
curl -i --compressed -G “cloud/index.php?r=file_cloud/api/search&filename=&bg=0&lm=19 ”
其中每个参数的含义要分别了解:filename表示输入的关键字,bg表示数据库第一行,lm表示共显示19行数据。这个接口返回的数据如下:
{"rows":[{"level":"10","plevel":"10","id":"20","md5":"","soft_name":"","soft_desc":"","file_desc":"","is_sys_file":"127","size":"41984","is_rep":"0","file_name":"apihex86.d
ll","file_version":"6.1.7600.16385","proct_version":"6.1.7600.16385","right":"\u00a9 Microsoft Corporation. All rights reserved.","lang":"0","org_name":"YXBpaGV4ODYuZGxs","sign_name":"TWljcm9zb2Z0IFdpbmRvd3M=","company_name":"Microsof
t Corporation","update_time":"2012-07-31 18:14:27","create_time":"2012-07-31 18:14:27","creator_mid":""}],"count":"1"}
分别是文件属性和文件信息,这涉及到两个数据库表,所以验证数据需要用python从两张表中获取对应信息。
从第一张表获取文件属性,比如只获取plevel:
SELECT plevel FROM `file` where md5=""
从第二张表获取文件信息,比如只获取company_name:
SELECT company_name FROM file_info where md5=""
Python代码如下:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

conn = MySQLdb.connect(host='%s'% self.host, user='user',passwd='test321',db='cloud')

cursor = conn.cursor()

count = cursor.execute('SELECT plevel FROM `file` where md5=""')

result = cursor.fetchone()

self.assertNotEqual(response.find(str(result[0])),-1)

count = cursor.execute('SELECT company_name FROM file_info where md5=""')

result1 = cursor.fetchone()

self.assertNotEqual(response.find(result1[0]),-1)

当然严谨的测试案例是每一个属性字段都需要进行查找和匹配,这里就不再赘述了。
后记:这种接口测试用到的无非就是curl、python的unitest而已,可能有的人会疑问,为什么用curl而不用py自带的pycurl或者request之类,我觉得只要能满足需求,能够用现成的就用现成的,怎么简单怎么来。搞一堆代码维护起来也麻烦啊,现在qa行业跳槽也比较频繁,万一换了个人看不懂你的代码怎么办?呵呵

❻ 纯 Python 写一个 Web 框架,就是这么简单

造轮子是最好的一种学习方式,本文尝试从0开始造个Python Web框架的轮子,我称它为 ToyWebF 。

本文操作环境为:MacOS,文中涉及的命令,请根据自己的系统进行替换。

ToyWebF的简单特性:

下面我们来实现这些特性。

首先,我们需要安装gunicorn,回忆一下Flask框架,该框架有内置的Web服务器,但不稳定,所以上线时通常会替换成uWSGI或gunicorn,这里不搞这个内置Web服务,直接使用gunicorn。

我们创建新的目录与Python虚拟环境,在该虚拟环境中安装gunicorn

在啥都没有的情况下,构建最简单的Web服务,在ToyWebF目录下,创建app.py与api.py文件,写入下面代码。

运行 gunicorn app:app 访问 http://127.0.0.1:8000 ,可以看见 Hello, World! ,但现在请求体中的参数在environ变量中,难以解析,我们返回的response也是bytes形式。

我们可以使用webob库,将environ中的数据转为Request对象,将需要返回的数据转为Response对象,处理起来更加直观方便,直接通过pip安装一下。

然后修改一下API类的 __call__方法 ,代码如下。

上述代码中,通过webob库的Request类将environ对象(请求的环境信息)转为容易处理的request,随后调用handle_request方法对request进行处理,处理的结果,通过response对象返回。

handle_request方法在ToyWebF中非常重要,它会匹配出某个路由对应的处理方法,然后调用该方法处理请求并将处理的结果返回,在解析handle_request前,需要先讨论路由注册实现,代码如下。

其实就是将路由和方法存到self.routes字典中,可以通过route装饰器的形式将路由和方法关联,也可以通过add_route方法关联,在app.py中使用一下。

因为url中可以存在变量,如 @app.route("/hello/{name}") ,所以在匹配时,需要进行解析,可以使用正则匹配的方式进行匹配,parse这个第三方库已经帮我们实现了相应的正则匹配逻辑,pip安装使用一下则可。

这里定义find_handler方法来实现对self.routes的遍历。

了解了路由与方法关联的原理后,就可以实现handle_request方法,该方法主要的路径就是根据路由调度对应的方法,代码如下。

在该方法中,首先实例化webob库的Response对象,然后通过self.find_handler方法获取此次请求路由对应的方法和对应的参数,比如。

它将返回hello方法对象和name参数,如果是 /hello/二两 ,那么name就是二两。

因为route装饰器可能装饰器的类对象,比如。

此时self.find_handler方法返回的hanler就是个类,但我们希望调用的是类中的get、post、delete等方法,所以需要一个简单的判断逻辑,通过inspect.isclass方法判断handler如果是类对象,那么就通过getattr方法获取类对象实例的中对应的请求方法。

如果类对象中没有该方法属性,则抛出该请求类型不被允许的错误,如果不是类对象或类对象中存在该方法属性,则直接调用则可。

此外,如果方法的路由并没有注册到self.routes中,即404的情况,定义了defalut_response方法返回其中内容,代码如下。

如果handle_request方法中调度的过程出现问题,则直接raise将错误抛出。

至此,一个最简单的web服务就编写完成了。

回顾Flask,Flask可以支持HTML、CSS、JavaScript等静态文件,利用模板语言,可以构建出简单但美观的Web应用,我们让TopWebF也支持这一功能,最终实现图中的网站,完美兼容静态文件。

Flask使用了jinja2作为其html模板引擎,ToyWebF同样使用jinja2,jinja2其实实现一种简单的DSL(领域内语言),让我们可以在HTML中通过特殊的语法改变HTML的结构,该项目非常值得研究学习。

首先 pip install jinja2 ,然后就可以使用它了,在ToyWebF项目目录中创建templates目录,以该目录作为默认的HTML文件根目录,代码如下。

首先利用jinja2的FileSystemLoader类将file system中的某个文件夹作为loader,然后初始化Environment。

在使用的过程中(即调用template方法),通过get_template方法获得具体的某个模板并通过render方法将对应的内容传递给模板中的变量。

这里我们不写前端代码,直接去互联网中下载模板,这里下载了Bootstrap提供的免费模板,可以自行去 https://startbootstrap.com/themes/freelancer/ 下载,下载完后,你会获得index.html以及对应的css、jss、img等文件,将index.html移动到ToyWebF/templates中并简单修改了一下,添加一些变量。

然后在app.py文件中为index.html定义路由以及需要的参数。

至此html文件的支持就完成了,但此时的html无法正常载入css和js,导致页面布局非常丑陋且交互无法使用。

接着就让ToyWebF支持css、js,首先在ToyWebF目录下创建static文件夹用于存放css、js或img等静态文件,随后直接将前面下载的模板,其中的静态文件复制到static中则可。

通过whitenoise第三方库,可以通过简单的几行代码让web框架支持css和js,不需要依赖nginx等服务,首先 pip install whitenoise ,随后修改API类的 __init__ 方法,代码如下。

其实就是通过WhiteNoise将self.wsgi_app方法包裹起来,在调用API的 __call__ 方法时,直接调用self.whitenoise。

此时,如果请求web服务获取css、js等静态资源,WhiteNoise会获取其内容并返回给client,它在背后会匹配静态资源在系统中对应的文件并将其读取返回。

至此,一开始的网页效果就实现好了。

web服务如果出现500时,默认会返回 internal server error ,这显得比较丑,为了让框架使用者可以自定义500时返回的错误,需要添加一些代码。

首先API初始化时,初始self.exception_handler对象并定义对应的方法添加自定义的错误

在handler_request方法进行请求调度时,调度的方法执行逻辑时报500,此时不再默认将错误抛出,而是先判断是否有自定义错误处理。

在app.py中,自定义错误返回方法,如下。

custom_exception_handler方法只返回自定义的一段话,你完全可以替换成美观的template。

我们可以实验性定义一个路由来看效果。

Web服务的中间件也可以理解成钩子,即在请求前可以对请求做一些处理或者返回Response前对Response做一下处理。

为了支持中间件,在TopWebF目录下创建middleware.py文件,在编写代码前,思考一下如何实现?

回顾一下现在请求的调度逻辑。

1.通过routes装饰器关联路由和方法 2.通过API.whitenoise处理 3.如果是请求API接口,那么会将参数传递给API.wsgi_app 4.API.wsgi_app最终会调用API.handle_request方法获取路由对应的方法并调用该方法执行相应的逻辑

如果希望在request前以及response后做相应的操作,那么其实就需要让逻辑在API.handle_request前后执行,看一下代码。

其中add方法会实例化Middleware对象,该对象会将当前的API类实例包裹起来。

Middleware.handle_request方法其实就是在self.app.handle_request前调用self.process_request方法处理request前的数据以及调用self.process_response处理response后的数据,而核心的调度逻辑,依旧交由API.handle_request方法进行处理。

这里的代码可能会让人感到疑惑, __call__ 方法和handle_request方法中都有self.app.handle_request(request),但其调用对象似乎不同?这个问题暂时放一下,先继续完善代码,然后再回来解释。

接着在api.py中为API创建middleware属性以及添加新中间件的方法。

随后,在app.py中,自定义一个简单的中间件,然后调用add_middleware方法将其添加。

定义好中间件后,在请求调度时,就需要使用中间件,为了兼容静态文件的情况,需要对css、js、ing文件的请求路径做一下兼容,在其路径中加上/static前缀

紧接着,修改API的 __call__ ,兼容中间件和静态文件,代码如下。

至此,中间件的逻辑就完成了。

但代码中依旧有疑惑,Middleware类中的 __call__ 方法和handle_request方法其调用的self.app到底是谁?

为了方便理解,这里一步步拆解。

如果没有添加新的中间件,那么请求的调度逻辑如下。

在没有添加中间件的情况下,self.app其实就是API本身,所以 middleware.__call__ 中的self.app.handle_request就是调用API.handle_request。

如果添加了新的中间件,如上述代码中添加了名为SimpleCustomMiddleware的中间件,此时的请求调度逻辑如下。

因为注册中间件时,Middleware.add方法替换了原始Middleware实例中的app对象,将其替换成了SimpleCustomMiddleware,而SimpleCustomMiddleware也有app对象,SimpleCustomMiddleware中的app对象,才是API类实例。

在请求调度的过程中,就会触发Middleware类的handle_request方法,该方法就会执行中间件相应的逻辑去处理request和response中的数据。

当然,你可以通过Middleware.add方法添加多个中间件,这就会构成栈式调用的效果,代码如下。

启动web服务后,其执行效果如下。

❼ python web开发 用什么工具

python web开发常用的工具:

1. Django

Django无疑是最通用的web开发框架之一,适用博客做一个后端和为企业做一个内容管理系统。

优点:从几乎为零的状态建设出一个全功能的web应用程序。


备注:Python面向对象的设计非常干净,而且配备了令人难以置信的支持库。Python可以很容易地与其他流行的编程语言如Java,C和C ++集成。