GET方法和POST方法的区别

1、GET方法多用于不改变系统设置的情况;比如获取数据。但是也可以用来向服务器传递数据。方法是把参数义键值对的形式放到URL里面。数据量有限制。

POST方法用于改变服务器的设置,向服务器传递数据。方法是把数据放到传送体里面,不在URL里面显示。而且数据量没有限制。

Http 状态码一览表

Monday, March 20th, 2006

1**:请求收到,继续处理
2**:操作成功收到,分析、接受
3**:完成此请求必须进一步处理
4**:请求包含一个错误语法或不能完成
5**:服务器执行一个完全有效请求失败

100——客户必须继续发出请求
101——客户要求服务器根据请求转换HTTP协议版本

200——交易成功
201——提示知道新文件的URL
202——接受和处理、但处理未完成
203——返回信息不确定或不完整
204——请求收到,但返回信息为空
205——服务器完成了请求,用户代理必须复位当前已经浏览过的文件
206——服务器已经完成了部分用户的GET请求

300——请求的资源可在多处得到
301——删除请求数据
302——在其他地址发现了请求数据
303——建议客户访问其他URL或访问方式
304——客户端已经执行了GET,但文件未变化
305——请求的资源必须从服务器指定的地址得到
306——前一版本HTTP中使用的代码,现行版本中不再使用
307——申明请求的资源临时性删除

400——错误请求,如语法错误
401——请求授权失败
402——保留有效ChargeTo头响应
403——请求不允许
404——没有发现文件、查询或URl
405——用户在Request-Line字段定义的方法不允许
406——根据用户发送的Accept拖,请求资源不可访问
407——类似401,用户必须首先在代理服务器上得到授权
408——客户端没有在用户指定的饿时间内完成请求
409——对当前资源状态,请求不能完成
410——服务器上不再有此资源且无进一步的参考地址
411——服务器拒绝用户定义的Content-Length属性请求
412——一个或多个请求头字段在当前请求中错误
413——请求的资源大于服务器允许的大小
414——请求的资源URL长于服务器允许的长度
415——请求资源不支持请求项目格式
416——请求中包含Range请求头字段,在当前请求资源范围内没有range指示值,请求
也不包含If-Range请求头字段
417——服务器不满足请求Expect头字段指定的期望值,如果是代理服务器,可能是下
一级服务器不能满足请求

500——服务器产生内部错误
501——服务器不支持请求的函数
502——服务器暂时不可用,有时是为了防止发生系统过载
503——服务器过载或暂停维修
504——关口过载,服务器使用另一个关口或服务来响应用户,等待时间设定值较长
505——服务器不支持或拒绝支请求头中指定的HTTP版本

 

==========================================================

英文版:

100:Continue
101:Switching Protocols
102:Processing

200:OK
201:Created
202:Accepted
203:Non-Authoriative Information
204:No Content
205:Reset Content
206:Partial Content
207:Multi-Status

300:Multiple Choices
301:Moved Permanently
302:Found
303:See Other
304:Not Modified
305:Use Proxy
306:(Unused)
307:Temporary Redirect

400:Bad Request
401:Unauthorized
402:Payment Granted
403:Forbidden
404:File Not Found
405:Method Not Allowed
406:Not Acceptable
407:Proxy Authentication Required
408:Request Time-out
409:Conflict
410:Gone
411:Length Required
412:Precondition Failed
413:Request Entity Too Large
414:Request-URI Too Large
415:Unsupported Media Type
416:Requested range not satisfiable
417:Expectation Failed
422:Unprocessable Entity
423:Locked
424:Failed Dependency

500:Internal Server Error
501:Not Implemented
502:Bad Gateway
503:Service Unavailable
504:Gateway Timeout
505:HTTP Version Not Supported
507:Insufficient Storage

关于一个点歌社交网络的构想

来源:Oneplus

在广播还比较流行的二十几年前,电台点歌是件非常时髦的事情。当时,人们可接触的文化媒介并不丰富,沟通方式也受到多方面的制约。点歌成了传达感情的一种浪漫而有效的方式。可惜这一美好的形式随着广播的没落而逐渐淡出人们的视线。

Web2.0时代,社交网络大面积兴起,Facebook、Twitter、豆瓣等等,成功的产品无一不是抓住了人与人之间的合理聚合点。“点歌”这一形式,虽然因为时间的推移而被人们遗忘,但是依旧具有强大的聚合力。首先,因为愈来愈大的社会、经济、生活压力,使得人们进行传统社交的时间愈来愈少。其次,文字图片类的社交网络,随着人们的广泛参与呈现出信息过载的趋势。在表达丰富复杂感情时,往往显得浅薄。点歌的形式,一方面,并不要求施事与受事者同时参与,保证了时空的相对自由;一方面,相对文字图片,要求参与者做出诸如选曲、赠言等等更多的工作,在表情达意方面有着先天的优势。

基于上述一些想法,我认为,一个以“点歌”聚合的社交网络,在当下是有需求的。

我在Google、百度等搜索引擎中查询“点歌”、“点歌网站”,反馈的结果都是提供手机点歌服务的网站,并没有与上述想法契合的网站。依此,我认为,一个以“点歌”聚合的社交网络,在当下是有生存空间的。

细化这一构想,我认为,可以提供下面一些服务:

  • 注册会员之间可以点歌赠言
  • 有一个公共广播,播出公开的点歌赠言,并且可以评论寄语
  • 系统进行音乐、好友、唱片电商等推荐

这一社交网络的学术价值,显而易见。可以收集大量用户行为数据,甚至可以将点歌视为一种人工标注,开展“推荐”、“情感分析”等多方面课题研究。

当然,作为一个信息提供商,特别是音乐这一版权敏感的信息服务,运营是一件非常具有挑战的工作。在这方面我并没有什么经验或者好的想法。但是觉得,可以通过在高校里推广这一服务规避版权问题。

这篇文章的主要目的是浅尝辄止地分析这样一种社交网络形式。由于自己并非从事产品与市场方面的工作,对于问题的看法难免片面。还希望有缘人多提宝贵意见。更重要的是,虽然,我觉得这个创意还好,但是没有时间与精力去实现它。所以更希望有时间精力的小同学们愿意在将来的软件工程课上把它变成现实。

随手山寨了一个效果图,避雷针自备了。