0.目录 整体架构目录:ASP.NET Core分布式项目实战-目录 一.前言 在开发项目的过程中,我新创建了一个controller,发现vs会给我们直接在controller头添加前缀,比如[Route("api/[controller]")],即在访问接口的时候会变成http://localhost:8000/api/values,但是如果控制器有很多个,或者要进行版本迭代时,我们会发现痛苦的时刻降临了,要一个一个的修改. 如果在这个时候可以进行全局配置前缀那真是福利呀,修改一处

通过全局异常类,所有程序中遇到的错误都会被拦截,并友好的返回结果. 1.自定义一个全局异常处理类中间件 using Microsoft.AspNetCore.Http; using Newtonsoft.Json; using System; using System.Collections.Generic; using System.IO; using System.Linq; using System.Net; using System.Threading.Tasks; using Syst

⒈新建ASP.NET Core WebAPi项目 ⒉添加 NuGet 包 Install-Package Swashbuckle.AspNetCore ⒊Startup中配置 using System; using System.Collections.Generic; using System.Linq; using System.Threading.Tasks; using Microsoft.AspNetCore.Builder; using Microsoft.AspNetCore.Ho

上一篇我们介绍了数据塑形,HATEOAS和内容协商,并在制器方法中完成了对应功能的添加:本章我们将介绍日志和测试相关的概念,并添加对应的功能 一.全局日志 在第一章介绍项目结构时,有提到.NET Core启动时默认加载了日志服务,且在appsetting.json文件配置了一些日志的设置,根据设置的日志等级的不同可以进行不同级别的信息的显示,但它无法做到输出固定格式的log信息至本地磁盘或是数据库,所以需要我们自己手动实现,而我们可以借助日志框架实现. ps:在第7章节中我们记录的是数据处理层方

最近我们团队一直进行.net core的转型,web开发向着前后端分离的技术架构演进,我们后台主要是采用了asp.net core webapi来进行开发,开始每次调试以及与前端人员的沟通上都存在这效率低下的问题,一次在看微软asp.net core官方文档的时候,发现了swagger这个好东西.然后在实际的项目中引入了该技术.我们开发人员测试自己写的api的过程大大得到了简化,前端人员也可以根据我们提供的swagger help pages 自己进行一些前端代码的测试,大大提高了前后端的开发效

版本控制的好处: (1)助于及时推出功能, 而不会破坏现有系统. (2)它还可以帮助为选定的客户提供额外的功能. API 版本控制可以采用不同的方式进行控制,方法如下: (1)在 URL 中追加版本或作为查询字符串参数, (2)通过自定义标头和通过接受标头 在这篇文章中, 让我们来看看如何支持多个版本的 ASP.NET  Core  Web API. 一.创建asp.net core webapi 项目,引用NuGet包:Install-Package Microsoft.AspNetCore.

Swagger简介: Swagger™的目标是为REST APIs 定义一个标准的,与语言无关的接口,使人和计算机在看不到源码或者看不到文档或者不能通过网络流量检测的情况下能发现和理解各种服务的功能.当服务通过Swagger定义,消费者就能与远程的服务互动通过少量的实现逻辑.类似于低级编程接口,Swagger去掉了调用服务时的很多猜测. 创建一个Asp.Net Core WebApi项目. 想要使用我们的Swagger你必须有Api,所以呢我们先构造一个数据库,当然我们可以使用DbFist,我们

ASP.NET Core WebApi 创建项目 使用VS新建项目,选择ASP.NET Core WebAPI即可. 此时Startup的Configure.ConfigureService方法中如下: // HTTP请求管道 public void Configure(IApplicationBuilder app, IHostingEnvironment env) { app.UseMvc(); } // 配置IOC容器 public void ConfigureServices(IServ

一.Core  WebAPI中的跨域处理  1.在使用WebAPI项目的时候基本上都会用到跨域处理 2.Core WebAPI的项目中自带了跨域Cors的处理,不需要单独添加程序包 3.使用方法简单 二.使用实例 1.全局配置中启用跨域处理,命名为‘any’,任何都可以访问 public void ConfigureServices(IServiceCollection services) { //配置跨域处理 services.AddCors(options => { options.AddP

最近我们团队一直进行.net core的转型,web开发向着前后端分离的技术架构演进,我们后台主要是采用了asp.net core webapi来进行开发,开始每次调试以及与前端人员的沟通上都存在这效率低下的问题,一次在看微软asp.net core官方文档的时候,发现了swagger这个好东西.然后在实际的项目中引入了该技术.我们开发人员测试自己写的api的过程大大得到了简化,前端人员也可以根据我们提供的swagger help pages 自己进行一些前端代码的测试,大大提高了前后端的开发效

一.Core WebAPI中的序列化 使用的是Newtonsoft.Json,自定义全局配置处理: // This method gets called by the runtime. Use this method to add services to the container. public void ConfigureServices(IServiceCollection services) { //使用IMvcBuilder 配置Json序列化处理 services.AddMvc()

目录 为什么是 JWT Bearer 什么是 JWT JWT 的优缺点 在 WebAPI 中使用 JWT 认证 刷新 Token 使用授权 简单授权 基于固定角色的授权 基于策略的授权 自定义策略授权 基于资源的授权 源代码 参考 为什么是 JWT Bearer ASP.NET Core 在 Microsoft.AspNetCore.Authentication 下实现了一系列认证, 包含 Cookie, JwtBearer, OAuth, OpenIdConnect 等, Cookie 认证是

0.目录 整体架构目录:ASP.NET Core分布式项目实战-目录 一.介绍 此篇文章将会介绍项目的全局异常收集以及采用log4net或者NLog记录. 众所周知,一旦自己的项目报错,如果没有进行处理都是显示不友好的,有得甚至直接爆出错误页面,看的也是很奇怪. 为了避免出现这样的错误以及在错误出现的时候可以进行收集错误,供维护人员进行bug修改,因此需要进行全局异常的收集. 让我们开始部署吧. 此篇文章的目录 1.log4net使用 2.Nlog使用 后期将会把NLog+ELK进行结合部署收集

一. 基础总结 1.Restful服务改造 Core下的WebApi默认也是Restful格式服务,即通过请求方式(Get,post,put,delete)来区分请求哪个方法,请求的URL中不需要写方法名. 但是我们不喜欢这种方式,所以我们将默认的路由规则 [Route("api/[controller]")] 改为: [Route("api/[controller]/[action]")] 2.基本格式 继承 ControllerBase 类,需要加特性[ApiC

概述 本文使用ionic/angular开发网页前台,asp.net core webapi开发restful service,使用keycloak保护前台页面和后台服务,并且利用open api自动生成代码功能,减少了重复代码编写. 准备工作 1.使用docker搭建并启动keycloak服务器,新建名称为test的realm,并建立几个测试用户,并且建立1个名称为my_client的客户端,注意客户端的回调url要正确. 2.安装ionic,使用 ionic start myApp tabs

#前言 我可能有三年没怎么碰C#了,目前的工作是在全职搞前端,最近有时间抽空看了一下Asp.net Core,Core版本号都到了5.0了,也越来越好用了,下面将记录一下这几天以来使用Asp.Net Core WebApi+Dapper+Mysql+Redis+Docker的一次开发过程. ## 项目结构 最终项目结构如下,CodeUin.Dapper数据访问层,CodeUin.WebApi应用层,其中涉及到具体业务逻辑的我将直接写在Controllers中,不再做过多分层.CodeUin.He

前言 近期在重新搭建一套基于ASP.NET Core WebAPI的框架,这其中确实带来了不少的收获,毕竟当你想搭建一套框架的时候,你总会不自觉的去想,如何让这套框架变得更完善一点更好用一点.其中在关于WebApi统一结果返回的时候,让我也有了更一步的思考,首先是如何能更好的限制返回统一的格式,其次

这里说的跨域是指通过js在不同的域之间进行数据传输或通信,比如用ajax向一个不同的域请求数据,或者通过js获取页面中不同域的框架中(iframe)的数据.只要协议.域名.端口有任何一个不同,都被当作是不同的域.默认浏览器是不支持直接跨域访问的.但是由于种种原因我们又不得不进行跨域访问,比如当前后端分离的方式开发程序是跨域是不可避免的.而解决跨域的方式也比较简单:1.通过jsonp跨域2.通过修改document.domain来跨子域3.添加对服务端进行改造使其支持跨域.接下来说说怎么实现asp

WebApi写好之后,在线帮助文档以及能够在线调试的工具是专业化的表现,而Swagger毫无疑问是做Docs的最佳工具,自动生成每个Controller的接口说明,自动将参数解析成json,并且能够在线调试. 那么要讲Swagger应用到Asp.net Core中需要哪些步骤,填多少坑呢? 安装Swagger到项目 { "dependencies": { "Swashbuckle": "6.0.0-beta902", ........ 或者直接通

Asp.Net Core WebApi学习笔记(四)-- Middleware 本文记录了Asp.Net管道模型和Asp.Net Core的Middleware模型的对比,并在上一篇的基础上增加Middleware功能支持. 在演示Middleware功能之前,先要了解一下Asp.Net管道模型发生了什么样的变化. 第一部分:管道模型 1. Asp.Net管道 在之前的Asp.Net里,主要的管道模型流程如下图所示: 请求进入Asp.Net工作进程后,由进程创建HttpWorkRequest对象