1. 程式人生 > >使用ASP.NET Core 3.x 構建 RESTful API - 3.3 狀態碼、錯誤/故障、ProblemDetails

使用ASP.NET Core 3.x 構建 RESTful API - 3.3 狀態碼、錯誤/故障、ProblemDetails

HTTP狀態碼

HTTP狀態碼會告訴API的消費者以下事情: 

  • 請求是否執行成功了 

  • 如果請求失敗了,那麼誰為它負責 

 

HTTP的狀態碼有很多,但是Web API不一定需要支援所有的狀態碼。HTTP狀態碼一共分為5個級別: 

  • 1xx,屬於資訊性的狀態碼。Web API並不使用1xx的狀態碼。 

  • 2xx,意味著請求執行的很成功。 

    • 200 - Ok,表示請求成功; 

    • 201 - Created,請求成功並建立了資源; 

    • 204 - No Content,請求成功,但是不應該返回任何東西,例如刪除操作。 

  • 3xx,用於跳轉。例如告訴搜素引擎,某個頁面的網址已經永久的改變了。絕大多數的Web API都不需要使用這類狀態碼。 

  • 4xx,客戶端錯誤: 

    • 400 - Bad Request,表示API消費者傳送到伺服器的請求是有錯誤的; 

    • 401 - Unauthorized,表示沒有提供授權資訊或者提供的授權資訊不正確; 

    • 403 - Forbidden,表示身份認證已經成功,但是已認證的使用者卻無法訪問請求的資源; 

    • 404 - Not Found,表示請求的資源不存在; 

    • 405 - Method not allowed,當嘗試傳送請求到資源的時候,使用了不被支援的HTTP方法時,就會返回405狀態碼; 

    • 406 - Not acceptable,這表示API消費者請求的表述格式並不被Web API所支援,並且API不會提供預設的表述格式。例如請求的媒體型別是application/xml,但是Web API僅支援application/json型別,並且API不會將application/json作為預設格式提供; 

    • 409 - Conflict,表示請求與伺服器當前狀態衝突。通常指更新資源時發生的衝突,例如,當你編輯某個資源的時候,該資源在伺服器上又進行了更新,所以你編輯的資源版本和伺服器的不一致。當然有時候也用來表示你想要建立的資源在伺服器上已經存在了。它就是用來處理併發問題的狀態碼。  

    • 415 - Unsupported media type,與406正好相反,有一些請求必須帶著資料發往伺服器,這些資料都屬於特定的媒體型別,如果API不支援該媒體型別格式,415就會被返回。 

    • 422 - Unprocessable entity,它是HTTP擴充套件協議的一部分。它說明伺服器已經懂得了實體的Content Type,也就是說415狀態碼肯定不合適;此外,實體的語法也沒有問題,所以400也不合適。但是伺服器仍然無法處理這個實體資料,這時就可以返回422。所以它通常是用來表示語意上有錯誤,通常就表示實體驗證的錯誤。 

  • 5xx,伺服器錯誤: 

    • 500 - Internal server error,表示伺服器出現了錯誤,客戶端無能為力,只能以後再試試了。 

 

錯誤和故障

系統時不時的會出現一些問題,這些問題可以劃分為兩類:錯誤和故障。 

 

錯誤 Errors 

錯誤通常是由API的消費者引起的。API消費者請求時傳遞的資料是不合理的,這時API就會正常的將其拒絕。例如,請求的憑證是不合理的,或者請求的引數不合理等等。  

這些就是HTTP  4xx錯誤。  

錯誤並不會影響API的可用性。 

 

故障 Faults 

故障是指,針對一個合理的請求,API無法返回它的響應。 換句話說就是API引起的問題。 

這些是HTTP 5xx錯誤。 

故障確實會對API整體的可用性造成影響。 

 

ProblemDetails

當ASP.NET Core 大約在 2.1 版本的時候,它引入了 ProblemDetails。ProblemDetails是基於 RFC7807 這個規範,目的是讓 HTTP 響應可以攜帶錯誤的詳細資訊,而不是隻返回一個錯誤的狀態碼。 

在 ASP.NET Core 2.2的時候,如果Controller使用了 [ApiController] 這個屬性,那麼 ProblemDetails 就是客戶端錯誤碼的標準響應。 

例如,當返回型別為 IActionResult 的方法返回客戶端錯誤狀態碼的時候(4xx),同時還會返回一個body,這個 body 就是 ProblemDetails。 這個結果裡還會包含著一個相關的ID,使用這個ID,就可以把錯誤和相應的請求日誌關聯起來。 

 

關於ProblemDetails這個類,可以檢視:官方文件。 

 

為了使用ProblemDetails? 

  • 需要為應用程式定義一個通用的錯誤顯示格式; 

  • 很多時候,只返回HTTP狀態碼並不能表達和傳遞出足夠的資訊。 

 

在ASP.NET Core 3.x裡面,同樣也使用了 ProblemDetails。 

看一個返回404的例子: 

這是一個Get請求,但是並沒有找到該資源,返回的狀態碼是404,而響應的body就是 ProblemDetails。 

值得注意的是,這個響應的 Content-Type 是 application/problem+json: 

相關推薦

使用ASP.NET Core 3.x 構建 RESTful API - 4.3 HTTP 方法的安全性和冪等性

什麼樣的HTTP方法是安全的?  如果一個方法不會改變資源的表述,那麼這個方法就被認為是安全的。  例如 HTTP GET 和 HTTP HEAD 就被認為是安全的,但需要注意的是,這並不意味著執行GET請求就不會引起其它的資

使用ASP.NET Core 3.x 構建 RESTful API - 3.3 狀態錯誤/故障ProblemDetails

HTTP狀態碼 HTTP狀態碼會告訴API的消費者以下事情:  請求是否執行成功了  如果請求失敗了,那麼誰為它負責    HTTP的狀態碼有很多,但是Web API不一定需要支援所有的狀態碼。HTTP狀態碼一共分為5個級別: 

使用 .NET Core 3.x 構建 RESTFUL Api

準備工作:在此之前你需要了解關於.NET .Core的基礎,前面幾篇文章已經介紹:https://www.cnblogs.com/hcyesdo/p/12834345.html 首先需要明確一點的就是REST Api它不是一個標準,而是一種架構風格 什麼是WebApi? WebApi通常是指“使用HTTP協議

使用 .NET Core 3.x 構建 RESTFUL Api (續)

關於Entity Model vs 面向外部的Model Entity Framework Core 使用 Entity Model 用來表示資料庫裡面的記錄。 面向外部的Model 則表示要傳輸的東西,有時候被稱為 Dto,有時候被稱為 ViewModel。 關於Dto,API消費者通過Dto,僅提供給使用

使用 .NET Core 3.x 構建RESTful Api(第三部分)

關於HTTP HEAD 和 HTTP GET: 從執行效能來說,這兩種其實並沒有什麼區別。最大的不同就是對於HTTP HEAD 來說,Api消費者請求介面資料時,如果是通過HTTP HEAD的方式去請求, 應該是不會把 Body返回回去的。那麼它會返回什麼呢? 比如說,Headers的一些響應頭資料,例如Co

ASP.NET Core MVC中構建簡單 Web Api

程序 Getting Started在 ASP.NET Core MVC 框架中,ASP.NET 團隊為我們提供了一整套的用於構建一個 Web 中的各種部分所需的套件,那麽有些時候我們只需要做一個簡單的 Web Api 程序怎麽辦呢?在 GitHub 中的 ASP.NET Core MVC 源碼裏面,我

使用靜態基類方案讓 ASP.NET Core 實現遵循 HATEOAS Restful Web API

以及 acc repo pri == single partially context 繼承 Hypermedia As The Engine Of Application State (HATEOAS) HATEOAS(Hypermedia as the engi

ASP.NET Core 實戰:構建帶有版本控制的 API 接口

uil 早已 請求參數 想要 cin 可選 true ora documents 一、前言   在上一篇的文章中,主要是搭建了我們的開發環境,同時創建了我們的項目模板框架。在整個前後端分離的項目中,後端的 API 接口至關重要,它是前端與後端之間進行溝通的媒介,如何構

ASP.NET Core 實戰:構建帶有版本控制的 API 介面

 一、前言    在上一篇的文章中,主要是搭建了我們的開發環境,同時建立了我們的專案模板框架。在整個前後端分離的專案中,後端的 API 介面至關重要,它是前端與後端之間進行溝通的媒介,如何構建一個 “好用” 的 API 介面,是需要我們後端人員好好思考的。  在系統迭代的整個過程中,不可

ASP.NET Core】從向 Web API 提交純文本內容談起

文本 .text prot 實例 out 示例 問題 img anr 前些時日,老周在升級“華南閑腎回收登記平臺”時,為了擴展業務,尤其是允許其他開發人員在其他平臺向本系統提交有關腎的介紹資料,於是就為該系統增加了幾個 Web API。 其中,有關

發布 ASP.NET Core 2.x 應用到 Ubuntu

bsp 返回 proxy 地址 direct color rev 默認 info 簡單紹一下如何將ASP.NET Core 應用發布到Linux (Ubuntu)服務器上,都是文檔的東西。 服務器結構 ASP.NET Core 2.x 有兩種server:

Asp.net core 2.0 的Web Api 新增logging

我們已經熟悉在ASP.NET CORE專案中新增NLog去記錄我們的日誌。但方法移到web API中行不通。我簡歷記錄下我加的方法。     1. Nuget 加 NLog.Web.AspNetCore     2. 加引用 usi

ASP.NET Core 2.x中獲取客戶端IP地址

一、前言 大家也知道服務端請求時我們獲取的IP地址是包含在請求頭中,因此這也大大便利了IP的獲取。 在ASP.NET中,可以通過以下方式獲取客戶端的IP地址。 HttpContext.Current.Request.ServerVariables["HTTP_X_FORWARDED_FOR"]

釋出 ASP.NET Core 2.x 應用到 Ubuntu

簡單紹一下如何將ASP.NET Core 應用釋出到Linux (Ubuntu)伺服器上,都是文件的東西。 伺服器結構 ASP.NET Core 2.x 有兩種server: HTTP.sys 只支援Windows,並支援一些Windows獨有的特性。 Kestrel,跨平臺的伺服器,高度優化

ASP.NET Core 入門教程 2使用ASP.NET Core MVC框架構建Web應用

一、前言 1、本文主要內容 使用dotnet cli建立基於解決方案(sln+csproj)的專案 使用Visual Studio Code開發基於解決方案(sln+csproj)的專案 Visual Studio Code Solution外掛( vscode-solution-explorer)基礎使用

ASP.NET core webapi RouteAttribute _平臺:windows (3)

ASP.NET core webapi RouteAttribute _平臺:windows (3) 簡版(後面還有囉嗦版本 點我進入囉嗦版本): 問題: 1、介紹RouteAttribute特性。 這個東西其實很簡單:主要用處就是設定路由罷了 什麼?不懂路由是什麼? 那麼你就理

ASP.NET Core的身份認證框架IdentityServer4(3)-術語的解釋

IdentityServer4 術語 IdentityServer4的規範、文件和物件模型使用了一些你應該瞭解的術語。 身份認證伺服器(IdentityServer) IdentityServer是一個OpenID Connect提供程式,它實現了OpenID Connect 和 OAuth 2.0 協議。

ABP框架(asp.net core 2.X+Vue)模板專案學習之路(一)

      前言:   第一次接觸ABP的專案是在2018年6月份,但是當時沒有深入具體的研究,而今天因為工作的需要,需要學習、瞭解這個框架,在時隔半年之後,今天重新下載了這個專案,雖然在園子裡有很多前輩們寫的這類的文章,但是我還是會在部落格園中記錄一下學習的過程,一是希

DevExpress ASP.NET Core Controls 2019發展藍圖(No.3)

藍圖 java 渲染 自動 加載 顏色 增強功能 選項 使用 本文主要為大家介紹DevExpress ASP.NET Core Controls 2019年的官方發展藍圖,更多精彩內容歡迎持續收藏關註哦~ 【DevExpress ASP.NET Controls 下載】

Asp.Net Core WebAPI使用Swagger時API隱藏與分組

sum pro build 程序集 cto fse 區分 分組 odi 原文:Asp.Net Core WebAPI使用Swagger時API隱藏與分組1、前言 為什麽我們要隱藏部分接口? 因為我們在用swagger代替接口的時候,難免有些接口會直觀的暴露出來,比如我們