RESTful 架构详解

架构四月 12, 2019, 10:30 a.m. SHAOSONG 8Browse volume

<h2>1. 什么是REST</h2> REST全称是Representational State Transfer，中文意思是表述（编者注：通常译为表征）性状态转移。它首次出现在2000年Roy Fielding的博士论文中，Roy Fielding是HTTP规范的主要编写者之一。他在论文中提到："我这篇文章的写作目的，就是想在符合架构原理的前提下，理解和评估以网络为基础的应用软件的架构设计，得到一个功能强、性能好、适宜通信的架构。REST指的是一组架构约束条件和原则。" 如果一个架构符合REST的约束条件和原则，我们就称它为RESTful架构。 REST本身并没有创造新的技术、组件或服务，而隐藏在RESTful背后的理念就是使用Web的现有特征和能力，更好地使用现有Web标准中的一些准则和约束。虽然REST本身受Web技术的影响很深，但是理论上REST架构风格并不是绑定在HTTP上，只不过目前HTTP是唯一与REST相关的实例。所以我们这里描述的REST也是通过HTTP实现的REST。 <h2>2. 理解RESTful</h2> 要理解RESTful架构，需要理解Representational State Transfer这个词组到底是什么意思，它的每一个词都有些什么涵义。 下面我们结合REST原则，围绕资源展开讨论，从资源的定义、获取、表述、关联、状态变迁等角度，列举一些关键概念并加以解释。 <ul> <li>资源与URI</li> <li>统一资源接口</li> <li>资源的表述</li> <li>资源的链接</li> <li>状态的转移</li> </ul> <h2>2. 1 资源与URI</h2> REST全称是表述性状态转移，那究竟指的是什么的表述? 其实指的就是资源。任何事物，只要有被引用到的必要，它就是一个资源。资源可以是实体(例如手机号码)，也可以只是一个抽象概念(例如价值) 。下面是一些资源的例子： <ul> <li>某用户的手机号码</li> <li>某用户的个人信息</li> <li>最多用户订购的GPRS套餐</li> <li>两个产品之间的依赖关系</li> <li>某用户可以办理的优惠套餐</li> <li>某手机号码的潜在价值</li> </ul> 要让一个资源可以被识别，需要有个唯一标识，在Web中这个唯一标识就是URI(Uniform Resource Identifier)。 URI既可以看成是资源的地址，也可以看成是资源的名称。如果某些信息没有使用URI来表示，那它就不能算是一个资源，只能算是资源的一些信息而已。URI的设计应该遵循可寻址性原则，具有自描述性，需要在形式上给人以直觉上的关联。这里以github网站为例，给出一些还算不错的URI： <ul> <li><a href='https://github.com/git' target='_blank' class='url'>https://github.com/git</a></li> <li><a href='https://github.com/git/git' target='_blank' class='url'>https://github.com/git/git</a></li> <li><a href='https://github.com/git/git/blob/master/block-sha1/sha1.h' target='_blank' class='url'>https://github.com/git/git/blob/master/block-sha1/sha1.h</a></li> <li><a href='https://github.com/git/git/commit/e3af72cdafab5993d18fae056f87e1d675913d08' target='_blank' class='url'>https://github.com/git/git/commit/e3af72cdafab5993d18fae056f87e1d675913d08</a></li> <li><a href='https://github.com/git/git/pulls' target='_blank' class='url'>https://github.com/git/git/pulls</a></li> <li><a href='https://github.com/git/git/pulls?state=closed' target='_blank' class='url'>https://github.com/git/git/pulls?state=closed</a></li> <li><a href='https://github.com/git/git/compare/master' target='_blank' class='url'>https://github.com/git/git/compare/master</a>…next</li> </ul> 下面让我们来看看URI设计上的一些技巧: <ul> <li>使用_或-来让URI可读性更好</li> </ul> 曾经Web上的URI都是冰冷的数字或者无意义的字符串，但现在越来越多的网站使用_或-来分隔一些单词，让URI看上去更为人性化。例如国内比较出名的开源中国社区，它上面的新闻地址就采用这种风格，如<a href='http://www.oschina.net/news/38119/oschina-translate-reward-plan' target='_blank' class='url'>http://www.oschina.net/news/38119/oschina-translate-reward-plan</a>。 <ul> <li>使用/来表示资源的层级关系</li> </ul> 例如上述/git/git/commit/e3af72cdafab5993d18fae056f87e1d675913d08就表示了一个多级的资源，指的是git用户的git项目的某次提交记录，又例如/orders/2012/10可以用来表示2012年10月的订单记录。 <ul> <li>使用?用来过滤资源</li> </ul> 很多人只是把?简单的当做是参数的传递，很容易造成URI过于复杂、难以理解。可以把?用于对资源的过滤，例如/git/git/pulls用来表示git项目的所有推入请求，而/pulls?state=closed用来表示git项目中已经关闭的推入请求，这种URL通常对应的是一些特定条件的查询结果或算法运算结果。 <ul> <li>,或;可以用来表示同级资源的关系</li> </ul> 有时候我们需要表示同级资源的关系时，可以使用,或;来进行分割。例如哪天github可以比较某个文件在随意两次提交记录之间的差异，或许可以使用/git/git /block-sha1/sha1.h/compare/e3af72cdafab5993d18fae056f87e1d675913d08;bd63e61bdf38e872d5215c07b264dcc16e4febca作为URI。不过，现在github是使用…来做这个事情的，例如/git/git/compare/master…next。 <h2>2. 2 统一资源接口</h2> RESTful架构应该遵循统一接口原则，统一接口包含了一组受限的预定义的操作，不论什么样的资源，都是通过使用相同的接口进行资源的访问。接口应该使用标准的HTTP方法如GET，PUT和POST，并遵循这些方法的语义。 如果按照HTTP方法的语义来暴露资源，那么接口将会拥有安全性和幂等性的特性，例如GET和HEAD请求都是安全的，无论请求多少次，都不会改变服务器状态。而GET、HEAD、PUT和DELETE请求都是幂等的，无论对资源操作多少次，结果总是一样的，后面的请求并不会产生比第一次更多的影响。 下面列出了GET，DELETE，PUT和POST的典型用法: <h2>GET</h2> <ul> <li>安全且幂等</li> <li>获取表示</li> <li>变更时获取表示（缓存）</li> <li>200（OK） - 表示已在响应中发出</li> <li>204（无内容） - 资源有空表示</li> <li>301（Moved Permanently） - 资源的URI已被更新</li> <li>303（See Other） - 其他（如，负载均衡）</li> <li>304（not modified）- 资源未更改（缓存）</li> <li>400 （bad request）- 指代坏请求（如，参数错误）</li> <li>404 （not found）- 资源不存在</li> <li>406 （not acceptable）- 服务端不支持所需表示</li> <li>500 （internal server error）- 通用错误响应</li> <li>503 （Service Unavailable）- 服务端当前无法处理请求</li> </ul> <h2>POST</h2> <ul> <li>不安全且不幂等</li> <li>使用服务端管理的（自动产生）的实例号创建资源</li> <li>创建子资源</li> <li>部分更新资源</li> <li>如果没有被修改，则不过更新资源（乐观锁）</li> <li>200（OK）- 如果现有资源已被更改</li> <li>201（created）- 如果新资源被创建</li> <li>202（accepted）- 已接受处理请求但尚未完成（异步处理）</li> <li>301（Moved Permanently）- 资源的URI被更新</li> <li>303（See Other）- 其他（如，负载均衡）</li> <li>400（bad request）- 指代坏请求</li> <li>404 （not found）- 资源不存在</li> <li>406 （not acceptable）- 服务端不支持所需表示</li> <li>409 （conflict）- 通用冲突</li> <li>412 （Precondition Failed）- 前置条件失败（如执行条件更新时的冲突）</li> <li>415 （unsupported media type）- 接受到的表示不受支持</li> <li>500 （internal server error）- 通用错误响应</li> <li>503 （Service Unavailable）- 服务当前无法处理请求</li> </ul> <h2>PUT</h2> <ul> <li>不安全但幂等</li> <li>用客户端管理的实例号创建一个资源</li> <li>通过替换的方式更新资源</li> <li>如果未被修改，则更新资源（乐观锁）</li> <li>200 （OK）- 如果已存在资源被更改</li> <li>201 （created）- 如果新资源被创建</li> <li>301（Moved Permanently）- 资源的URI已更改</li> <li>303 （See Other）- 其他（如，负载均衡）</li> <li>400 （bad request）- 指代坏请求</li> <li>404 （not found）- 资源不存在</li> <li>406 （not acceptable）- 服务端不支持所需表示</li> <li>409 （conflict）- 通用冲突</li> <li>412 （Precondition Failed）- 前置条件失败（如执行条件更新时的冲突）</li> <li>415 （unsupported media type）- 接受到的表示不受支持</li> <li>500 （internal server error）- 通用错误响应</li> <li>503 （Service Unavailable）- 服务当前无法处理请求</li> </ul> <h2>DELETE</h2> <ul> <li>不安全但幂等</li> <li>删除资源</li> <li>200 （OK）- 资源已被删除</li> <li>301 （Moved Permanently）- 资源的URI已更改</li> <li>303 （See Other）- 其他，如负载均衡</li> <li>400 （bad request）- 指代坏请求</li> <li>404 （not found）- 资源不存在</li> <li>409 （conflict）- 通用冲突</li> <li>500 （internal server error）- 通用错误响应</li> <li>503 （Service Unavailable）- 服务端当前无法处理请求</li> </ul> 下面我们来看一些实践中常见的问题: <ul> <li>POST和PUT用于创建资源时有什么区别?</li> </ul> POST和PUT在创建资源的区别在于，所创建的资源的名称(URI)是否由客户端决定。例如为我的博文增加一个java的分类，生成的路径就是分类名/categories/java，那么就可以采用PUT方法。不过很多人直接把POST、GET、PUT、DELETE直接对应上CRUD，例如在一个典型的rails实现的RESTful应用中就是这么做的。 我认为，这是因为rails默认使用服务端生成的ID作为URI的缘故，而不少人就是通过rails实践REST的，所以很容易造成这种误解。 <ul> <li>客户端不一定都支持这些HTTP方法吧?</li> </ul> 的确有这种情况，特别是一些比较古老的基于浏览器的客户端，只能支持GET和POST两种方法。 在实践上，客户端和服务端都可能需要做一些妥协。例如rails框架就支持通过隐藏参数method=DELETE来传递真实的请求方法，而像Backbone这样的客户端MVC框架则允许传递method传输和设置X-HTTP-Method-Override头来规避这个问题。 <ul> <li>统一接口是否意味着不能扩展带特殊语义的方法?</li> </ul> 统一接口并不阻止你扩展方法，只要方法对资源的操作有着具体的、可识别的语义即可，并能够保持整个接口的统一性。 像WebDAV就对HTTP方法进行了扩展，增加了LOCK、UPLOCK等方法。而github的API则支持使用PATCH方法来进行issue的更新，例如: <pre><code>PATCH /repos/:owner/:repo/issues/:number </code></pre> 不过，需要注意的是，像PATCH这种不是HTTP标准方法的，服务端需要考虑客户端是否能够支持的问题。 <ul> <li>统一资源接口对URI有什么指导意义?</li> </ul> 统一资源接口要求使用标准的HTTP方法对资源进行操作，所以URI只应该来表示资源的名称，而不应该包括资源的操作。 通俗来说，URI不应该使用动作来描述。例如，下面是一些不符合统一接口要求的URI: <ul> <li>GET /getUser/1</li> <li>POST /createUser</li> <li>PUT /updateUser/1</li> <li>DELETE /deleteUser/1</li> </ul> 如果GET请求增加计数器，这是否违反安全性? 安全性不代表请求不产生副作用，例如像很多API开发平台，都对请求流量做限制。像github，就会限制没有认证的请求每小时只能请求60次。 但客户端不是为了追求副作用而发出这些GET或HEAD请求的，产生副作用是服务端"自作主张"的。 另外，服务端在设计时，也不应该让副作用太大，因为客户端认为这些请求是不会产生副作用的。 <ul> <li>直接忽视缓存可取吗?</li> </ul> 即使你按各个动词的原本意图来使用它们，你仍可以轻易禁止缓存机制。最简单的做法就是在你的HTTP响应里增加这样一个报头： Cache-control: no-cache。但是，同时你也对失去了高效的缓存与再验证的支持(使用Etag等机制)。 对于客户端来说，在为一个REST式服务实现程序客户端时，也应该充分利用现有的缓存机制，以免每次都重新获取表示。 <ul> <li>响应代码的处理有必要吗?</li> </ul> HTTP的响应代码可用于应付不同场合，正确使用这些状态代码意味着客户端与服务器可以在一个具备较丰富语义的层次上进行沟通。 例如，201（"Created"）响应代码表明已经创建了一个新的资源，其URI在Location响应报头里。 假如你不利用HTTP状态代码丰富的应用语义，那么你将错失提高重用性、增强互操作性和提升松耦合性的机会。 如果这些所谓的RESTful应用必须通过响应实体才能给出错误信息，那么SOAP就是这样的了，它就能够满足了。 <h2>2. 3 资源的表述</h2> 上面提到，客户端通过HTTP方法可以获取资源，是吧? 不，确切的说，客户端获取的只是资源的表述而已。资源在外界的具体呈现，可以有多种表述(或成为表现、表示)形式，在客户端和服务端之间传送的也是资源的表述，而不是资源本身。例如文本资源可以采用html、xml、json等格式，图片可以使用PNG或JPG展现出来。 资源的表述包括数据和描述数据的元数据，例如，HTTP头"Content-Type" 就是这样一个元数据属性。 那么客户端如何知道服务端提供哪种表述形式呢? 答案是可以通过HTTP内容协商，客户端可以通过Accept头请求一种特定格式的表述，服务端则通过Content-Type告诉客户端资源的表述形式。 以github为例，请求某组织资源的json格式的表述形式: <img src='https://www.runoob.com/wp-content/uploads/2015/07/291731048886033.jpg' alt='291731048886033' referrerPolicy='no-referrer' /> 　 　假如github也能够支持xml格式的表述格式，那么结果就是这样的: <img src='https://www.runoob.com/wp-content/uploads/2015/07/291731045756062.jpg' alt='291731045756062' referrerPolicy='no-referrer' /> 　 　下面我们来看一些实践上常见的设计: <h2>在URI里边带上版本号</h2> 有些API在URI里边带上版本号，例如: <ul> <li><a href='http://api.example.com/1.0/foo' target='_blank' class='url'>http://api.example.com/1.0/foo</a></li> <li><a href='http://api.example.com/1.2/foo' target='_blank' class='url'>http://api.example.com/1.2/foo</a></li> <li><a href='http://api.example.com/2.0/foo' target='_blank' class='url'>http://api.example.com/2.0/foo</a></li> </ul> 如果我们把版本号理解成资源的不同表述形式的话，就应该只是用一个URL，并通过Accept头部来区分，还是以github为例，它的Accept的完整格式是:application/vnd.github[.version].param[+json] 对于v3版本的话，就是Accept: application/vnd.github.v3。对于上面的例子，同理可以使用使用下面的头部: <ul> <li>Accept: vnd.example-com.foo+json; version=1.0</li> <li>Accept: vnd.example-com.foo+json; version=1.2</li> <li>Accept: vnd.example-com.foo+json; version=2.0</li> </ul> <h2>使用URI后缀来区分表述格式</h2> 像rails框架，就支持使用/users.xml或/users.json来区分不同的格式。这样的方式对于客户端来说，无疑是更为直观，但混淆了资源的名称和资源的表述形式。我个人认为，还是应该优先使用内容协商来区分表述格式。 <h2>如何处理不支持的表述格式</h2> 当服务器不支持所请求的表述格式，那么应该怎么办？若服务器不支持，它应该返回一个HTTP 406响应，表示拒绝处理该请求。下面以github为例，展示了一个请求XML表述资源的结果： <img src='https://www.runoob.com/wp-content/uploads/2015/07/291732082474844.jpg' alt='291732082474844' referrerPolicy='no-referrer' /> 　　 <h2>2. 4 资源的链接</h2> 我们知道REST是使用标准的HTTP方法来操作资源的，但仅仅因此就理解成带CURD的Web数据库架构就太过于简单了。 这种反模式忽略了一个核心概念："超媒体即应用状态引擎（hypermedia as the engine of application state）"。超媒体是什么? 当你浏览Web网页时，从一个连接跳到一个页面，再从另一个连接跳到另外一个页面，就是利用了超媒体的概念：把一个个把资源链接起来. 要达到这个目的，就要求在表述格式里边加入链接来引导客户端。在《RESTful Web Services》一书中，作者把这种具有链接的特性成为连通性。下面我们具体来看一些例子。 下面展示的是github获取某个组织下的项目列表的请求，可以看到在响应头里边增加Link头告诉客户端怎么访问下一页和最后一页的记录。而在响应体里边，用url来链接项目所有者和项目地址。 <img src='https://www.runoob.com/wp-content/uploads/2015/07/291731042784620.jpg' alt='291731042784620' referrerPolicy='no-referrer' /> 　　又例如下面这个例子，创建订单后通过链接引导客户端如何去付款。 <a href='https://www.runoob.com/wp-content/uploads/2015/07/291731052313462.jpg'><img src='https://www.runoob.com/wp-content/uploads/2015/07/291731052313462.jpg' alt='291731052313462' referrerPolicy='no-referrer' /></a> 上面的例子展示了如何使用超媒体来增强资源的连通性。很多人在设计RESTful架构时，使用很多时间来寻找漂亮的URI，而忽略了超媒体。所以，应该多花一些时间来给资源的表述提供链接，而不是专注于"资源的CRUD"。 <h2>2. 5 状态的转移</h2> 有了上面的铺垫，再讨论REST里边的状态转移就会很容易理解了。 不过，我们先来讨论一下REST原则中的无状态通信原则。初看一下，好像自相矛盾了，既然无状态，何来状态转移一说? 其实，这里说的无状态通信原则，并不是说客户端应用不能有状态，而是指服务端不应该保存客户端状态。 <h2>2. 5.1 应用状态与资源状态</h2> 实际上，状态应该区分应用状态和资源状态，客户端负责维护应用状态，而服务端维护资源状态。 客户端与服务端的交互必须是无状态的，并在每一次请求中包含处理该请求所需的一切信息。 服务端不需要在请求间保留应用状态，只有在接受到实际请求的时候，服务端才会关注应用状态。 这种无状态通信原则，使得服务端和中介能够理解独立的请求和响应。 在多次请求中，同一客户端也不再需要依赖于同一服务器，方便实现高可扩展和高可用性的服务端。 但有时候我们会做出违反无状态通信原则的设计，例如利用Cookie跟踪某个服务端会话状态，常见的像J2EE里边的JSESSIONID。 这意味着，浏览器随各次请求发出去的Cookie是被用于构建会话状态的。 当然，如果Cookie保存的是一些服务器不依赖于会话状态即可验证的信息（比如认证令牌），这样的Cookie也是符合REST原则的。 <h2>2. 5.2 应用状态的转移</h2> 状态转移到这里已经很好理解了， "会话"状态不是作为资源状态保存在服务端的，而是被客户端作为应用状态进行跟踪的。客户端应用状态在服务端提供的超媒体的指引下发生变迁。服务端通过超媒体告诉客户端当前状态有哪些后续状态可以进入。 这些类似"下一页"之类的链接起的就是这种推进状态的作用——指引你如何从当前状态进入下一个可能的状态。 <h2>3. 总结</h2> 现在广东XXX版本、XXX等项目中均使用传统的RPC、SOAP方式的Web服务，而移动南方基地XXXX项目的后台，虽然采用了JSON格式进行交互，但还是属于RPC风格的。本文从资源的定义、获取、表述、关联、状态变迁等角度，试图快速理解RESTful架构背后的概念。RESTful架构与传统的RPC、SOAP等方式在理念上有很大的不同，希望本文能对各位理解REST有所帮助。

Continue reading →

递归算法实现快速排序

Java 数据结构四月 12, 2019, 6:18 a.m. SHAOSONG 19Browse volume

吃亏还不长记性没办法活该吃亏，就在上次笔试中遇到了让写排序算法可以根据isDesc来判断是否从小到大或者从大到小在这个过程中让我吃了大亏，按道理说这块随便写个算法就可以了但是面试官不是这样理解的，面试官要求应该是一个比较有灵魂的排序算法，比如那些比较经典的快速排序，并不是我所写的冒泡排序让我惨遭被刷。随后本人便回家开始学习一种可以拿的出手的排序算法，快速排序。 例如下面这个数组：{2,4,5,9,7,6,3,1,8}首先需要从第一个数字开始遍历，第一个数字为2，以2为支撑数X，开始从右向左遍历数组遇到比2小的变换位置即可，i是从左往右的遍历节点，j是从右往左的遍历节点，第一轮遍历如下： 支撑节点X=2： 1） 1,4,5,9,7,6,3, 2 ,8 i=0,j=7; 2） 1, 2 ,5,9,7,6,3,4,8 i=1,j=7; 这个时候你就会发现2的左边都是比它小的数，右边都是比它大的数，这时候以2为中心左边开始从新按照上面的方法来执行一次，发现2左边只有1所以不管左边，现在观察2的右边都是比他大的而且数大于一个，这时候以i+1为开始的位置，j=8依然是最后一个数字。 支撑节点X=5： 1）1, 2 ,4,9,7,6,3, 5 ,8 i=2,j=7; 2）1, 2 ,4, 5 ,7,6,3,9,8 i=3,j=7; 3）1, 2 ,4,3,7,6, 5 ,9,8 i=3,j=6; 4）1, 2 ,4,3, 5 ,6,7,9,8 i=4,j=6; 这时候第二轮已经结束； 第三轮以5为中心，左边从i=2开始到j=3结束，右边从i=5开始j=8结束一直重复以上步骤即可完成排序。 Java代码如下所示： <pre> <code class='language-Java' lang='Java'> public class QuickSoft { public void soft(Boolean isDesc, int a[], int start, int end){ if (start < end ){ int s = a[start]; int i = start; int j = end; while( i < j ){ while (i < j && (isDesc ? a[j]>=s : a[j]<=s)) //{2,4,5,9,7,6,3,1,8} j--; if (i < j && i != j) a[i++] = a[j]; while(i < j && (isDesc ? a[i] < s : a[i] > s)) i++; if (i < j && i != j) a[j--] = a[i]; } a[i] = s; soft(isDesc, a, start, i-1); soft(isDesc, a, i+1, end); } } public static void main(String[] args) { QuickSoft q = new QuickSoft(); int b[] ={2,4,5,9,7,6,3,1,8}; Boolean isDesc = false; q.soft(isDesc, b, 0, b.length-1); for (int i=0; i < b.length; i++) System.out.print(a[i]); } } </code></pre>

Continue reading →

笔试失败的动力来源于什么！

Java 数据结构四月 11, 2019, 8:16 a.m. SHAOSONG 10Browse volume

每天我都在复习Java基础今天笔试一道天天见的题，我没做对，心理的惭愧不说，天天看的东西我居然没有写出来这事就equals方法的底层实现，我现在就equals方法进行一个简单的实现。 首先equals方法是做什么的，在我的理解，它是被用来对对象进行比较，判断是否两个对象的内容是否相等，并且返回Boolean值。 首先分析代码是如何实现的： <ol start='' > <li>先对两个对象进行’==‘比较如果相同直接返回true，不同则继续使用以下方法进行比较；</li> <li>对两个对象进行instanceof 看是否属于String，如果属于在比较其长度是否相同；</li> <li>如果长度相同，在比较其每个位置对应的字符是不是相同，如果相同则返回true，否则这两个对象不同。</li> </ol> 下面代码是我自己改写的equals方法，仅供参考： <pre><code class='language-java' lang='java'>public boolean equals(Object ojb1, Object ojb2){ if (ojb1 == ojb2){ return true; } if(ojb1 instanceof String && ojb2 instanceof String){ String str1 = (String) ojb1; String str2 = (String) ojb2; int m = str1.length(); int n = str2.length(); if (m == n){ char v1[] = str1.toCharArray(); char v2[] = str2.toCharArray(); int i = 0; while( n-- != 0 ){ if (v1[i] != v2[i]) return false; i++; } return true; } } return false; } </code></pre>

Continue reading →

Python+Django+小程序API的编写

Python 微信小程序十二月 27, 2018, 3:13 a.m. SHAOSONG 70Browse volume

在学习这个之前，首先要求是你们会Django框架的基础之上，如果不会可以<a href='https://blog.songshao.site/single/10007/'>点击这里</a>学习有关Django框架的一些使用方案，在下面我将会讲出有关api的简单编写和json数据处理过程。 api结构主要包括请求链接，入参，Django的业务逻辑处理，返回参数。一般情况下尽量使用POST请求，数据比较安全。 <ol> <li>Django的业务逻辑 <ol> <li>urls的编写 两种方法的原因是1.7以前不支持path来编写 <pre><code class='language-python' lang='python'>Django2.0.4可以使用以下方法 from django.urls import path urlpatterns = [ path('depot/', get_depot), path('depot_list/', get_depot_list) ] Django1.7.0可以使用以下方法 from django.conf.urls import url urlpatterns = [ url(r'depot/$', get_depot), url(r'depot_list/$', get_depot_list) ] </code></pre> </li> <li>models创建 就举个简单的栗子吧，这样更加明确直白，这三个表个栗子，可以解决以后的多表联合查询问题。 <pre><code class='language-python' lang='python'># 停车场表 class TB_DEPOT(models.Model): DE_ID = models.CharField(max_length=18, verbose_name="停车场编码", primary_key=True) NAME = models.CharField(max_length=11, verbose_name="停车场名称") ADDRESS = models.CharField(max_length=64, verbose_name="停车场地址") LATITUDE = models.CharField(max_length=18, verbose_name="坐标(纬度)") LONGITUDE = models.CharField(max_length=18, verbose_name="坐标(经度)") COST_1 = models.CharField(max_length=6, verbose_name="停车费用_1") COST_2 = models.CharField(max_length=6, verbose_name="停车费用_2",null=True) MAN_COST = models.CharField(max_length=6, verbose_name="日最高消费",null=True) FREE_TIME = models.CharField(max_length=6, verbose_name="免费时长",null=True) MODE_PAY = models.CharField(max_length=11, verbose_name="支付方式") START_DATE = models.TimeField(verbose_name="营业开始时间") END_DATE = models.TimeField(verbose_name="营业结束时间") STATE = models.IntegerField(verbose_name="停车场状态") IMAGE_1 = models.ImageField(verbose_name="图片一", upload_to=image_upload_to) IMAGE_2 = models.ImageField(verbose_name="图片二", null=True, upload_to=image_upload_to) IMAGE_3 = models.ImageField(verbose_name="图片三", null=True, upload_to=image_upload_to) IMAGE_4 = models.ImageField(verbose_name="图片四", null=True, upload_to=image_upload_to) BUSI_ID = models.ForeignKey(TB_BUSINESSMAN, verbose_name="商户编码", on_delete=models.CASCADE) def __str__(self): return self.DE_ID class Meta: db_table = "TB_DEPOT" verbose_name = '停车场' verbose_name_plural = verbose_name # 预约表（TB_APPOINTMENT） class TB_APPOINTMENT(models.Model): APPO_ID = models.CharField(max_length=18, verbose_name="预约编码", primary_key=True) USER_ID = models.CharField(max_length=18, verbose_name="预约人编码") DATE = models.DateField(verbose_name='预约时间') PL_NUM = models.CharField(max_length=10, verbose_name='预约车牌', default='') APPO_TIME = models.CharField(max_length=4, verbose_name="预约时长") COST = models.CharField(max_length=4, verbose_name="预约费用") STATE = models.IntegerField(verbose_name="预约付款状态") APPO_STATE = models.IntegerField(verbose_name='预约过期状态', default='1') OUTPUT = models.IntegerField(verbose_name='是否入场', default='0') DEPOT = models.ForeignKey(TB_DEPOT, verbose_name="停车场编码", on_delete=models.CASCADE) def __str__(self): return self.APPO_ID class Meta: db_table = "TB_APPOINTMENT" verbose_name = '预约' verbose_name_plural = verbose_name # 用户表（TB_USER） class TB_USER(models.Model): OPEN_ID = models.CharField(max_length=64, verbose_name='微信唯一标识') USER_ID = models.CharField(max_length=32, verbose_name='用户编码') PHONE = models.CharField(max_length=11, verbose_name='用户手机号', null=True, default='') USER_NAME = models.CharField(max_length=32, verbose_name='用户微信名称') USER_STATE = models.IntegerField(verbose_name='用户状态') def __str__(self): return self.OPEN_ID class Meta: db_table = "TB_USER" verbose_name = '用户' verbose_name_plural = verbose_name </code></pre> </li> <li>api方法的编写 先看一个简单的查询业务案例，停车场表信息查询 <pre><code class='language-python' lang='python'>from django.http import JsonResponse from django.views.decorators.csrf import csrf_exempt #请求参数设置 #http://localhost:8000/Api/depot/ # 入参无 # 返回json数据 def get_depot(request): if request.method == 'GET': try: data = {} depot = TB_DEPOT.objects.values() data['depot'] = list(depot) print(data['depot']) return JsonResponse({'success': True, 'data': data['depot']}) except Exception as e: return JsonResponse({'success': False, 'data': str(e)}) </code></pre> 主要问题就是如何把把QuerySet,数据转化成json数据，也就是Python中的字典，根据<code>depot = TB_DEPOT.objects.values()</code>获取到数据对象，然后使用下面这种简单的方法来把数据转化成json数据，<code>data['depot'] = list(depot)</code>，这种方法给大家解释一下他就是把获取到的数据对象转化成list对象，然后反身存储到data['depot']中，完成一个简单的转化。 下面这个栗子稍微有点复杂通过请求链接传参，进行获取数据，进行数据查询，拼接，返回json对象。 <pre><code class='language-python' lang='python'># 用户预约信息查询根据用户唯一标识openid进行查询 # 请求示例 # 请求示例：http://localhost:8000/Api/get_appo_over/?openId=****** # 入参设置，需要进行openid标识传入 # 可选参数：STATE、PPO_STATE、OUTPUT # 返回用户预约的记录 def get_appo_over(request): data = {} if request.method == 'GET': openid = request.GET.get('openId') state = request.GET.get('state') output = request.GET.get('output') appo_state = request.GET.get('appo_state') try: userid = TB_USER.objects.get(OPEN_ID=openid).USER_ID print(userid) appo = {} if state: appo = TB_APPOINTMENT.objects.filter(Q(USER_ID=userid) & Q(STATE=state)) elif appo_state: appo = TB_APPOINTMENT.objects.filter(Q(USER_ID=userid) & Q(APPO_STATE=appo_state)) elif output: appo = TB_APPOINTMENT.objects.filter(Q(USER_ID=userid) & Q(OUTPUT=output)) else: appo = TB_APPOINTMENT.objects.filter(Q(USER_ID=userid)) data['appo'] = list(appo.values()) i = 0 for a in appo: print(a.DEPOT.DE_ID) depot = TB_DEPOT.objects.filter(DE_ID=a.DEPOT.DE_ID).values() data['depot'] = list(depot) print(data['depot']) data['appo'][i].update(data['depot'][0]) i = i + 1 return JsonResponse({'success': True, 'data': data['appo']}) except Exception as e: return JsonResponse({'success': False, 'data': 0}) </code></pre> 这个接口，主要是进行预约和相对应的停车场进行查询简单解释一下一些语句的用途 <code>openid = request.GET.get('openId')</code> 使用该代码来获取请求链接中的参数； <pre><code class='language-python' lang='python'> i = 0 for a in appo: print(a.DEPOT.DE_ID) depot = TB_DEPOT.objects.filter(DE_ID=a.DEPOT.DE_ID).values() data['depot'] = list(depot) print(data['depot']) data['appo'][i].update(data['depot'][0]) i = i + 1 </code></pre> 这块代码主要是对预约记录进行解析出来，根据对应的a.DEPOT.DE_ID标识去进行停车场查询，将得到的数据转化，然后拼接到appo数据中，因为data['depot']和data['appo']都属于是dict类型的对象，可以使用update直接把数据更新到另一个里面注意的是如果直接更新，相同索引的值都会被替换掉，所以使用之前先对数据进行处理。 </li> <li>小程序端的请求方法 <pre><code class='language-javascript' lang='javascript'>var that = this wx.request({ url: 'http://127.0.0.1:8000/Api/get_appo_over/?openId=' + app.gloabData.openid + '&state=0', method: 'GET', // url: 'https://api.songshao.site/Api/get_appo_over/?openId=' + app.gloabData.openid + '&state=0', method: 'GET', header: { 'content-type': 'application/json,charset=utf-8' }, success: function (res) { console.log(res.data.data) if (res.data.data.length == 0) { that.setData({ num: 0 }) } else { that.setData({ num: 1, appo: res.data.data, }) } }, fail: function (res) { wx.showToast({ title: '服务器开了小差，下拉刷新一下', icon: 'waring', duration: 3000 }) } }) </code></pre>   小程序使用wx.request来请求api,在url中编写链接地址和对应的参数，请求method一般尽量使用post，请求头设置 header: { 'content-type': 'application/json,charset=utf-8' }，成功之后返回数据处理请求成功数据如下： <pre><code class='language-json' lang='json'>{"success": true, "data": [{"APPO_ID": "684407", "USER_ID": "8208225", "DATE": "2018-12-25", "PL_NUM": "\u9655A88888", "APPO_TIME": "10", "COST": "0.5", "STATE": 1, "APPO_STATE": 1, "OUTPUT": 0, "DEPOT_id": "20181215002", "DE_ID": "20181215002", "NAME": "\u5c1a\u54c1\u7f8e\u5730\u57ce\u4e8c\u671f", "ADDRESS": "\u9655\u897f\u7701\u897f\u5b89\u5e02\u96c1\u5854\u533a\u9526\u4e1a\u8def92\u53f7", "LATITUDE": "34.34627", "LONGITUDE": "108.93984", "COST_1": "5", "COST_2": "6", "MAN_COST": "50", "FREE_TIME": "0.5", "MODE_PAY": "\u7535\u5b50\u652f\u4ed8", "START_DATE": "00:00:00", "END_DATE": "23:59:00", "IMAGE_1": "index/static/upload_image/47735b874b494483b1ab1149b1b6d84d/\u5c1a\u54c1.jpg", "IMAGE_2": "index/static/upload_image/d03235beb44548de9cab02041ba2d511/\u5c1a\u54c1.jpg", "IMAGE_3": "index/static/upload_image/14545c2c9f4a4e2ebf392a3fe04bc1af/\u5c1a\u54c1.jpg", "IMAGE_4": "index/static/upload_image/4bb82db280584fa6a6e4f91fde65f7e5/\u5c1a\u54c1.jpg", "BUSI_ID_id": "20181215001"}, {"APPO_ID": "9276129", "USER_ID": "8208225", "DATE": "2018-12-25", "PL_NUM": "\u9655E88888", "APPO_TIME": "10", "COST": "0.5", "STATE": 1, "APPO_STATE": 0, "OUTPUT": 0, "DEPOT_id": "20181215002", "DE_ID": "20181215002", "NAME": "\u5c1a\u54c1\u7f8e\u5730\u57ce\u4e8c\u671f", "ADDRESS": "\u9655\u897f\u7701\u897f\u5b89\u5e02\u96c1\u5854\u533a\u9526\u4e1a\u8def92\u53f7", "LATITUDE": "34.34627", "LONGITUDE": "108.93984", "COST_1": "5", "COST_2": "6", "MAN_COST": "50", "FREE_TIME": "0.5", "MODE_PAY": "\u7535\u5b50\u652f\u4ed8", "START_DATE": "00:00:00", "END_DATE": "23:59:00", "IMAGE_1": "index/static/upload_image/47735b874b494483b1ab1149b1b6d84d/\u5c1a\u54c1.jpg", "IMAGE_2": "index/static/upload_image/d03235beb44548de9cab02041ba2d511/\u5c1a\u54c1.jpg", "IMAGE_3": "index/static/upload_image/14545c2c9f4a4e2ebf392a3fe04bc1af/\u5c1a\u54c1.jpg", "IMAGE_4": "index/static/upload_image/4bb82db280584fa6a6e4f91fde65f7e5/\u5c1a\u54c1.jpg", "BUSI_ID_id": "20181215001"}]} </code></pre> 首先需要说明小程序请求之后会把json数据默认存放方到data里面，这块本省还有一个data，所以定位时就需要用res.data.data定位数据，像这个json数据有两条，在页面显示时可以用for循环输出数据 <pre><code class='language-html' lang='html'><view class='content_view' wx:for='{{appo}}' wx:key> <view class='header'> <text class='l_text'>{{item.DATE}}</text> <text class='r_text'>未进场</text> </view> <view class='header_content'> <view class='header_text'> <text>{{item.NAME}}停车场</text> </view> <view class='text_view'> <image class='image_style' src='../../resource/image/ding_wei_1.png'/> <text class='text_view_text'>{{item.ADDRESS}}</text> </view> <view class='text_view'> <image class='image_style' src='../../resource/image/car.png'/> <text class='text_view_text'>预约车牌为：{{item.PL_NUM}}</text> </view> <view class='text_view'> <image class='image_style' src='../../resource/image/time.png'/> <text class='text_view_text'>剩余时长：{{item.APPO_TIME}}</text> </view> <button class='btn'>续费</button> </view> </view> </code></pre> 在循环中可以通过定义的数据对象appo，去循环，因为循环使用的是它的array(),因为json对象有两条所以循环两次，输出，每次遍历数组对象是可以使用item.属性名，来获取相应的数据，显示结果如下图所示 <img src='/static/upload/xiaochengx_list1.png' alt='xiaochengx_list1' referrerPolicy='no-referrer' /> 如果出现这种结果就说明你的小程序成功了！ </li> </ol> </li> </ol>

Continue reading →