api接口

一：Desktop类和SystemTray类 在JDK6中 ,AWT新增加了两个类:Desktop和SystemTray。 前者可以用来打开系统默认浏览器浏览指定的URL,打开系统默认邮件客户端给指定的邮箱发邮件,用默认应用程序打开或编辑文件(比如,用记事本打开以txt为后缀名的文件),用系统默认的打印机打印文档;后者可以用来在系统托盘区创建一个托盘程序. 二:使用JAXB2来实现对象与XML之间的映射 JAXB是Java Architecture for XML Binding的缩写，可以将一个Java对象转变成为XML格式，反之亦然。 我们把对象与关系数据库之间的映射称为ORM, 其实也可以把对象与XML之间的映射称为OXM(Object XML Mapping). 原来JAXB是Java EE的一部分，在JDK6中，SUN将其放到了Java SE中，这也是SUN的一贯做法。JDK6中自带的这个JAXB版本是2.0, 比起1.0(JSR 31)来，JAXB2(JSR 222)用JDK5的新特性Annotation来标识要作绑定的类和属性等，这就极大简化了开发的工作量。 实际上，在Java EE 5.0中，EJB和Web Services也通过Annotation来简化开发工作。另外,JAXB2在底层是用StAX(JSR 173)来处理XML文档。除了JAXB之外

要点 Reactor 是一个运行在 Java8 之上的响应式流框架，它提供了一组响应式风格的 API 除了个别 API 上的区别，它的原理跟 RxJava 很相似 它是第四代响应式框架，支持操作融合，类似 RxJava 2 Spring 5 的响应式编程模型主要依赖 Reactor RxJava 回顾 Reactor 是第四代响应式框架，跟RxJava 2 有些相似。Reactor 项目由Pivotal 启动，以响应式流规范、Java8 和ReactiveX 术语表为基础。它的设计是Reactor 2（上一个主要版本）和RxJava 核心贡献者共同努力的结果。 在之前的同系列文章 RxJava 实例解析 和 测试RxJava 里，我们已经了解了响应式编程的基础：数据流的概念、Observable 类和它的各种操作以及通过工厂方法创建静态和动态的Observable 对象。 Observable 是事件的源头，Observer 提供了一组简单的接口，并通过订阅事件源来消费 Observable 的事件。Observable 通过 onNext 向 Observer 通知事件的到达，后面可能会跟上 onError 或 onComplete 来表示事件的结束。 RxJava 提供了 TestSubscriber 来测试 Observable，TestSubscriber 是一个特别的

前言 　　很久没写文章了，今天有时间，把自己一直以来想说的，写出来，算是一种总结吧！ 这篇文章主要说前后端分离模式下(也包括app开发)，自己对后台框架和与前端交互的一些理解和看法。 　 前后端分离，一般传递json数据，对于 出参 ，现在通用的做法是，包装一个响应类，里面包含code，msg，data三个属性，code代表状态码，msg是状态码对应的消息，data是返回的数据。 　　如 {"code":"10008","message":"手机号不存在","totalRows":null,"data":null} 　　对于入参，如果没有规范，可是各式各样的，比如： 　　UserController的getById方法，可能是这样的： 　　　　 　　　　如果是把变量放在url，是这样的： 　　　　 　　比如 addUser方法，如果是用user类直接接收参数，是这样的： 　　 　　这样在前后端不分离的情况下，自己前后端代码都写，是没有啥问题，但是前后端分离情况下，如果这样用user类接收参数，如果你用了swagger来生成接口文档，那么，User类里面的一些对于前段来说没用的字段（createTime、isDel、updateTime。。。），也都会给前端展示出来，这时候前端得来问你，哪些参数是有用的，哪些是没用的。其实每个接口，对前端没用的参数，最好是不要给他展示，所以

1.简述 Java8中有两大最为重要的改变。第一个是 Lambda 表达式；另外一 个就是 Stream API。 Stream 是处理集合的抽象概念，它可以指定你希望对集合进行的操作，可以执行非常复杂的查找、过滤和映射数据等操作。使用Stream API 对集合数据进行操作，就类似于使用 SQL 执行的数据库查询，比如可以实现group by的分组操作。总之就是Stream API提供的高效简介的数据处理方式。 流(Stream)是什么？心脏的血液通过血管流变全身，在血管中的时候就可以看做流，生病了需要通过血管进行输液，也就是说在这个流中进行了操作。心脏的血液可以看做一个数据集合，转换成流通过血管进行输送，输液这个操作就相当于是我们Stream API 所做的操作，也就是对这个流进行计算处理。 集合是数据，流是计算。 需要注意的是： 　　1.Stream 自己不会存储元素。 　　2.Stream 不会改变源对象。相反，他们会返回一个持有结果的新Stream。 　　3.Stream 操作是延迟执行的。这意味着他们会等到需要结果的时候才执行。 Stream三步走： 　　1.创建流 　　2.操作流 　　3.终止操作获取结果，注意： 流进行了终止操作后，不能再次使用 2.API操作案例 　　 2.1.创建流 //集合创建流 Stream<Student> stream1 =

前言 在app开放接口api的设计中，避免不了的就是安全性问题，因为大多数接口涉及到用户的个人信息以及一些敏感的数据，所以对这些接口需要进行身份的认证， 那么这就需要用户提供一些信息，比如用户名密码等，但是为了安全起见让用户暴露的明文密码次数越少越好，我们一般在web项目中，大多数采用保存的session中， 然后在存一份到cookie中，来保持用户的回话有效性。但是在app提供的开放接口中，后端服务器在用户登录后如何去验证和维护用户的登陆有效性呢？ 设计 对于敏感的api接口，需使用https协议 https是在http超文本传输协议加入SSL层，它在网络间通信是加密的，所以需要加密证书。https协议需要ca证书，一般需要交费。 　　1、原理 用户登录后向服务器提供用户认证信息（如账户和密码），服务器认证完后给客户端返回一个PID令牌，用户再次获取信息时， 带上此令牌，如果令牌正取，则返回数据。对于获取Token信息后，访问用户相关接口，客户端请求的url需要带上如下参数： 　　① 时间戳：timestamp 　　② PID令牌：PID（在这我们给定义为PID） 然后将所有用户请求的参数（包括timestamp，pid），然后更具MD5加密（可以加点盐），生成动态的url。 然后登陆后每次调用用户信息时，带上timestamp，pid参数。 加上时间戳和pid后的URL

注： 本文是【 ASP.NET Web API系列教程 】的一部分，如果您是第一次看本系列教程，请先看前面的内容。 Exception Handling in ASP.NET Web API ASP.NET Web API中的异常处理 本文引自：http://www.asp.net/web-api/overview/web-api-routing-and-actions/exception-handling By Mike Wasson | March 12, 2012 作者：Mike Wasson ｜ 日期：2012-3-12 This article describes error and exception handling in ASP.NET Web API. 本文描述ASP.NET Web API中的错误与异常处理： HttpResponseException Exception Filters 异常过滤器 Registering Exception Filters 注册异常过滤器 HttpError HttpResponseException What happens if a Web API controller throws an uncaught exception? By default, most exceptions are translated into

前言 Windows下实现摄像视频捕捉有多种实现方式；各种方式的优劣，本文不做对比。但是，opencv是一款老牌开发库，在图像处理领域声名显赫。采用opencv来处理摄像视频，在性能和稳定性上，是有保障的。并且，opencv包含很多图像处理函数，可以更方便的对视频处理。 　　执行程序是用wpf开发的，所以先将opencv封装成c语言接口，以供调用。opencv也不可能提供现成的控件供wpf使用，两种不同的开发语言“沟通”起来有些困难。其实稍作变通，就可以实现摄像头播放功能。 1 对opencv封装 opencv的类VideoCapture封装了对摄像头的操作，使用起来也非常简单。 bool open(int device); device为摄像头设备序号。 如果有多个摄像头，怎么知道哪个摄像头的序号那？可以通过如下函数，获取摄像头列表。摄像头在list中索引即为设备序号。 int GetCameraDevices(vector<wstring>& list) { ICreateDevEnum *pDevEnum = NULL; IEnumMoniker *pEnum = NULL; int deviceCounter = 0; CoInitialize(NULL); HRESULT hr = CoCreateInstance(CLSID_SystemDeviceEnum, NULL

前段时间工作上比较忙，这篇文章一直没来得及写，本文是阅读《Java8实战》的时候，了解到Java 8里已经提供了一个异步非阻塞的接口（CompletableFuture），可以实现简单的响应式编程的模式，因此用这篇文章做个梳理。我是带着下面这几个问题去学习CompletableFuture这个接口的， CompletableFuture是为了解决什么问题而设计的？ 它的使用场景是什么？开源软件中有实战使用案例吗？ CompletableFuture的常用API都有哪些？如何使用？ CompletableFuture和RxJava有什么不同？ 这篇文章梳理下来，基本上可以回答前面四个问题，OK，我们进入正文。 基本概念 RPC（远程方法调用）的四种方式有：oneway、sync、future和callback，在dubbo或bolt这类通信框架中，默认使用的是sync模式（同步+阻塞），future和callback都属于异步模式，不过future模式在get的时候会阻塞，callback模式则不需要等待结果，有结果后服务端会回调请求方。 异步调用这类模式，比较适合的场景是IO密集型场景，要执行很多远程调用的任务，并且这些调用耗时可能比较久。以openwrite中的一个case为例：我发布一篇文章，需要给几个不同的写作平台创建文章，这时候我不希望这个过程是顺序的

一、简介 Guava提供的RateLimiter可以限制物理或逻辑资源的被访问速率。RateLimit二的原理类似与令牌桶，它主要由许可发出的速率来定义，如果没有额外的配置，许可证将按每秒许可证规定的固定速度分配，许可将被平滑地分发，若请求超过permitsPerSecond则RateLimiter按照每秒1/permitsPerSecond的速率释放许可。 使用RateLimiter需要引入的jar包： <!-- Guava是一种基于开源的Java库,谷歌很多项目使用它的很多核心库。这个库是为了方便编码,并减少编码错误 --> <dependency> <groupId>com.google.guava</groupId> <artifactId>guava</artifactId> <version>${guava.version}</version> </dependency> 注意： Guava 20（将于2016年初发布）将是支持Java 6甚至Java 7的最终Guava版本.Guava 21（理想情况下是2016年中期）将需要Java 8。 在版本21中，我们还将启动一个新的分支，可能称为guava-android。它将保持Java 6兼容性，允许它用于支持最小版本Gingerbread的Android应用程序。 方法摘要： 参考地址：https://www

随着.NET Core 3.0 Preview 7的发布，C＃8.0已被认为是“功能完整”的。这意味着它们的最大亮点Nullable Reference Types，在行为方面也被锁定在.NET Core版本中。它将在C＃8.0之后继续改进，但现在可以认为它与C＃8.0的其余部分一样是稳定的。 目前，我们的目标是尽可能多地收集关于可空性使用过程中的反馈以发现问题，同时收集有关在.NET Core 3.0之后我们可以做的功能的进一步改进的反馈。这是有史以来为C＃构建的最大功能之一，尽管我们已尽力做好它，但我们仍然需要您的帮助！ 正是基于这样的交叉点，我们特别呼吁.NET库作者们尝试使用该功能并开始注解您的库。我们很乐意听取您的反馈并帮助解决您所遇到的任何问题。 熟悉该功能 我们建议您在使用该功能之前，先阅读一下 Nullable Reference Types文档 ，它包含以下功能点： 概念性概述 如何指定可为空的引用类型 如何控制编译器分析或覆盖编译器分析 如果您还不熟悉这些概念，请在继续操作之前快速阅读文档。 为您的库采用可空性的第一步是放开Nullable约束。具体步骤： 确保您使用的是C＃8.0 如果您的库是基于 netcoreapp3.0的 ，默认情况下将使用C＃8.0。当我们发布预览8时，如果你是基于 netstandard2.1 构建，那么默认情况也将使用C＃8.0 。