webapi

对HTTP协议的基本了解是能理解并使用RestFul风格API的基础，在了解了这些基础之后，使用各种RestFul的开发框架才能得心应手。我一开始使用WebApi的时候就因为对这些知识缺乏了解，觉得用起来各种不顺手，直到熟悉了这些HTTP的知识后，使用WebApi开发起来才觉得得心应手，我的理解里，RestFul风格的API即是对HTTP协议良好支持，实现HTTP完整语义风格的API。 在介绍这些知识之前，我需要强调一下很多人存在的一个误区：HTTP的谓词和数据传递方式。绝大多数人接触并使用的HTTP协议都是在网站编写的过程中，在一般的WEB应用中，我们仅使用GET、POST两个谓词，其他谓词并不适用，在这一习惯下很多人有几个奇怪的认知：HTTP协议只适用于网站开发，HTTP仅有两个谓词：GET/POST，HTTP调用数据传递仅使用表单K-V的形式进行；在这种认知下，用这种风格开发的RestApi经常会不伦不类，使用ASP.NET WebAPi也会显得不伦不类，平添麻烦。而我们首先要认识到，网站的数据交互只是HTTP使用的一个场景而已，HTTP可以传递各种形式的数据。 我们从HTTP的第一行说起：HTTP的第一行包含三个信息：谓词、URL、HTTP协议版本。三个数据使用空格隔开。 谓词：对于RestFul API来说谓词是非常重要的一个元素，WEB

上篇中简单介绍了一下WebApi,本章主要介绍一下Controller相关的知识。 在实际应用中，Controller是WebAPI的链接服务器和客户端的窗口。Controller的好坏影响整个系统的设计。Controller中是各种Action接口，对于Action接口，我们有必要对其接收的参数和返回值了解。 Action返回类型 WebAPI服务函数的返回值主要可以分为void、普通对象、HttpResponseMessag、IHttpActionResult 四种，这里简单的介绍一下。 Void类型 一般来说，Delete和Put类型的求情返回void类型的值，如： public class DepartmentController : ApiController { public void Delete(int id) { } } 不过一个交互性好的接口，应该返回正确的Http status code,如返回200,对列子做修改： public class DepartmentController : ApiController { public HttpStatusCode Delete(int id) 　　{ 　　　　return HttpStatusCode.OK; 　　} } 普通对象 普通对象通常是由Get接口返回。例如： public class

WebApi是微软在VS2012 MVC4版本中绑定发行的，WebApi是完全基于Restful标准的框架。RestFul: （英文：Representational State Transfer，简称REST）网上关于Restful定义的资料很多，我个人理解的Restful api 是指基于资源的定义的接口,它的所有接口都是对资源的操作。REST的核心原则是将你的API拆分为逻辑上的资源。这些资源通过http被操作（GET ,POST,PUT,DELETE).Restful Api接口标准的定义满足CURD，标准的接口定义如下： Post:新增记录 Put:修改记录 Get:获取数据 Delete:删除数据 webapi标准的定义形式为：每个controller都对应一个Model，controller中的接口都应该是对controller所对应的那个model进行的操作，所以上诉的post,get,put,delete都是对model所对应的资源操作。但是在实际的操作中，可能没有办法完全满足这种定义的形式，力求尽量满足。 WebAPI项目和典型的MVC项目一样，包含主要的Models，Views，Controllers等文件夹和Global.asax文件。Views对于WebAPI来说没有太大的用途，Models中的Model主要用于保存Service和Client交互的对象

WebApi是微软在VS2012 MVC4版本中绑定发行的，WebApi是完全基于Restful标准的框架。RestFul: （英文：Representational State Transfer，简称REST）网上关于Restful定义的资料很多，我个人理解的Restful api 是指基于资源的定义的接口,它的所有接口都是对资源的操作。REST的核心原则是将你的API拆分为逻辑上的资源。这些资源通过http被操作（GET ,POST,PUT,DELETE).Restful Api接口标准的定义满足CURD，标准的接口定义如下： Post:新增记录 Put:修改记录 Get:获取数据 Delete:删除数据 webapi标准的定义形式为：每个controller都对应一个Model，controller中的接口都应该是对controller所对应的那个model进行的操作，所以上诉的post,get,put,delete都是对model所对应的资源操作。但是在实际的操作中，可能没有办法完全满足这种定义的形式，力求尽量满足。 WebAPI项目和典型的MVC项目一样，包含主要的Models，Views，Controllers等文件夹和Global.asax文件。Views对于WebAPI来说没有太大的用途，Models中的Model主要用于保存Service和Client交互的对象

在RestFul风格盛行的年代，对接接口大多数人会选择使用JSON,XML和JSON的对比传送（http://blog.csdn.net/liaomin416100569/article/details/5480825），看看这位博主是怎么说的，虽然最后没有说完，我想大概也能略微解决心中的疑惑。 1.其实要想让WebAPI 返回JSON格式的数据很简单，只要在ConfigureWebapi方法中配置一下即可。此前需要引用两个命名空间。 using Newtonsoft.Json.Serialization; using System.Linq; 2.核心代码如下： var json = config.Formatters.JsonFormatter; // 解决json序列化时的循环引用问题 json.SerializerSettings.ReferenceLoopHandling = Newtonsoft.Json.ReferenceLoopHandling.Ignore; // 移除XML序列化器 config.Formatters.Remove(config.Formatters.XmlFormatter); //设置序列化方式为驼峰命名法 var jsonFormatter = config.Formatters.OfType<System.Net.Http

目录 前言 Autofac 添加一个Util来随时调用 小结 代码地址 预告 前言 周末加班，下午犯困，整理下之前鼓捣过的东西，看过我之前的webapi系列的读者知道，我之前试过Aspect，但是升级到3.0之后没往下去试了，当时还留了个坑，这不，现在果断移除了换成这个了。 Autofac 这个第三方类库呢，是Ioc的容器，可以简化我们很大的工作量，比如说在之前我们需要写个类去声明接口与实现，而用了这个容器呢，就不需要了，当然还是需要些配置的。 首先，引入第三方类库，不多说。 然后开始配置吧，首先先来看Program，添加 AutofacServiceProviderFactory 。 public static IHostBuilder CreateHostBuilder(string[] args) => Host.CreateDefaultBuilder(args) .ConfigureWebHostDefaults(webBuilder => { webBuilder.UseStartup<Startup>(); }) .UseServiceProviderFactory(new AutofacServiceProviderFactory()); 改完之后呢，我们果断就来到了Startup，只要是配置，当然要看入口文件跟这个配置文件了。 3

原文: net core WebApi——依赖注入Autofac 目录 前言 Autofac 添加一个Util来随时调用 小结 代码地址 预告 前言 周末加班，下午犯困，整理下之前鼓捣过的东西，看过我之前的webapi系列的读者知道，我之前试过Aspect，但是升级到3.0之后没往下去试了，当时还留了个坑，这不，现在果断移除了换成这个了。 Autofac 这个第三方类库呢，是Ioc的容器，可以简化我们很大的工作量，比如说在之前我们需要写个类去声明接口与实现，而用了这个容器呢，就不需要了，当然还是需要些配置的。 首先，引入第三方类库，不多说。 然后开始配置吧，首先先来看Program，添加 AutofacServiceProviderFactory 。 public static IHostBuilder CreateHostBuilder(string[] args) => Host.CreateDefaultBuilder(args) .ConfigureWebHostDefaults(webBuilder => { webBuilder.UseStartup<Startup>(); }) .UseServiceProviderFactory(new AutofacServiceProviderFactory()); 改完之后呢，我们果断就来到了Startup，只要是配置

在项目中我们经常需要做的是，把我们写的应用封装成系统服务，那么它就会像一个守护程序一样，被操作系统所管理。目前linux有3种初始化系统，按出现的时间依次为init ，upstart和systemd。 3种系统简介 1. init init即sysvinit，它是system v的成果，被推广到其他unix系统。常见的init 命令和/etc/init.d即属于它。 init的优点来自服务串行启动，可以保证脚本执行顺序，也方便调试和排错。但也因为串行启动导致系统启动时间很长，在linux被应用到移动端后这个缺点成了大问题。 2. upstart upstart通过并行启动加快执行速度，但对于相互依赖的服务采用并发启动。它也支持硬件热插拔时的动态启动和卸载。 3.Systemd systemd的并发更激进，因为对于相互依赖的服务它也同时启动。而且它的按需启动比upstart更优秀。 upstart取代了曾经辉煌的init，而systemd将要取代upstart 问题： 如何判断某个linux系统采用了哪种初始化系统？ 初始化进程是kernel启动的第一个进程，其pid始终为1，因此我们可以使用stat /proc/1/exe可以查看： #stat /proc/1/exe File: `/proc/1/exe' -> `/sbin/init' Size: 0 Blocks: 0 IO

直接上代码，该说明的我都把注释写在代码中了 逻辑图如下： 一、创建WebApi（用于IdentityServer4发送token和验证token）（IdentityServerSolution） 1.nuget安装identityServer4（最新版必须是.net core3.0才可以，我是2.0，所以装不了最新版的）： Install-Package IdentityServer4 -version 2.5.4 2.创建Config类：配置资源和客户端（家里哪些东西可以被访问，以及客户端得满足什么条件才可以访问） using IdentityServer4.Models; using System.Collections.Generic; namespace IdentityServerSolution { public class Config { /// <summary> /// 允许访问哪些Api（就像我允许我家里的哪些东西可以让顾客访问使用，如桌子，椅子等等） CreateDate：2019-12-26 14:08:29；Author：Ling_bug /// </summary> /// <returns></returns> public static IEnumerable<ApiResource> GetApiResources() { return new[

终于忍不住对WebAPI下手了，网上有好多关于怎么通过VS创建WebAPI的教程，我在此就不再赘述了。 在这主要分享一下我在创建后调试的问题。 前提 ：写好一个简单的API，代码内容及所属文件夹架构如下： namespace webTestAPI.Controllers { public class TestController : ApiController { [HttpGet] public string getstring() { return "Hello Word"; } [HttpPost] public string returnstring(string name, string id) { return "我的名字是" + name + ";我的ID是" + id; } } } 问题 ：作为一名小白，顺着一般的思路就是点击调试，在URL给参数。当我调试时，点击调试按钮后页面如下： 点击调试后： 点击Controllers后： 点击TestController.cs后： 尝试着用 https://localhost:44382/webTestAPI/Controllers/TestController/getstring 直接调用仍然无效。纠结、、、 解决方案 ： 查了很多资料，问题根源是URL地址不对。 1.更改App_Start