技术人员如何确认web产品的需求
web需求定义涉及到展示和交互两个部分，展示是打开一个页面时呈现出来的页面效果，交互是用户通过鼠标，键盘，触摸或其他外设操作之后系统给出响应的过程。
对于页面的展示要从下面几个角度来确认需求。
一. 界面展示，需要确认展示的逻辑
1）展示逻辑通常要考虑不同的角色进入页面时候的显示是否一致，如果不一致，则要明确不同角色进来后显示内容的异同
2）对于有隐藏内容的控件，必须确认隐藏的内容，例如菜单，tab
3）对于每一个显示单元要确认显示数据的逻辑，例如“最热文章”，必须要确认这个最热文章是如何定义的，是按点击的还是按转贴的，还是其他逻辑，另外还要注意这个最热是否有隐含的时间范围
4）对于显示区域临界条件的确认，要确认数据不足时如何展示，数据字段过长时如何展示
二. 交互需求确认
什么是交互呢？ 页面展示出来，用户通过鼠标，键盘，触摸或其他外设操作之后系统给出响应的过程就是交互。
对于传统的web最常见的交互是填写表单和鼠标点击。
我们可以先考虑表单需求的确认。 可以把表单性需求的确认分为三个阶段 1） 表单填写 ２）表单的提交 ３）表单提交后的响应
先来看表单填写需要确认的需求：
1. 对于输入性控件必须确认输入框是否必填，输入框是否需要格式校验，是否有最大长度限制，是否有相等性校验。
2. 对于选择性控件，也要明确是否有最多选择数，最少选择数，是否可以不填等边界条件
3. 另外要注意是否有键盘操作便捷的需求，例如按回车或Ctrl+回车提交，按tab键要到下一个表单元素
4. 是否需要在进入界面时自动focus到某一控件上
5. 当用户将焦点移向下一个控件时是否需要做交互判断（最典型的是注册用户填写用户名后自动校验用户名是否存在）
上面5点前两点是边界条件的确认，第3，4是便捷性需求的确认，第5点是用户友好性的确认
表单填写完毕用户就可以提交表单了，提交表单有异步和同步两种方式，最好给产品经理确认提交的方式，另外还要评估表单提交是否涉及到耗时的操作，如果操作很耗时，应该要求产品经理给出应对用户等待焦虑的方案。
最后需要明确表单提交之后需要明确后端处理的业务逻辑，和处理成功或者失败之后的提示或页面跳转。
除了表单之外最常见的交互是鼠标点击，例如点击删除链接，删除一条记录，这时候要确认点击前需要客户端如何响应，点击服务器收到成功响应后如何显示，失败时如何显示。
对于一个系统来说添加或者修改一个功能点，往往会影响其他功能点，在做需求确认时还要明确当前操作会影响到地方，影响是什么样子的，如果因为性能原因使用了缓存，要给产品同事明确缓存时间。
总结：
技术人员在确认需求是要考虑界面效果，要考虑显示逻辑，也要考虑后台的业务逻辑，以及当前需求点操作逻辑对其他地方的影响。
必须在确认需求阶段就充分考虑好界面显示的边界条件，用户输入的校验条件，用户交互的显示逻辑，有错误发生时的处理。
业务逻辑中一定要考虑到当前用户是否分了角色，操作的对象是谁，这个需求是否有时间范围,操作是否有其他的前提条件，是否影响到其他地方。
如何让ASP.NET WEB API 默认回应JSON 格式
WEB API 默认是通过客户端浏览器Header 发送的请求来决定返回什么格式的，如图中红色部分所示。浏览器默认是XML格式的 所以如果我们不加以限定Header的Accept值，默认返回的是XML格式。 WEN API服务端返回数据格式支持主要有XML 以及 JSON，我们的思路是直接从服务端移除XML格式的支持，那自然而然就只好返回JSON格式了。
解决方案：
在Global.asax.cs的Application_Start中
加入
GlobalConfiguration.Configuration.Formatters.XmlFormatter.SupportedMediaTypes.Clear();
如图
保存 重新生成 F5。
我们可以看到 红色区域的Accept值不变 但是返回的数据已经变成了可爱的JSON了。OVER