2020/03/11 03-pub和get接口实现

在开发中做前后端分离应该把接口分开，不做分开，就是需要有模板，别人打开模板所对应的页面后，能在浏览器看到相应的内容。
前后端分离，我们之间传的只是数据，所以后端写的程序，只需要靠postman这样的一些测试端，发起对接口的请求，看到数据即可，这些接口基本上是增删改查，只不过查有些不同（查有些不同，有详情页和列表页）
用restful风格来设计的话，应该对应不同的方法，常用的有post，delete，get，django在我们选择url映射的时候，不能够让我们选择方法，所以django不太方便。
所以我们设计的时候，对于增不要/了，把它映射到pub函数上，一般都会写一个表，总之都要有个证据来怎么知道如何对接在一起，得有接口让前端来调用，最后前后端对应在一起

接口设计好后，这是属于哪一块功能的，属于博客系统的，就需要创建应用startapp 应用名称，这样应用的脚手架文件就全部准备好了，可以在这个脚手架文件上进行进一步的开发，第一个要做的还是model或者先写url配置也可以
第二张表就会有一个外键

但是这个外键创建的是另外的字段

引用的是post表中的id字段，创建的就是post。id

这就是关于一对一如何设计，一对多如何设计

**这个类的实例可以试试访问属性，到时候试一下 **


路由依然采取两级路由，先到post再去对应不同函数，对于函数，无非就是请求进去，response出来

我们做的pub就是提交数据，一篇文章就是提交名字和内容，按现在的字段还能提供作者，还可以提交时间，时间不可以由客户端提交，发文章需要作者直接登录，登录通过验证，就会有一个token，把token带上，没有token，说明现在没有登陆成功过，cookie（带了两个信息，userid，和登录成功后的过期时间，用这两个信息可以进行验证）认证函数里认证没过期，说明登录是有效的，但是userid能不能用，还需要去数据库查，此人如果是激活状态就可以用，这时候才能允许你post的信息保存下来

按照现在的，只接收标题和内容，用户既然在登录过，就要求从浏览器发过来的数据，把塞到set-cookie里去Jwt的信息，将Jwt的信息发给我们，我们这些就可以解析其中的信息，还要做一些验证

这一次不用中间件的原因是，我们用中间件就相当于所有的Jwt都拦截一下，但是有些地方不需要，只是有些用户认证的地方需要，看博客不要，写博客需要，所以是需要判断哪些函数需要认证，哪些不需要

也就是把所有的url作为一个列表判断，是否需要验证，否则就直接往后调用，要做判断，就是需要判断现在访问的是否需要权限认证的view函数

这里不是我们每个都要做认证的，比较适合装饰器，谁要认证给谁加，就不太适合中间件，想一下，这几个view谁需要认证，两个get现在都不要，只要一个pub

如果觉得写在这里不合适可以直接单独写一个模块

对方是通过post提交数据，数据放在body中

还是需要try，最后该return什么就return什么

准备现在使用post，有了post后，id自增可以不管，title（可能超长，塞到数据库还是抛出异常，那就还是抛出请求的问题），postdate可以自己写日期，不相信客户端的，需要加时区，timezone

写一下时区

这就是所谓的一个人，要跟一个人的实例对应上，id不用管，内部处理，实例对应实例，这是要一个作者实例，就把实例给它，如果要id就给id

这张表要这三个

写完以后，可以做post.save，接下去写content，实例对实例，缺什么自己拿

最后也需要save

首先这些都叫insert，insert会插入一个主键，title检验一下，时间用的是服务器时间，需要加入时区，作者是一个外键，在访问的时候有可能用author_id这样的字段来访问，这是由djang动态生成，但是其实字段名真的这样。但是我们在创建的时候写author，就写request.user,这是一个user的实例可以跟作者直接对应起来，如果以后定义的时候auther_id，就需要给request.user_id。
最后直接save

save之后post里就有id了，这时候content的post就直接给post即可，这时候postid就直接给它了，出了任何错就显示提交的数据不对

如果正确了可以返回一些信息，有了id代表提交确实成功了

启动 server

先登录下，token就有了

新的jwt加进来

提交下

生成了一堆语句

主键到时候回滚了，因为2用过了，可能下次就直接3了，自增不保证连续

这样数据就写成了，关于发布这一块，发布就需要认证一下，认证还是较为严格的，把它的一些信息发现没篡改，然后还没过期，用它的用户id到数据库里查一遍，看有没有效，有效才认为能够登录，登陆之后才会把request信息注入，验证是很有必要的

大多数ORM都这么写，尤其是这种写一个实例给它，这个实例里包含想要的所有字段，只要一个id，这时候后面的实例就有，直接给id即可

这也是要个id，后面包含了很多信息，你要的id也在其中，这个由orm对象自己提取不用管

pub写法注意里面提取数据，还要注意时区的问题

两种方式来写都可以

get接口不要认证，get就是拿一篇文章

文章从post里面去拿，看1对应的文章在不在

这个url就要进行匹配，第一级匹配之后 剩后面的文章编号1

1再到post里去匹配，是不是它，如果是就过来

拿到之后该如何使用，get拿的是查询字符串（？xx=xxx&xx=xx），在path里，request有get，pat，restful风格里几乎不用查询字符串，我们基本能不写就不写，如何提交数据，往往用post在body里提交。

这时候的好办法，只能在urls上做文章，括号是代表后面所有的

现在通过这样的方式来测试

测试get能否get到一些信息，500服务器错误

get方法需要了2个位置参数
缺东西没写

打印看看是什么

现在就成功了

是个元组

这个元素是分组来的，url一个分组，大多数都是一个分组，这是django的做法，不是每一个都要传参的方式
（这种做法其实有很多，可以通过注入的方法，注入到request中也可以，在request中提取参数）

注入的话就可以这么用

是string，因为整个http基于文本传输的，在它眼里没有数字，http1.1到以前的都是文本传输的

请求资源，用一下httpnotfound，用404

如何去查询一个内容，找不到就抛出异常404

如果找到了就返回，也是json的。author_id也是有几种写法，详情页，就需要从post里去拿找post.content.content,一对一的关系建立好了，会帮你去找的

这里就拿回来了

时间恐怕不是我们想要的

这里强行做了字符串转换，而字符串不一定是你想要的，给客户端传，最好不要传字符串，在这里可以格式化掉，str和time，还有format函数

这里拿到是一个时间对象，在这里能否直接取时间对象的时间戳

存的时候已经告诉字段类型是时间了

愿意的话还可以取整，把这样的事情交给前端，让他们决定是用什么来显示

时间戳又回来了，用js函数可以直接转换过来

数据返回来就ok了
长度是先有内容，然后在发头的时候，将内容字节数提取出来，length取长度，然后添入到头中，再返回到客户端

这就是看到的内容，以后如果要鼠标移到作者名称，鼠标放上去的时候要跟作者相关，作者id最好带过来

测一个错误的地址，11

返回404

这样数据就可以从后端拿到了，这个就是文章详情页，文章详情页有标题栏，作者，什么时间发表，分段的正文，好看不好看依据样式表。