wsgiref模块版web框架

wsgiref模块版web框架

wsgiref模块其实就是将整个请求信息给封装了起来，就不需要你自己处理了，假如它将所有请求信息封装成了一个叫做request的对象，那么你直接request.path就能获取到用户这次请求的路径，request.method就能获取到本次用户请求的请求方式(get还是post)等，那这个模块用起来，我们再写web框架是不是就简单了好多。

　　　　对于真实开发中的python web程序来说，一般会分为两部分：服务器程序和应用程序。

　　　　服务器程序负责对socket服务器进行封装，并在请求到来时，对请求的各种数据进行整理。

　　　　应用程序则负责具体的逻辑处理。为了方便应用程序的开发，就出现了众多的Web框架，例如：Django、Flask、web.py 等。不同的框架有不同的开发方式，但是无论如何，开发出的应用程序都要和服务器程序配合，才能为用户提供服务。

　　　　这样，服务器程序就需要为不同的框架提供不同的支持。这样混乱的局面无论对于服务器还是框架，都是不好的。对服务器来说，需要支持各种不同框架，对框架来说，只有支持它的服务器才能被开发出的应用使用。最简单的Web应用就是先把HTML用文件保存好，用一个现成的HTTP服务器软件，接收用户请求，从文件中读取HTML，返回。如果要动态生成HTML，就需要把上述步骤自己来实现。不过，接受HTTP请求、解析HTTP请求、发送HTTP响应都是苦力活，如果我们自己来写这些底层代码，还没开始写动态HTML呢，就得花个把月去读HTTP规范。

正确的做法是底层代码由专门的服务器软件实现，我们用Python专注于生成HTML文档。因为我们不希望接触到TCP连接、HTTP原始请求和响应格式，所以，需要一个统一的接口协议来实现这样的服务器软件，让我们专心用Python编写Web业务。

　　　　这时候，标准化就变得尤为重要。我们可以设立一个标准，只要服务器程序支持这个标准，框架也支持这个标准，那么他们就可以配合使用。一旦标准确定，双方各自实现。这样，服务器可以支持更多支持标准的框架，框架也可以使用更多支持标准的服务器。

　　　　WSGI（Web Server Gateway Interface）就是一种规范，它定义了使用Python编写的web应用程序与web服务器程序之间的接口格式，实现web应用程序与web服务器程序间的解耦。

　　　　常用的WSGI服务器有uwsgi、Gunicorn。而Python标准库提供的独立WSGI服务器叫wsgiref，Django开发环境用的就是这个模块来做服务器。

利用wsgiref写一个简单的web server端程序：

from wsgiref.simple_server import make_server

# wsgiref本身就是个web框架，提供了一些固定的功能
# 请求和响应信息的封装，不需要我们自己写原生的socket了也不需要咱们自己来完成请求信息的提取了，提取起来很方便
def application(environ,start_response):
	'''
	environ:是全部加工好的请求信息，加工成了一个字典，通过字典取值的方式就能拿到很多你想要拿到的信息
	start_response: 帮你封装响应信息的（响应行和响应头），注意下面的参数
	'''
    #200 OK必须得有~后面的两个键值对可以不加~具体看需求
	start_response('200 OK',[('Content-Type','text/html'),('k1','v1')])
	
	print(environ)
	##输入地址127.0.0.1:8080，这个打印的是'/',输入的是127.0.0.1:8080/index，打印结果是'/index'
	print(environ['PATH_INFO'])
    #注意最后return的是：列表里面是bytes类型的数据！
	return [b'<h1>Hello Web</h1>']

if __name__ == '__main__':
	http_obj = make_server('127.0.0.1',8080,application)

	print('Serving HTTP on port 8080...')
	#开始监听HTTP请求
	http_obj.serve_forever()