住房和城乡建设部网站焊工查询,python生成网页,wordpress为什么被,网站做编辑器什么是Rest
RPC
1、Web API两种风格: 面向过程(RPC) 、面向REST (REST)
2、RPC:“控制器/操作方法“的形式把服务器端的代码当成方法去调用。把HTTP当成传输数据的通道#xff0c;不关心HTTP谓词。通过QueryString请求报文体给服务器传递数据。状态码。比如/Persons/GetAll…什么是Rest
RPC
1、Web API两种风格: 面向过程(RPC) 、面向REST (REST)
2、RPC:“控制器/操作方法“的形式把服务器端的代码当成方法去调用。把HTTP当成传输数据的通道不关心HTTP谓词。通过QueryString请求报文体给服务器传递数据。状态码。比如/Persons/GetAll、/Persons/GetBvld?id8./Persons/Update、/Persons/DeleteByld/8
REST
REST: 按照HTTP的语义来使用HTTP协议 1、URL用于资源的定位: /user/888、/user/888/orders) 2、HTTP谓词: GET、POST (新增) 、PUT (整体更新)DELETE、PATCH (局部更新) 等 3、什么是“幂等”举例? DELETE删除id1的数据多次删除都是一样的、PUT、GET是幂等的POST不幂等幂等执行一次和执行多次的结果是一致的 4、GET的响应可以被缓存 5、服务器端要通过状态码来反映资源获取的结果: 404、403(没有权限) 、201 (新增成功) RPC:业务驱动自然 REST: 要求开发人员对REST原则更了解、并且有更多的设计能力。
没有绝对的好与坏根据业务需求选择适合自己的方式。
REST的优缺点
REST的优点
1、通过URL对资源定位语义更清晰 2、通过HTTP谓词表示不同的操作接口自描 3、可以对GET、PUT、DELETE请求进行重试 4、可以用GET请求做缓存 5、通过HTTP状态码反映服务器端的处理结果统一错误处理机制。 6、网关等可以分析请求处理结果
REST的缺点
1、真实系统中的资源非常复杂很难清晰地进行资源的划分对技术人员的业务和技术水平要求高。 2、不是所有的操作都能简单地对应到确定的HTTP谓词力 3、系统的进化可能会改变幂等性. 4、通过URL进行资源定位不符合中文用户的习惯 5、HTTP状态码个数有限。 6、有些环节会篡改非200响应码的响应报文 7、有的客户端不支持PUT、DELETE请求。
选择
1、REST是学术化的概念仅供参考。为什么AWS、ES等比较RESTful。为什么阿里、腾讯等很多系统不RESTful? 2、根据公司情况进行REST的选择和裁剪
Asp.NET Core Restful中如何传递参数
HTTP传递参数的三种方式
URL: 适合定位;长度限制 QueryString: 灵活长度限制 请求报文体:灵活长度不限制不支持GET、Delete
三种方式的不同语义
URL: 资源定位 Querstring URL之外的额外数据 请求报文体: 供PUT、POST提供数据
实施指南
1、完全按照HTTP语义要求高 2、我的建议 1)对于保存、更新类的请求POST、PUT请求把全部参数都放到请求报 文体中;
2) 对于DELETE请求要传递的参数就是一个资源的id因此把参数放到QueryString中即可3) 对于GET请求一般参数的内容都不会太长因此统一通过QueryString传递参数就可以。对于极少数参数内容超过URL限制的请求由于GET、PUT请求都是幂等的因此我们把请求改成通过PUT请求然后通过报文体来传递参数。Asp.NET Core如何返回错误码
状态码
1、REST:通过HTTP状态码返回服务器端的处理结果 2、问题
HTTP状态码数量有限HTTP的状态码并不适合用来表示业务层面的错误码它是一个用来表示技术层面信息的状态码。新增用户的操作中如果服务器端要求Json格式客户端提交XML服务器返回400是没问题的。但是如果用户名格式错误或者用户名重复存在200派和400派
400派观点
1、网关等可以监控HTTP状态码如果接口频繁出现4xx1状态码那么就说明客户端的代码不完善。 2、很多的系统都是按照HTTP状态码的不同含义进行设计的。如果失败了服务器端返回的状态码还是200的话这会违背软件设计的初衷。
200派观点
网络的问题归网络、业务的问题归业务。业务错误不应该和技术错误混在一起。把系统日志和业务日志区分开。
大企业也不统一 百度: 200派 谷歌: 400派 同一家公司企业微信和微信小程序: 200派 微信支付: 400派
个人观点:400派 1、对于数据库服务器连接失败、请求报文格式、服务器端异常等非业务错误服务器端应该返回4xx、5xx等状态招 2、对于业务层面的错误比如用户不存在我们要使用4xx等HTTP状态码返回。同样在响应报文体中给出详细的错误信息比如(“code”:3,message”:”用户不存在”}。 3、不仅要返回4xx的HTTP状态码而且不要忘了通过响应报文体给出详细的错误信息。对于用户不存在不仅要404而且把响应报文体设置为(“code”:3,message”:”用户名已存在”]这样能区分出来是哪里的问题
ASP.NET Core中的Rest落地指南
实现建议
1、使用RPC风格: Users/AddNew、Users/GetAll、Users/DeleteByld。 2、对于可以缓存的操作使用GET请求对于幂等的更新操作使用PUT请求对于幂等的删除操作使用DELETE请求对于其他操作统一使用POST请求。 3、参数: 保存、更新类的请求使用POST、PUT请求把全部参数都放到请求报文体中;对于GET和DELETE请求把参数放到QueryString中。推荐尽量使用URL做资源定位。 4、对于业务错误服务器端返回合适的4XX状态码不知道该选择哪个状态码就用400同时在报文体中通过code参数提供业务错误码以及错误消息。 5、如果请求的处理执行成功服务器端返回值为200的Http状态码如果有需要返回给客户端的数据则服务器端把这些数据放到响应报文体
实现技术
1、控制器上[Route(“[controller]/[action]”)] 2、强制要求控制器中不同的操作用不同的方法名2 3、把[HttpGet]、[HttpPost]、[HttpDelete]、[HttpPut]等添加到对应的操作方法上。 注意: 如果控制器中存在一个没有添加[HttpGet].[HttpPost]等的public方法Swagger就会报错可以用ApiExplorerSettings(lgnoreApi true)] 运行结果: 但是此时这个接口是可以直接调用的
将方法改为private 运行结果 或者加上特性 运行结果: 测试 新建Person类 编写控制类 [HttpGet] 运行 GetAll getById
Post addNew
