Category: Web开发

HTML也可以实现文件包含

我们知道,很多编程语言都有包含文件的功能,所以代码结构相对比较灵活,
但HTML作为一种文本标记语言,默认是不支持文件包含的!
但是,我们可以通过配置Web服务器让HTML支持文件包含!

SSI(Server Side Include),通常称为"服务器端嵌入"或者叫"服务器端包含",是一种类似ASP基于服务器的网页制作技术。
默认扩展名是 .stm、.shtm 和 .shtml
但我们常用的是是html,如果要在扩展名为 html 的文件使用SSI,就需要对 Apache 进行配置

以 Apache2.2 为例,编辑 httpd.conf,

1、搜索 AddType 和 AddOutputFilter,源码如下:

# Filters allow you to process content before it is sent to the client.
#
# To parse .shtml files for server-side includes (SSI):
# (You will also need to add "Includes" to the "Options" directive.)
#
# AddType text/html .shtml
# AddOutputFilter INCLUDES .shtml

默认是被注释的,需要去掉注释,修改成如下:

# Filters allow you to process content before it is sent to the client.
#
# To parse .shtml files for server-side includes (SSI):
# (You will also need to add "Includes" to the "Options" directive.)
#
AddType text/html .html .shtml
AddOutputFilter INCLUDES .html .shtml

2、搜索 Options Indexes FollowSymLinks 在后面加上 INCLUDES

注意,SSI 确实可以利用 Shell 来执行命令,这个功能是极度危险的,因为它会执行任何包含在 exec 标记中的命令。
如果用户有可能修改你的网页内容,那么你一定要关闭这个功能。
可以在 Options 指令中加上 IncludesNOEXEC 参数,以关闭 exec 功能,同时又保留 SSI。

<Directory /usr/local/www/979137.com>
    Options Includes FollowSymLinks
    AllowOverride None
</Directory>

3、重启Apache,可以使用 include 语法了,如:

<!--#include virtual="/header.html" -->

include 元素能按 file 属性或 virtual 属性判断应该包含的文件。
file 属性是一个相对于当前目录的文件路径,即不能是一个绝对路径(以"/"开头)或包含"../"的路径。
virtual 属性可能更有用,它是一个相对于被提供的文档的URL ,可以以"/"开头,但必须与被提供的文档位于同一服务器上。

PHP也支持多线程:cURL并发请求

PHP cURL所有函数列表:
https://secure.php.net/manual/zh/ref.curl.php

以下是PHP中cURL多线程相关函数:

  • curl_multi_add_handle — 向curl批处理会话中添加单独的curl句柄
  • curl_multi_close — 关闭一组cURL句柄
  • curl_multi_exec — 运行当前 cURL 句柄的子连接
  • curl_multi_getcontent — 如果设置了CURLOPT_RETURNTRANSFER,则返回获取的输出的文本流
  • curl_multi_info_read — 获取当前解析的cURL的相关传输信息
  • curl_multi_init — 返回一个新cURL批处理句柄
  • curl_multi_remove_handle — 移除curl批处理句柄资源中的某个句柄资源
  • curl_multi_select — 等待所有cURL批处理中的活动连接
  • curl_multi_setopt — 为 cURL 并行处理设置一个选项
  • curl_multi_strerror — Return string describing error code

一般来说,想到要用这些函数时,目的显然应该是要同时请求多个URL,而不是一个一个依次请求,否则不如自己循环去调curl_exec好了。

步骤总结如下:

1、调用 curl_multi_init,初始化一个批处理handle
2、循环调用 curl_multi_add_handle,往1中的批处理handle 添加curl_init来的子handle
3、持续调用 curl_multi_exec,直到所有子handle执行完毕。
4、根据需要循环调用 curl_multi_getcontent 获取结果
5、调用 curl_multi_remove_handle,并为每个字handle调用curl_close
6、调用 curl_multi_close

以下是一个通过并发请求抓取网页的demo

$urls = array(
    'https://979137.com/',
    'http://www.sina.com.cn/',
    'http://www.sohu.com/',
    'http://www.163.com/'
);

//1、初始化一个批处理handle
$mh = curl_multi_init();

//2、往批处理handle 添加curl_init来的子handle
foreach ($urls as $i => $url) {
    $conn[$i] = curl_init($url);
    curl_setopt($conn[$i], CURLOPT_HEADER, 0);   
    curl_setopt($conn[$i], CURLOPT_CONNECTTIMEOUT, 60);
    curl_setopt($conn[$i], CURLOPT_RETURNTRANSFER, true);
    curl_multi_add_handle($mh, $conn[$i]);
}

//3、并发执行,直到全部结束。
do {
    curl_multi_exec($mh, $active);
} while ($active);

//4、获取结果
foreach ($urls as $i => $url) {
    $data = curl_multi_getcontent($conn[$i]);
    echo ($data);
}

//5、移除子handle,并close子handle
foreach ($urls as $i => $url) {
    curl_multi_remove_handle($mh,$conn[$i]);
    curl_close($conn[$i]);
}

//6、关闭批处理handle
curl_multi_close($mh);

在新浪云SAE架构一个大型Web应用到底有多简单

一般大型Web应用是指具有大流量、高并发、海量数据等特征的Web应用,
支撑此类应用,必需要一个安全、高可靠、可扩展、易维护的动态平台,才能保证应用的平稳运行。

下面我们先来聊聊,如何架构一个支撑大型Web应用的动态平台?

上图是较多大型应用采用的架构模式(实际应用中,会随着业务和需求的复杂程度,而出现更多更复杂的多层架构)

1、分布式Web服务器

如前言所述,大型应用,具有大流量、高并发的特征,一台服务器,显然无法满足需求。
以一个日均8亿PV的网站为例,根据PV我们计算出每秒的并发为1万,并发峰值是3.7万(每天80%的访问集中在20%的时间里,这20%时间叫做峰值时间),如果要保证100QPS,则至少需要400台服务器一起分担压力。
另外,大型应用业务普遍比较复杂,业务拆分是很常见的架构模式,如微博平台针对用户的行为、关系、设置等从技术架构中进行了业务拆分。

2、负载均衡系统

负载均衡和分布式Web服务器可以说是“连体婴儿”,负载均衡系统是所有请求的入口,请求到达时,根据分发策略将请求分发到健康的Web服务器节点,从而实现对请求的合理调度。
负载均衡分为硬件和软件两种。硬件负载均衡效率高,但是价格贵。软件负载均衡系统价格较低或者免费,但效率较硬件负载均衡系统低,常见的如LVS、Nginx,软硬负载均衡系统并用也是常见的均衡方式。

3、CDN、反向代理

大型应用普遍用户量都非常庞大,遍布全国各地,甚至全球,并且处于不同的网络环境。所以需要CDN,去解决跨地区、跨运营商的访问速度问题。反向代理,则是部署在应用所在机房,请求到达时,首先访问反向代理服务器,反向代理服务器将缓存的数据返回给用户,如果没有缓存数据才会继续走应用服务器获取,减少获取数据的成本。反向代理有Squid、Nginx等

4、分布式数据库系统

很多大型应用都会面临一个数据库性能瓶颈问题,海量数据如何存储?高并发情况下如果保证数据库负载问题?复杂业务逻辑如何保证数据的一致性、安全性?大流量面前如果保证查询效率?
一个大型应用,必然需要一个高可靠的、可以提供大规模并发处理的数据库体系,如此才能保证整个应用的高可靠性。
一般数据库系统都会同时使用关系型(如MySQL)数据库和非关系型(即NoSQL,如MongoDB、Redis)数据库,以满足不同的业务场景。
在分布式部署的基础上,还会采用主从架构、读写分离,主库抗写压力,通过从库来分担读压力。

5、分布式缓存系统

在海量数据、大流量、高并发面前,光有高可靠的分布式数据库系统,是远远不够的!
缓存技术是关键,在大型Web应用中使用最多且效率最高的是内存缓存,最常用的内存缓存工具是Memcached。
一个好的缓存机制,可以提高访问效率、提高服务器吞吐能力、减轻数据库系统和文件系统的访问压力。
分布式缓存系统,则可以避免单点故障,提高性能,提供高可靠性和可扩展性,巨大容量的缓存池,也可以将发生宕机时缓存的穿透率维持在一个很低的水平。

6、分布式文件系统

大规模存储,也是大型应用一大特征,如图片、视频、音乐、压缩包等等。
因此高性能的分布式存储系统对于大型应用来说是非常重要的一环。

7、代码发布系统

从 本地开发 到 生产环境(测试),再到 灰度发布,再到 全网发布,
为了满足分布式环境下程序代码的批量分发和更新,大型应用都需要一个代码发布系统和机制。

8、分布式服务器管理系统

文章开头,我们提出一个 “易维护” 概念,何谓 “易维护”?
就是能够集中式的、分组的、批量的、自动化的对所有服务器进行管理,能够批量化的执行计划任务。
常见的集中配置管理系统和软件有:puppet、Cfengine

OK!到此,我们大概地全面描述了一个支撑大型Web应用的动态平台架构。
那么问题来了,架构一个这样的动态平台,需要多少人力成本?周期?IT成本?稳定性?安全性?可靠性?

你也许看到过诸如 “如何理解云计算中的IaaS、PaaS和SaaS”、“PaaS和IaaS的区别”、“为什么选择PaaS” 等等之类的文章。
现在请先忘了那些乱七八糟的概念,这一次,我们站在实际用例的角度,看看国内领先的 PaaS 云平台SAE是如何优雅的帮你解决以上问题的!

一张图告诉你,在SAE架构一个大型Web应用到底有多简单!

如你所见,SAE用成熟稳定的技术,帮您解决了所有问题,开发者只需专注于业务本身(写自己的代码,让别人加班去吧!)

1、分布式Web服务器

分布式部署是PaaS的天然特性,自然也是SAE的一大特性,在SAE的所有应用均是分布式部署,相当于每台Web服务器上都有代码,避开单点故障问题,稳定性不言而喻。
SAE的Web服务器,相当于纯粹的代码运行环境,我们先且称之为SAE Runtime吧!
SAE通过沙箱机制,将代码、数据、连接数、内存、CPU进行了安全隔离,保证了应用的绝对安全性。
看完这篇文章,你会发现,其实SAE全平台的Web服务都是分布式的。

2、负载均衡系统

SAE的Web服务器采用分布式部署的架构,这就需要均衡每一台服务器的负载,从而保证每一个请求的访问速度。
SAE通过7层(至于为什么叫7层,可能是因为它工作在OSI 7层网络模型的第7层应用层吧)经分析后转发到负载相对较小的Web服务器上。

3、CDN、反向代理

SAE的负载均衡服务器部署在电信机房,为了保证跨运营商访问速度,SAE在各大运营商的机房都有代理,代理通过专线和电信机房连接。
SAE拥有覆盖全国各大城市的多路(电信、联通、移动、教育)骨干网络CDN节点,用户只需简单的开启操作,就能使用高质量的CDN服务。

4、分布式数据库系统

SAE提供了MySQL、NoSQL(KVDB)两种分布式数据库服务,
SAE每组MySQL都采用 一主多从加一备份 的设计,充分保证了数据库的性能,以及数据的可靠性。
KVDB是SAE开发的分布式key-value数据存储服务,用来支持公有云计算平台上的海量key-value存储。KVDB支持的存储容量很大,对每个用户支持100G的存储空间,可支持1,000,000,000条记录。
KVDB是高性能高可靠存储,读写可达10W QPS。KVDB采用一主多从的分布式架构, SAE提供热备和定期冷备,发生宕机时,会自动切换到健康的DB上。

5、分布式缓存系统

SAE Memcache,是SAE为开发者提供分布式缓存服务。SAE Memcache采用企业级规模的缓存池。巨大容量的缓存池,将发生宕机时缓存的穿透率维持在一个很低的水平。同时支持无缝扩容,domain等概念。较传统Memcache更加稳定、可靠、高效。

6、分布式文件系统

Storage是 SAE 利用自身在分布式以及网络技术方面的优势为开发者提供的安全、高效的分布式对象存储服务,支持文本、多媒体、二进制等任何类型的数据的存储。开发者可通过客户端简单的完成文件的管理操作,SAE还提供了完整的 Storage API,以满足开发者的所有应用场景。

7、代码发布系统

在SAE,通过svn或git完成代码发布。代码提交后,SAE CodeFS会自动同步到所有Web服务器。

8、分布式服务器管理系统

......
(为什么是点点点??在SAE,你可以忘记这玩意了,因为在SAE是完全免运维的,开发者不需要管理自己的服务器,一切运维都交给了SAE!)

看到这里,你会发现,在SAE,其实每一个应用都是以大型应用的标准和规格运行着!

除此以外,SAE还提供了丰富的符合开发者实际业务场景的分布式Web服务,如:
DDoS防火墙/应用防火墙、FetchURL(分布式网页抓取服务)、Cron(分布式计划任务服务)、TaskQueue(分布式任务队列服务)、Channel(实时消息推送服务)、Push(手机通知推送服务,同时支持iOS、Android)等等,因为服务较多,为不使文章篇幅太长,就不一一介绍了!

如上,便是SAE(SinaAppEngine,http://sae.sina.com.cn)的魅力所在!

国内外免费CDN公共JS库,前端公共库、常用JavaScript库CDN服务

做前端的开发者们经常需要用到一些公共的JS库,用户量大了JS库会消耗不少服务器资源。
为了给用户更好的访问体验,给自己网站减小服务器压力,推荐大家几个我感觉比较好的国内互联网大佬们提供的免费公共JS库。

又拍云:http://jscdn.upai.com
支持HTTPS
库有点少

七牛云:http://www.staticfile.org
库很全

百度:
静态库版:http://cdn.code.baidu.com
开发者版:http://developer.baidu.com/wiki/index.php?title=docs/cplat/libs
百度实力强大

新浪:http://lib.sinaapp.com
SAE挂掉的时候会加载不出来
支持HTTPS
库有点老

奇虎360:http://libs.useso.com
支持Google公共库、字体库直接换域名加速
用起来总是不放心

Bootstrap:http://www.bootcdn.cn
资源丰富
与又拍合作
支持HTTPS

cdnjs.net:http://cdnjs.net
支持HTTPS
国内不知谁家提供的
库很全

Google:
部分国家地区已挂,不推荐了

微软:http://www.asp.net/ajax/cdn
国内速度不错
支持HTTPS
库较少

jsDelivr:http://www.jsdelivr.com
库很全
支持HTTPS

cdnjs:https://cdnjs.com
使用CloudFlare
支持HTTPS
库很全

JS实现完美身份证号有效性验证

根据〖中华人民共和国国家标准 GB 11643-1999〗中有关公民身份号码的规定,公民身份号码是特征组合码,由十七位数字本体码和一位数字校验码组成。排列顺序从左至右依次为:六位数字地址码,八位数字出生日期码,三位数字顺序码和一位数字校验码。

地址码表示编码对象常住户口所在县(市、旗、区)的行政区划代码。
出生日期码表示编码对象出生的年、月、日,其中年份用四位数字表示,年、月、日之间不用分隔符。
顺序码表示同一地址码所标识的区域范围内,对同年、月、日出生的人员编定的顺序号。顺序码的奇数分给男性,偶数分给女性。
校验码是根据前面十七位数字码,按照ISO 7064:1983.MOD 11-2校验码计算出来的检验码。

出生日期计算方法。
15位的身份证编码首先把出生年扩展为4位,简单的就是增加一个19或18,这样就包含了所有1800-1999年出生的人;
2000年后出生的肯定都是18位的了没有这个烦恼,至于1800年前出生的,那啥那时应该还没身份证号这个东东,⊙﹏⊙b汗...
下面是正则表达式:

出生日期1800-2099 (18|19|20)?\d{2}(0[1-9]|1[12])(0[1-9]|[12]\d|3[01])
身份证正则表达式 /^\d{6}(18|19|20)?\d{2}(0[1-9]|1[12])(0[1-9]|[12]\d|3[01])\d{3}(\d|X)$/i
15位校验规则 6位地址编码+6位出生日期+3位顺序号
18位校验规则 6位地址编码+8位出生日期+3位顺序号+1位校验位

校验位规则

公式:∑(ai×Wi)(mod 11)……………………………………(1)
公式(1)中:
i----表示号码字符从由至左包括校验码在内的位置序号;
ai----表示第i位置上的号码字符值;
Wi----示第i位置上的加权因子,其数值依据公式Wi=2^(n-1)(mod 11)计算得出。
i 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1
Wi 7 9 10 5 8 4 2 1 6 3 7 9 10 5 8 4 2 1

校验身份证号函数
//身份证号合法性验证 
//支持15位和18位身份证号
//支持地址编码、出生日期、校验位验证
function IdentityCodeValid(code) { 
    var city={11:"北京",12:"天津",13:"河北",14:"山西",15:"内蒙古",21:"辽宁",22:"吉林",23:"黑龙江 ",31:"上海",32:"江苏",33:"浙江",34:"安徽",35:"福建",36:"江西",37:"山东",41:"河南",42:"湖北 ",43:"湖南",44:"广东",45:"广西",46:"海南",50:"重庆",51:"四川",52:"贵州",53:"云南",54:"西藏 ",61:"陕西",62:"甘肃",63:"青海",64:"宁夏",65:"新疆",71:"台湾",81:"香港",82:"澳门",91:"国外 "};
    var tip = "";
    var pass= true;
    if(!code || !/^\d{6}(18|19|20)?\d{2}(0[1-9]|1[12])(0[1-9]|[12]\d|3[01])\d{3}(\d|X)$/i.test(code)){
        tip = "身份证号格式错误";
        pass = false;
    } else if(!city[code.substr(0,2)]){
        tip = "地址编码错误";
        pass = false;
    } else {
        //18位身份证需要验证最后一位校验位
        if(code.length == 18){
            code = code.split('');
            //∑(ai×Wi)(mod 11)
            //加权因子
            var factor = [ 7, 9, 10, 5, 8, 4, 2, 1, 6, 3, 7, 9, 10, 5, 8, 4, 2 ];
            //校验位
            var parity = [ 1, 0, 'X', 9, 8, 7, 6, 5, 4, 3, 2 ];
            var sum = 0;
            var ai = 0;
            var wi = 0;
            for (var i = 0; i < 17; i++) {
                ai = code[i];
                wi = factor[i];
                sum += ai * wi;
            }
            var last = parity[sum % 11];
            if(parity[sum % 11] != code[17]){
                tip = "校验位错误";
                pass =false;
            }
        }
    }
    if(!pass) alert(tip);
     return pass;
}
测试
var c = '130981199312253466';
var res= IdentityCodeValid(c);
alert(res);

全民https时代:如何免费获取SSL证书并部署到服务器

如今各大网站基本都披上了https,绿色的锁,看着好安全的样子,AppStore更是要求开发者必须使用https作为应用的服务器端接口协议。如今不上个https都没脸出来混?笔者思来想去,准备给自己的博客加个https,洋气一回

获得SSL证书:

免费的SSL证书有很多,这里推荐腾讯云,全球领先的云服务商,值得信赖!
腾讯云免费提供的证书是域名型免费版(DV)
首先进入腾讯云SSL产品页,点击购买,
https://cloud.tencent.com/product/ssl

选择免费版

输入域名和邮箱等信息

验证域名

下载证书

按照流程走完,就可以获得证书了!解压后可以获得支持多种Web服务器的证书

在服务器部署SSL功能(这里以NGINX为例)

server {
    listen  80; 
    listen  443 ssl;
    ...
    if ($server_port != 443) {
        rewrite (.*) https://$host$1 permanent;
    }
    # 证书包下Nginx目录内的crt文件路径,建议写绝对路径
    ssl_certificate  /home/www/hosts/979137.com.crt;
    # 证书包下Nginx目录内的key文件路径,建议写绝对路径
    ssl_certificate_key  /home/www/hosts/979137.com.key;
    ssl_session_timeout  5m;
    ssl_protocols SSLv2 SSLv3 TLSv1;
    ssl_ciphers ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP;
    ssl_prefer_server_ciphers on;
    ...
}

如果你希望你的网站同时支持http和https,把下面三行删掉就行!

if ($server_port != 443) {
    rewrite (.*) https://$host$1 permanent;
}

完成!重启NGINX,验证下,

very good !

不用OAuth授权,10行代码获取用户微博昵称

这种需求看似奇葩,其实很常见,比如你的应用或网站接入了微博登录,一般会在数据库维护用户绑定的微博唯一ID,但用户的可变信息一般不会存。
然后在一些专题页,用到了用户的微博头像和昵称,这时候如果用OAuth协议,需要先获取授权码,再获取token,再调用户信息接口 ...

如果你觉得太麻烦,那就来试试笔者的方法。笔者的微博:http://weibo.com/1864997710 ,直接cURL:

curl 'http://weibo.com/1864997710' -v

* About to connect() to weibo.com port 80 (#0)
* Trying 123.125.104.197... connected
> GET /1864997710 HTTP/1.1
> User-Agent: curl/7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3
> Host: weibo.com
> Accept: */*
>
< HTTP/1.1 302 Moved Temporarily < Server: WeiBo < Date: Thu, 18 Sep 2014 02:02:22 GMT < Content-Type: text/html; charset=utf-8 < Transfer-Encoding: chunked < Connection: close < Expires: Sat, 26 Jul 1997 05:00:00 GMT < P3P: CP="CURa ADMa DEVa PSAo PSDo OUR BUS UNI PUR INT DEM STA PRE COM NAV OTC NOI DSP COR" < Cache-Control: no-cache, no-store < Pragma: no-cache < Location: http://passport.weibo.com/visitor/visitor?a=enter&url=http%3A%2F%2Fweibo.com%2F1864997710&_rand=1411005742.125 < DPOOL_HEADER: alice97 < Set-Cookie: TC-Page-G0=4e714161a27175839f5a8e7411c8b98c;Path=/ < LB_HEADER: alice27 < * Closing connection #0

看来直接抓取用户主页的形式不靠谱,因为未登录,微博给你重定向了。

庆幸的是,微博还有一个页面,是不需要登录,而且恰好有微博昵称。
就是访问某人的微博时产生的邀请注册页,页面中会有TA的微博昵称,于是就呵呵了

下面这个函数,可以帮你实现,无需授权无需登录,根据微博ID获取微博昵称

这样做,有什么好处?
1.少写很多OAuth相关代码
2.也降低了多次http的网络消耗
3.实时性(也可以根据需要缓存起来)

RESTful 是什么?一起来理解 RESTful 架构

传统上,软件和网络是两个不同的领域,很少有交集;软件开发主要针对单机环境,网络则主要研究系统之间的通信。
互联网的兴起,使得这两个领域开始融合,即 "互联网软件",比网站、网络游戏、各种非单机版APP等,
这种"互联网软件"采用客户端/服务器(C/S)模式,建立在分布式体系上,通过互联网通信,具有高延时(high latency)、高并发等特点。

那么如何开发在互联网环境中使用的软件呢?

云厉的博客

RESTful架构,就是目前非常流行的一种互联网软件架构。
它结构清晰、符合标准、易于理解、扩展方便,所以正得到越来越多网站的采用。
但是,到底什么是RESTful架构,并不是一个容易说清楚的问题。下面,我就谈谈我理解的RESTful架构。

一、起源

REST 这个词,是Roy Thomas Fielding在他2000年的博士论文中提出的。

Fielding是一个非常重要的人,他是HTTP协议(1.0版和1.1版)的主要设计者、Apache服务器软件的作者之一、Apache基金会的第一任主席。
所以,他的这篇论文一经发表,就引起了关注,并且立即对互联网开发产生了深远的影响。
他这样介绍论文的写作目的:

本文研究计算机科学两大前沿----软件和网络----的交叉点。长期以来,软件研究主要关注软件设计的分类、设计方法的演化,很少客观地评估不同的设计选择对系统行为的影响。而相反地,网络研究主要关注系统之间通信行为的细节、如何改进特定通信机制的表现,常常忽视了一个事实,那就是改变应用程序的互动风格比改变互动协议,对整体表现有更大的影响。我这篇文章的写作目的,就是想在符合架构原理的前提下,理解和评估以网络为基础的应用软件的架构设计,得到一个功能强、性能好、适宜通信的架构。
(This dissertation explores a junction on the frontiers of two research disciplines in computer science: software and networking. Software research has long been concerned with the categorization of software designs and the development of design methodologies, but has rarely been able to objectively evaluate the impact of various design choices on system behavior. Networking research, in contrast, is focused on the details of generic communication behavior between systems and improving the performance of particular communication techniques, often ignoring the fact that changing the interaction style of an application can have more impact on performance than the communication protocols used for that interaction. My work is motivated by the desire to understand and evaluate the architectural design of network-based application software through principled use of architectural constraints, thereby obtaining the functional, performance, and social properties desired of an architecture. )

二、名称

Fielding将他对互联网软件的架构原则,定名为REST,即Representational State Transfer的缩写。我对这个词组的翻译是"表现层状态转化"。
如果一个架构符合REST原则,就称它为RESTful架构。
要理解RESTful架构,最好的方法就是去理解Representational State Transfer这个词组到底是什么意思,它的每一个词代表了什么涵义。
如果你把这个名称搞懂了,也就不难体会REST是一种什么样的设计。

三、资源(Resources)

REST的名称"表现层状态转化"中,省略了主语。"表现层"其实指的是"资源"(Resources)的"表现层"。
所谓"资源",就是网络上的一个实体,或者说是网络上的一个具体信息。它可以是一段文本、一张图片、一首歌曲、一种服务,总之就是一个具体的实在。
你可以用一个URI(统一资源定位符)指向它,每种资源对应一个特定的URI。
要获取这个资源,访问它的URI就可以,因此URI就成了每一个资源的地址或独一无二的识别符。
所谓"上网",就是与互联网上一系列的"资源"互动,调用它的URI。

四、表现层(Representation)

"资源"是一种信息实体,它可以有多种外在表现形式。我们把"资源"具体呈现出来的形式,叫做它的"表现层"(Representation)。
比如,文本可以用txt格式表现,也可以用HTML格式、XML格式、JSON格式表现,甚至可以采用二进制格式;图片可以用JPG格式表现,也可以用PNG格式表现。
URI只代表资源的实体,不代表它的形式。严格地说,有些网址最后的".html"后缀名是不必要的,因为这个后缀名表示格式,属于"表现层"范畴,而URI应该只代表"资源"的位置。它的具体表现形式,应该在HTTP请求的头信息中用Accept和Content-Type字段指定,这两个字段才是对"表现层"的描述。

五、状态转化(State Transfer)

访问一个网站,就代表了客户端和服务器的一个互动过程。在这个过程中,势必涉及到数据和状态的变化。
互联网通信协议HTTP协议,是一个无状态协议。这意味着,所有的状态都保存在服务器端。因此,如果客户端想要操作服务器,必须通过某种手段,让服务器端发生"状态转化"(State Transfer)。而这种转化是建立在表现层之上的,所以就是"表现层状态转化"。
客户端用到的手段,只能是HTTP协议。
具体来说,就是HTTP协议里面,四个表示操作方式的动词:GET、POST、PUT、DELETE。
它们分别对应四种基本操作:GET用来获取资源,POST用来新建资源(也可以用于更新资源),PUT用来更新资源,DELETE用来删除资源。

六、综述

综合上面的解释,我们总结一下什么是RESTful架构:

  • 每一个URI代表一种资源;
  • 客户端和服务器之间,传递这种资源的某种表现层;
  • 客户端通过四个HTTP动词,对服务器端资源进行操作,实现"表现层状态转化"。

七、误区

RESTful架构有一些典型的设计误区。

最常见的一种设计错误,就是URI包含动词。因为"资源"表示一种实体,所以应该是名词,URI不应该有动词,动词应该放在HTTP协议中。
举例来说,某个URI是/posts/show/1,其中show是动词,这个URI就设计不理想,正确的写法应该是/posts/1,然后用GET方法表示show。
如果某些动作是HTTP动词表示不了的,你就应该把动作做成一种资源。比如网上汇款,从账户1向账户2汇款500元,错误的URI是:

POST /accounts/1/transfer/500/to/2

正确的写法是把动词transfer改成名词transaction,资源不能是动词,但是可以是一种服务:

POST /transaction HTTP/1.1
Host: 127.0.0.1
from=1&to=2&amount=500.00

另一个设计误区,就是在URI中加入版本号:

http://www.example.com/app/1.0/foo
http://www.example.com/app/1.1/foo
http://www.example.com/app/2.0/foo

因为不同的版本,可以理解成同一种资源的不同表现形式,所以应该采用同一个URI。
版本号可以在HTTP请求头信息的Accept字段中进行区分

Accept: vnd.example-com.foo+json; version=1.0
Accept: vnd.example-com.foo+json; version=1.1
Accept: vnd.example-com.foo+json; version=2.0

PHP提取百度网盘真实下载地址

文件哪里存?当然选网盘,永久免费、容量够大、速度快。
不过下载是个问题,网盘一盘不提供直链,只能进入分享页手动下载,虽然下载后能看到直链,但这个直链是有时间限制的,也就是说那是临时的。

需求来了,当我们把文件存储到网盘后,并不希望用户跑到网盘去下载,而是点击链接就直接下载

下面提供一个封装好的百度网盘真实下载地址提取函数,有空再去研究研究微云的

function baiduPan($url) {
        if (strpos($url, 'pan.baidu.com') === false) return false;
        $ch = curl_init();
        curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
        curl_setopt($ch, CURLOPT_HEADER, false);
        curl_setopt($ch, CURLOPT_URL, $url);
        $html = curl_exec($ch);
        if (preg_match('/bdstoken="(.*?)".*?fsId="(.*?)".*?share_uk="(.*?)".*?share_id="(.*?)"/i', $html, $matches)) {
                $proxyUrl  = sprintf('http://pan.baidu.com/share/download?bdstoken=%s&uk=%s&shareid=%s&fid_list=%%5B%s%%5D', $matches[1], $matches[3], $matches[4], $matches[2]);
                curl_setopt($ch, CURLOPT_URL, $proxyUrl);
                $proxyHtml = curl_exec($ch);
                $jsonObj   = json_decode($proxyHtml, true);
                $downloadButtonUrl = $jsonObj['dlink'];
                $downloadButtonUrl = str_replace("\\\\/", "/", $downloadButtonUrl);
                curl_setopt($ch, CURLOPT_URL, $downloadButtonUrl);
                curl_setopt($ch, CURLOPT_VERBOSE, 1);
                curl_setopt($ch, CURLOPT_HEADER, 1);
                $result = curl_exec($ch);
                list($header, $body) = explode("\r\n\r\n", $result, 2);
                if (preg_match('/Location: (.*?)(\r?\n)/is', $header, $matches)) {
                        return $matches[1];
                }
        }
        return false;
}
$testurl = 'http://pan.baidu.com/share/link?shareid=3142223074&uk=1864945200';
$downurl = baiduPan($testurl);
//这个就是文件的真实下载地址,可以用浏览器或者下载工具试试
echo $downurl; 


规则是活的,代码是死的,所以无法保证可以永久使用,如发现无法正常使用,那就是网盘规则变了,需要自行修改代码咯,就个人经验来看,百度网盘一般两到三个月会更新一次,不过变化不会太大。

一款不错的弹窗/消息提示组件(ymPrompt),多功能、多风格

倒流’s Bolg

应该有很多人用过,这里分享给没用过的码农,可以考虑试试!
觉得还是挺不错的!功能比较多~

不多废话,直接看演示:包含使用简介,多种风格可选(若出现乱码,请确保浏览器的编码格式为GBK):
http://demo.979137.com/tools/ymPrompt

PS:
1、很多人说该组件效率不高。个人使用感受:如果负载不是特别高的网站,它对网站性能的影响微乎其微;一个高性能的WEB程序,前端的优化只是很小一部分。
2、有人觉得不好看,组件有7个风格可以选择,可以看看后面几个风格,页面可以直接设置预览,满足各种需求。
3、功能比较多,需要慢慢尝试

微信公众号:程序员到架构师

最新文章

Return Top