restwebapi

1. webapi 發布後帶有多語言文件夾de es

在新出的MVC中，增加了WebAPI，用於提供REST風格的WebService，新生成的WebAPI項目和典型的MVC項目一樣，包含主要的Models、Views、Controllers等文件夾和Global.asax文件。Views對於WebAPI來說沒有太大的用途

2. webapi和mvc的區別

在新出的MVC中，增加了WebAPI，用於提供REST風格的WebService，新生成的WebAPI項目和典型的MVC項目一樣，包含主要的Models、Views、Controllers等文件夾和Global.asax文件。Views對於WebAPI來說沒有太大的用途，Models中的Model主要用於保存Service和Client交互的對象，這些對象默認情況下會被轉換為Json格式的數據迚行傳輸，Controllers中的Controller對應於WebService來說是一個Resource，用於提供服務。和普通的MVC一樣，Global.asax用於配置路由規則。
對於WebAPI來說它最初被設計為和WCF一樣的客戶端、服務端兩套結構我們到現在乊所以還沒有提到客戶端是因為我們的請求別的方式來封裝成HTTP請求戒接收HTTP相應的比如AJAX和Form表單提交。

3. 如何使 WebAPI 自動生成漂亮又實用在線API文檔

1.1 SwaggerUI

SwaggerUI 是一個簡單的Restful API 測試和文檔工具。簡單、漂亮、易用（官方demo）。通過讀取JSON 配置顯示API. 項目本身僅僅也只依賴一些 html,css.js靜態文件. 你可以幾乎放在任何Web容器上使用。

1.2 Swashbuckle

Swashbuckle 是.NET類庫,可以將WebAPI所有開放的控制器方法生成對應SwaggerUI的JSON配置。再通過SwaggerUI 顯示出來。類庫中已經包含SwaggerUI 。所以不需要額外安裝。

2.快速開始

創建項目 OnlineAPI來封裝網路音樂服務(示例下載) ，通過API可以搜索、獲取音樂的信息和播放連接。

我盡量刪除一些我們demo中不會用到的一些文件，使其看上去比較簡潔。

WebAPI 安裝 Swashbuckle

Install-Package Swashbuckle

代碼注釋生成文檔說明。
Swashbuckle 是通過生成的XML文件來讀取注釋的，生成 SwaggerUI，JSON 配置中的說明的。
安裝時會在項目目錄 App_Start 文件夾下生成一個 SwaggerConfig.cs 配置文件，用於配置 SwaggerUI 相關展示行為的。如圖：

將配置文件大概99行注釋去掉並修改為
c.IncludeXmlComments(GetXmlCommentsPath(thisAssembly.GetName().Name));

並在當前類中添加一個方法

/// <summary>
/// </summary>
/// <param name="name"></param>
/// <returns></returns>
protected static string GetXmlCommentsPath(string name)
{
return string.Format(@"{0}\bin\{1}.XML", AppDomain.CurrentDomain.BaseDirectory, name);
}

緊接著你在此Web項目屬性生成選卡中勾選 「XML 文檔文件」，編譯過程中生成類庫的注釋文件

添加網路音樂 3個API

訪問 http://<youhost>/swagger/ui/index,最終顯示效果

我們通過API 測試API 是否成功運行

3.添加自定義HTTP Header

在開發移動端 API時常常需要驗證許可權，驗證參數放在Http請求頭中是再好不過了。WebAPI配合過濾器驗證許可權即可

首先我們需要創建一個 IOperationFilter 介面的類。IOperationFilter
using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
using System.Web.Http;
using System.Web.Http.Description;
using System.Web.Http.Filters;
using Swashbuckle.Swagger;

namespace OnlineAPI.Utility
{
public class HttpHeaderFilter : IOperationFilter
{
public void Apply(Operation operation, SchemaRegistry
schemaRegistry, ApiDescription apiDescription)
{
if (operation.parameters == null) operation.parameters = new
List<Parameter>();
var filterPipeline =
apiDescription.ActionDescriptor.GetFilterPipeline();
//判斷是否添加許可權過濾器
var isAuthorized = filterPipeline.Select(filterInfo =>
filterInfo.Instance).Any(filter => filter is IAuthorizationFilter);
//判斷是否允許匿名方法
var allowAnonymous =
apiDescription.ActionDescriptor.GetCustomAttributes<AllowAnonymousAttribute>().Any();

if (isAuthorized && !allowAnonymous)
{
operation.parameters.Add(new Parameter
{
name = "access-key",
@in = "header",
description = "用戶訪問Key",
required = false,
type = "string"
});
}
}
}
}

在 SwaggerConfig.cs 的 EnableSwagger 配置匿名方法類添加一行注冊代碼
c.OperationFilter<HttpHeaderFilter>();

添加Web許可權過濾器
using System;
using System.Collections.Generic;
using System.Linq;
using System.Net;
using System.Net.Http;
using System.Text;
using System.Web;
using System.Web.Http;
using System.Web.Http.Controllers;
using Newtonsoft.Json;

namespace OnlineAPI.Utility
{
/// <summary>
///
/// </summary>
public class AccessKeyAttribute : AuthorizeAttribute
{
/// <summary>
/// 許可權驗證
/// </summary>
/// <param name="actionContext"></param>
/// <returns></returns>
protected override bool IsAuthorized(HttpActionContext actionContext)
{
var request = actionContext.Request;
if (request.Headers.Contains("access-key"))
{
var accessKey = request.Headers.GetValues("access-key").SingleOrDefault();
//TODO 驗證Key
return accessKey == "123456789";
}
return false;
}

/// <summary>
/// 處理未授權的請求
/// </summary>
/// <param name="actionContext"></param>
protected override void HandleUnauthorizedRequest(HttpActionContext actionContext)
{
var content = JsonConvert.SerializeObject(new {State = HttpStatusCode.Unauthorized});
actionContext.Response = new HttpResponseMessage
{
Content = new StringContent(content, Encoding.UTF8, "application/json"),
StatusCode = HttpStatusCode.Unauthorized
};
}
}
}

在你想要的ApiController 或者是 Action 添加過濾器
[AccessKey]

最終顯示效果

4.顯示上傳文件參數

SwaggerUI 有上傳文件的功能和添加自定義HTTP Header 做法類似，只是我們通過特殊的設置來標示API具有上傳文件的功能
using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
using System.Web.Http.Description;
using Swashbuckle.Swagger;

namespace OnlineAPI.Utility
{
/// <summary>
///
/// </summary>
public class UploadFilter : IOperationFilter
{

/// <summary>
/// 文件上傳
/// </summary>
/// <param name="operation"></param>
/// <param name="schemaRegistry"></param>
/// <param name="apiDescription"></param>
public void Apply(Operation operation, SchemaRegistry schemaRegistry, ApiDescription apiDescription)
{
if (!string.IsNullOrWhiteSpace(operation.summary) && operation.summary.Contains("upload"))
{
operation.consumes.Add("application/form-data");
operation.parameters.Add(new Parameter
{
name = "file",
@in = "formData",
required = true,
type = "file"
});
}
}
}
}

在 SwaggerConfig.cs 的 EnableSwagger 配置匿名方法類添加一行注冊代碼
c.OperationFilter<UploadFilter>();

API 文檔展示效果

4. restful和webapi的區別

restful是標准，webapi是.net的實現

5. WebAPI 和 webservice的區別

1、它是基於SOAP協議的，數據格式是XML
2、只支持HTTP協議
3、它不是開源的，但可以被任意一個了解XML的人使用
4、它只能部署在IIS上
Web API：
1、這是一個簡單的構建HTTP服務的新框架
2、在.net平台上Web API 是一個開源的、理想的、構建REST-ful 服務的技術
3、不像WCF REST Service.它可以使用HTTP的全部特點（比如URIs、request/response頭，緩存，版本控制，多種內容格式）
4、它也支持MVC的特徵，像路由、控制器、action、filter、模型綁定、控制反轉（IOC）或依賴注入（DI），單元測試。
5、它可以部署在應用程序和IIS上
6、這是一個輕量級的框架，並且對限制帶寬的設備，比如智能手機等支持的很好
7、Response可以被Web API的MediaTypeFormatter轉換成Json、XML 或者任何你想轉換的格式。

6. 內部系統可以做成通過REST API的方式調用嗎

想要為開發工程師們開發一個既能滿足REST約束條件和原則又不像OAuth OAuth 那樣復雜 the complexity ，僅僅使用簡單的傳值語句或者其它簡單但同樣安全的方法就能實現的web API?
聰明人會有聰明的想法…
問題
直接通過HTTP literally passing the credentials over HTTP以文本方式傳輸鑒權信息可能會被破譯; 尤其在 Gawker incident, 再以文本或是弱加密的方式傳輸鑒權信息是非常不安全的做法 weakly-hashed anything is usually a bad idea.
即便是使用哈希加密後還是很有可能被人根據彩虹表 Rainbow Table破譯出與用戶名匹配的密碼（個別案例）

這可該怎麼辦，真是郁悶…
也許你又會想到很多公共的API popular public APIs在請求中採用雙數據的模式：一個公有值一個（最好是有）只有屬主能訪問的私有值。
」還是有點不對!」這不跟原來（用戶名密碼模式）文本模式差不多麼，還是可能會被（嗅探器）破譯。
這時候你可能准備放棄並採用OAuth模式了，但仍堅信必有某種簡單方法能實現公用webAPI安全訪問私有鑒權信息。
解決方案

連續2天的Peyote實驗後（你可能會找到更好的放鬆辦法），結論終於呈現在你眼前：Amazon是擁有最大的、使用最多的在線網路API的網路服務之一，並且根本不支持OAuth！
經過一個下午長時間的狂想之後，你最終敗下陣來，並看到Amazon是如何保持API請求安全的。你不清楚為什麼，但讀完整頁關於如何為Amazon網路服務裝配一個請求後，你依然覺得不完全合理。這個「簽名」和什麼連在一起？代碼示例中的「data」參數是什麼？這樣，你會繼續查找關於「安全API設計」的文章。。。
當遇到其他人問同樣的問題時，你看到一些指出"HMAC"或其他事物的優秀回復，但還是不太確定。
你找到其他鼓勵你使用「HMAC」的文章並且你正H-FINE地使用它，如果有人將「HMAC」解釋成簡明的H_ENGLISH的話。
你的確偶遇了一個有道理的蒸餾的基本概念，它是這樣一簡明的英語描述的：
一個伺服器和客戶端知道一個公鑰和一個私鑰；只有伺服器和客戶端知道私鑰，但每個人都知道公鑰。。。但不關心別人所知道的。
一個客戶端生成一個唯一的HMAC（哈希）表示它到伺服器的請求。通過把請求數據（參數和值或XML/JSON或任何它計劃發送的數據）以及請求數據的散列blob和私鑰結合來實現。
客戶端隨後將這個HASH以及所有它將要發送的參數和值一並發給伺服器。
伺服器接到請求，並使用與客戶端相同的方式重新生成自己獨有的基於提交值的HMAC（哈希）。
然後，伺服器比較這兩個HMAC，如果相同，伺服器就信任這個客戶端並執行請求。
這似乎很直截了當。最初讓你困惑的是，你以為原始請求是經過加密傳送的，但實際上，HMAC方法所做的一切只是使用只有客戶端和伺服器才知道的私鑰將參數生成為一些獨特的校驗和（哈希）。
隨後，客戶端將這個校驗和及原始參數和值發給伺服器，然後伺服器復核校驗和（哈希）以確定它接受客戶端所發的請求。
因為根據假設，只有在客戶端和伺服器知道私鑰，我們假設如果他們的哈希匹配，那麼它們會互相信任，以至伺服器隨即正常處理這個請求。
你知道在現實中，這就相當於某人過來對你說：「Jimmy讓我告訴你把錢給Johnny」，但你不知道這個人是誰，所以你要伸出手去試探他，看看他是否知道這個秘密握手。
如果三次握手證明無誤，則通訊繼續進行，否則中斷通訊。.

你明白了大概是怎麼回事，但還是想會不會還有更好的方法呢？還好，有tarsnap網站 tarsnap幫你答疑解惑。看看亞馬遜是如何解決簽名認證問題的Amazon screwed this up with Signature Version 1.
看完了亞馬遜的web service是如何鑒權的，re-read how Amazon Web Services does authentication 講的確實有道理，整個流程如下:
[客戶端]在調用REST API之前，首先將待發送消息體打包, combine a bunch of unique data together(websevice端將要接收的數據)

[客戶端]用系統分派的密鑰使用哈希(最好是HMAC-SHA1 or SHA256 ) 加密(第一步的數據).
[客戶端]向伺服器發送數據:

用戶身份認證信息例如,用戶ID，客戶ID或是其他能別用戶身份的信息。這是公共API，大家都能訪問的到(自然也包括了那些居心叵測的訪問者)系統僅僅需要這部分信息來區分發信人而不考慮可靠與否(當然可以通過HMAC來判斷可靠性).
發送生成的HMAC碼.
發送消息體（屬性名和屬性值），如果是私有信息需要加密，像是（「mode=start&number=4&order=desc」或其他不重要的信息）直接發送即可.
(可選項)避免重放攻擊 「replay attacks」 o的唯一辦法就是加上時間戳。在使用HMAC演算法時加入時間戳，這樣系統就能依據一定的條件去驗證是否有重放的請求並拒絕.
[伺服器端]接收客戶端發來的消息.
[伺服器端] (參看可選項)檢查接收時間和發送時間的間隔是否在允許范圍內（5-15分）以避免重放攻擊replay attacks.
提示: 確保待檢對象的時區無誤daylight savings time
更新: 最近得到的結論就是直接使用UTC時區而無需考慮DST的問題 use UTC time .
[伺服器端]使用發送請求中用戶信息（比如.API值）從資料庫檢索出對應的私匙.
[伺服器端] 跟客戶端相同，先將消息體打包然後用剛得到的私匙加密（生成HMAC）消息體.
(參看可選項) 如果你使用了加入時間戳的方式避免重放攻擊，請確保服務端生成的加密信息中擁有和客戶端相同的時間戳信息以避免中間人攻擊man-in-the-middle attack.
[伺服器端] 就像在客戶端一樣，使用HMAC哈希加密剛才的信息體.
[伺服器端] 將伺服器端剛生成的哈希與客戶端的對比。如果一致，則通訊繼續；否則，拒絕請求!
提示: 在打包消息體的時候一定要考慮清楚，如果像亞馬遜進行簽名版本1中信息識別那樣會面臨哈希沖突的問題 open yourself up to hash-collisions! (建議：將整個包含URL的請求加密即可!)
特別提示:私匙絕對不能在通訊過程中傳遞，它僅僅用來生成HMAC,伺服器端會自動查詢出它的私匙並重新生成自己的HMAC.我來翻譯公匙僅僅用來區分不同的用戶，即使被破解也無所謂。因為此時的消息無需判斷其可靠性，服務端和客戶端還是要通過私匙來加密（比如，前綴、後綴，倍數等等）
10/13/11更新：Chris最近發現 pointed out 如果在HMAC計算中加入了URI或是HTTP請求/回復，攻擊者更易通過更改末端或是HTTP方法來搞破壞。比如，在HTTP POST方法中將/issue/create改成/user/delete。

7. webapi與mvc兩個是共存關系還是單獨分別創建

在新出的MVC中，增加了WebAPI，用於提供REST風格的WebService，新生成的WebAPI項目和典型的MVC項目一樣，包含主要的Models、Views、Controllers等文件夾和Global.asax文件。Views對於WebAPI來說沒有太大的用途，Models中的Model主要用於保存Service和Client交互的對象，這些對象默認情況下會被轉換為Json格式的數據迚行傳輸，Controllers中的Controller對應於WebService來說是一個Resource，用於提供服務。和普通的MVC一樣，Global.asax用於配置路由規則。

8. WebAPI與傳統的WebService有哪些不同

在.net平台下，有大量的技術讓你創建一個HTTP服務，像Web Service，WCF，現在又出了Web API。在.net平台下，你有很多的選擇來構建一個HTTP Services。我分享一下我對Web Service、WCF以及Web API的看法。

Web Service

1、它是基於SOAP協議的，數據格式是XML

2、只支持HTTP協議

3、它不是開源的，但可以被任意一個了解XML的人使用

4、它只能部署在IIS上

WCF

1、這個也是基於SOAP的，數據格式是XML

2、這個是Web Service（ASMX）的進化版，可以支持各種各樣的協議，像TCP，HTTP，HTTPS，Named Pipes, MSMQ.

3、WCF的主要問題是，它配置起來特別的繁瑣

4、它不是開源的，但可以被任意一個了解XML的人使用

5、它可以部署應用程序中或者IIS上或者Windows服務中

WCF Rest

1、想使用WCF Rest service，你必須在WCF中使用webHttpBindings

2、它分別用[WebGet]和[WebInvoke]屬性，實現了HTTP的GET和POST動詞

3、要想使用其他的HTTP動詞，你需要在IIS中做一些配置，使.svc文件可以接受這些動詞的請求

4、使用WebGet通過參數傳輸數據，也需要配置。而且必須指定UriTemplate

5、它支持XML、JSON以及ATOM這些數據格式

Web API

1、這是一個簡單的構建HTTP服務的新框架

2、在.net平台上Web API 是一個開源的、理想的、構建REST-ful 服務的技術

3、不像WCF REST Service.它可以使用HTTP的全部特點（比如URIs、request/response頭，緩存，版本控制，多種內容格式）

4、它也支持MVC的特徵，像路由、控制器、action、filter、模型綁定、控制反轉（IOC）或依賴注入（DI），單元測試。這些可以使程序更簡單、更健壯

5、它可以部署在應用程序和IIS上

6、這是一個輕量級的框架，並且對限制帶寬的設備，比如智能手機等支持的很好

7、Response可以被Web API的MediaTypeFormatter轉換成Json、XML 或者任何你想轉換的格式。WCF和WEB API我該選擇哪個？

1、當你想創建一個支持消息、消息隊列、雙工通信的服務時，你應該選擇WCF

2、當你想創建一個服務，可以用更快速的傳輸通道時，像TCP、Named Pipes或者甚至是UDP（在WCF4.5中）,在其他傳輸通道不可用的時候也可以支持HTTP。

3、當你想創建一個基於HTTP的面向資源的服務並且可以使用HTTP的全部特徵時（比如URIs、request/response頭，緩存，版本控制，多種內容格式），你應該選擇Web API

4、當你想讓你的服務用於瀏覽器、手機、iPhone和平板電腦時，你應該選擇Web API

9. 《RESTfulWebAPIs中文版》pdf下載在線閱讀，求百度網盤雲資源

《RESTful Web APIs中文版》（[美] Leonard Richardson）電子書網盤下載免費在線閱讀

資源鏈接：

鏈接：https://pan..com/s/1qp0zgCAwGZ58v2DK2y1POQ

書名：RESTful Web APIs中文版

作者：[美] Leonard Richardson

譯者：李哲

豆瓣評分：6.8

出版社：電子工業出版社

出版年份：2014-6

頁數：382

內容簡介：

《RESTful Web APIs中文版》是針對RESTful API的實用指南，通過展示各種用來創建高可用應用的強大工具，講解REST的深層原理，以及介紹基於超媒體API的策略，使讀者得以在將上述內容融會貫通後，設計出讓客戶高度滿意的RESTful的web API。《RESTful Web APIs中文版》極具權威性與前瞻性，既代表了API領域的最前沿趨勢，也覆蓋了API領域的最重要實踐。

《RESTful Web APIs中文版》適合所有從事Web開發和架構工作的讀者閱讀參考。

作者簡介：

Leonard Richardson， 《Ruby Cookbook》 （O』Reilly）一書的作者，曾 創建了包括Beautiful Soup在內 的多個開源代碼庫。Mike Amundsen 是包括《Building Hypermedia APIs with HTML5 and Node》（O』Reilly） 在內的十幾本為人所稱道的技術圖書的作者。

Sam Ruby 是W3C HTML工作組的聯合主席，同時也是IBM新 興技術組的一名高級技術人員。

10. WebService和Webapi的區別

webapi用的是http協議，webservice用的是soap協議
webapi無狀態，相對webservice更輕量級。webapi支持如get,post等http操作
http soap關系
http:是一個客戶端和伺服器端請求和應答的標准（TCP）。http協議其目的是為了提供一種發布和接收htttp頁面的方法
一http協議的客戶端與伺服器的交互：由HTTP客戶端發起一個請求，建立一個到伺服器指定埠（默認是80埠）的TCP連接。HTTP伺服器則在那個埠監聽客戶端發送過來的請求。一旦收到請求，伺服器（向客戶端）發回一個狀態行，比如」HTTP/1.1 200 OK」，和（響應的）消息，消息的消息體可能是請求的文件、錯誤消息、或者其它一些信息。
soap 協議：它描述了一種在分散或分布式的環境中如何交換信息的輕量級協議。soap在http協議的基礎上，一個基於XML的協議。
不同：都是底層的通信協議，請求包的格式不同而已，soap包是XML格式,http純文本格式。
關系：SOAP是個通信協議， SOAP在HTTP協議的基礎上，把編寫成XML的REQUEST參數, 放在HTTP BODY上提交個WEB SERVICE伺服器(SERVLET，ASP什麼的) 處理完成後，結果也寫成XML作為RESPONSE送回用戶端， 為了使用戶端和WEB SERVICE可以相互對應，可以使用WSDL作為這種通信方式的描述文件，利用WSDL工具可以自動生成WS和用戶端的框架文件，SOAP具備把復雜對象序列化捆綁到XML里去的能力。

WCF和WEB API我該選擇哪個？
1、當你想創建一個支持消息、消息隊列、雙工通信的服務時，你應該選擇WCF
2、當你想創建一個服務，可以用更快速的傳輸通道時，像TCP、Named Pipes或者甚至是UDP（在WCF4.5中）,在其他傳輸通道不可用的時候也可以支持HTTP。
3、當你想創建一個基於HTTP的面向資源的服務並且可以使用HTTP的全部特徵時（比如URIs、request/response頭，緩存，版本控制，多種內容格式），你應該選擇Web API
4、當你想讓你的服務用於瀏覽器、手機、iPhone和平板電腦時，你應該選擇Web API
SOAP：Simple Object Access Protocol
簡單對象訪問協議（SOAP）是一種輕量的、簡單的、基於 XML 的協議，它被設計成在 WEB 上交換結構化的和固化的信息。 SOAP 可以和現存的許多網際網路協議和格式結合使用，包括超文本傳輸協議（ HTTP），簡單郵件傳輸協議（SMTP），多用途網際郵件擴充協議（MIME）。它還支持從消息系統到遠程過程調用（RPC）等大量的應用程序。
HTTP協議： 應用層
TCP協議 ： 傳輸層
HTTP協議詳解之響應篇
在接收和解釋請求消息後，伺服器返回一個HTTP響應消息。

HTTP響應也是由三個部分組成，分別是：狀態行、消息報頭、響應正文
1、狀態行格式如下：
HTTP-Version Status-Code Reason-Phrase CRLF
其中，HTTP-Version表示伺服器HTTP協議的版本；Status-Code表示伺服器發回的響應狀態代碼；Reason-Phrase表示狀態代碼的文本描述。
狀態代碼有三位數字組成，第一個數字定義了響應的類別，且有五種可能取值：
1xx：指示信息–表示請求已接收，繼續處理
2xx：成功–表示請求已被成功接收、理解、接受
3xx：重定向–要完成請求必須進行更進一步的操作
4xx：客戶端錯誤–請求有語法錯誤或請求無法實現
5xx：伺服器端錯誤–伺服器未能實現合法的請求
常見狀態代碼、狀態描述、說明：
200 OK //客戶端請求成功
400 Bad Request //客戶端請求有語法錯誤，不能被伺服器所理解
401 Unauthorized //請求未經授權，這個狀態代碼必須和WWW-Authenticate報頭域一起使用
403 Forbidden //伺服器收到請求，但是拒絕提供服務
404 Not Found //請求資源不存在，eg：輸入了錯誤的URL
500 Internal Server Error //伺服器發生不可預期的錯誤
503 Server Unavailable //伺服器當前不能處理客戶端的請求，一段時間後可能恢復正常
eg：HTTP/1.1 200 OK （CRLF）
2、響應報頭後述
3、響應正文就是伺服器返回的資源的內容