ASP.NET WebAPI 사전 지식: HTTP 및 RestfulAPI

        HTTP 프로토콜에 대한 기본적인 이해는 RestFul 스타일 API를 이해하고 사용하기 위한 기초입니다. 이러한 기본 사항을 이해한 후 다양한 RestFul 개발 프레임워크를 사용하세요. 당신은 편리할 수 있습니다. WebApi를 처음 사용하기 시작했을 때 이러한 지식에 대한 이해가 부족하여 사용하기가 불편하다고 느꼈지만, 이러한 HTTP 지식을 익히고 나서야 WebApi를 사용하여 개발하는 것이 편해졌습니다. RestFul 스타일 API는 HTTP 프로토콜을 잘 지원하고 HTTP의 완전한 의미 스타일을 구현하는 API입니다.

이 지식을 소개하기 전에 많은 사람들이 오해하고 있는 HTTP 조건부 및 데이터 전송 방법에 대해 강조하고 싶습니다. 대부분의 사람들이 접하고 사용하는 HTTP 프로토콜은 웹 사이트를 작성하는 과정에서 일반적으로 WEB 응용 프로그램에서는 GET 및 POST 두 가지 조건만 사용하며 다른 조건은 적용되지 않습니다. 이상한 인식: HTTP 프로토콜은 웹사이트 개발에만 적합합니다. HTTP 호출 데이터 전송은 K-V 형식으로만 수행됩니다. 이 인식 하에서 RestApi는 설명이 없는 경우가 많습니다. ASP.NET WebAPi를 사용하는 경우에도 설명이 없는 것처럼 나타나 문제가 발생합니다. 먼저 웹 사이트에서의 데이터 상호 작용은 HTTP 사용의 한 시나리오일 뿐이며 HTTP는 다양한 형태의 데이터를 전송할 수 있다는 점을 인식해야 합니다.

HTTP의 첫 번째 줄부터 시작합니다. HTTP의 첫 번째 줄에는 조건자, URL, HTTP 프로토콜 버전의 세 가지 정보가 포함됩니다. 세 개의 데이터는 공백으로 구분됩니다.

조건자: 조건자는 RestFul API의 매우 중요한 요소입니다. WEB API는 조건자를 기본 라우팅 방법으로 사용합니다. 가장 일반적으로 사용되는 조건자는 POSTDELETEPUTGET입니다. , 이 네 가지 술어는 "추가, 삭제, 수정, 확인"의 네 가지 작업에 해당합니다(POST 및 PUT은 서로 다른 데이터를 추가하고 수정하는 데 사용됩니다. 항상 다른 의견이 있습니다. 사실 조금 혼란스럽습니다... 네 정의에 따르면 PUT는 멱등성 작업이지만 POST는 그렇지 않으므로 PUT은 변경 사항에 더 중점을 두고 POST는 증가에 더 중점을 둡니다. 가장 일반적으로 사용되는 술어는 이 네 가지이며, 다른 의미를 갖는 다른 술어도 있습니다:

HEAD: Body를 제외하고 해당 헤더만 반환

TRACE: 예 진단 데이터 전송 프로세스

OPTIONS: 웹 서버가 지원하는 다양한 기능을 알려주도록 요청

필요한 경우 관련 문서를 쿼리 할 수 있습니다. 일반적으로 사용되지 않음.

그 중 GET과 DELETE는 BODY를 포함하지 않으며, PUT과 POST는 BODY를 포함할 수 있습니다. 그리고 조건자에 BODY를 사용한 GET과 같은 의미 체계 외부의 작업이 포함된 경우 POST는 리소스를 삭제하는 데 사용되며 이 작업도 허용되며 조건자의 오버로딩이라고 합니다. , HTTP는 조건자 오버로드를 지원할 수 있지만 표준 의미 체계를 준수하지 않으므로 사용하지 않는 것이 좋습니다.

URL: URL은 리소스를 정의합니다. 예를 들어 www.example.com/person은 person을 리소스로 정의합니다. 위에서 소개한 조건자와 결합하여 Person을 제공합니다. 작업 집합:

GET www.example/person/1을 사용하여 ID 1의 사용자 정보 가져오기

POST www.example/person/(BODY 개인의 설명 포함) 개인 리소스 생성

PUT www.example/person/1 (BODY에는 개인의 설명 포함) 업데이트개인 리소스

.1 프로토콜인 HTTP2.0 프로토콜은 대중화 단계에 있으며 아직 많이 사용되지 않습니다. HTTP1.0과 HTTP1.1의 차이는 매우 작으며, 그 차이가 RestFul에 큰 영향을 미치지 않습니다. 구체적인 차이점은 관련 문서를 확인하실 수 있습니다.

 

이것은 HTTP의 첫 번째 줄입니다. 다음은 줄을 바꾸는 rn이 있습니다. 다음은 HTTP 요청과 응답을 설명하는 HTTP HEAD 부분입니다. HTTP HEAD는 HTTP 프로토콜에서 가장 중요한 부분이라고 생각합니다. 여기에는 인코딩, BODY 길이, 콘텐츠 협상 등과 같은 정보가 포함되어 있습니다. 일부 사용자 정의 정보도 포함할 수 있습니다. RestFul API에서 일반적으로 사용되는 몇 가지 HEAD를 소개하겠습니다.

User-Agent: 사용자 에이전트, 클라이언트가 요청하는 IE, Chrome, Fid dl 등 er, etc.

HOST: 도메인 이름(HOST는 일반적으로 서버의 사이트 바인딩에 사용됩니다. 일반적으로 URL의 도메인 이름과 동일하지만 일부 사용자 정의된 DNS 사용에서는 나타날 수 있습니다. HOST와 URL의 도메인 이름이 일치하지 않습니다.)

권한: 확인 정보, 이 필드는 사용자 확인을 위한 일부 정보를 포함할 수 있으며 표시 방법은 다음과 같습니다. 스키마 작성자 정보, 공백으로 구분, 여기서 스키마는 확인을 나타냅니다. 메소드, Authorinfo는 검증 정보, Base와 같은 공통 스키마를 나타냅니다. Authorinfo는 사용자 이름 + 비밀번호를 사용하며 Base64로 인코딩됩니다. 또는 세션과 유사한 토큰을 사용하세요.

수락: 응답 데이터의 내용 협상에 사용되는 MIME으로 표현된 반환된 데이터를 수락하는 직렬화 방법은 여러 MIME을 포함할 수 있으며 application/json과 같이 우선순위에 따라 정렬됩니다., application/xml, text/html; 서버가 반환할 수 있는 특정 유형의 데이터는 서버 지원에 따라 다릅니다. 때로는 사용자 정의된 MIME이 필요할 수도 있습니다. bson, 프로토콜 버퍼 등과 같은 MIME을 사용자 정의하고 서버 측에서 자체 구현을 개발할 수 있으며 이러한 특수 확장에는 ASP.NET WebApi에 해당 확장 지점이 있습니다.

Content-Type: MIME 표현을 사용하여 전송된 요청 본문의 직렬화 방법을 나타냅니다. 일반적인 표현은 application/json과 가장 일반적으로 사용되는 application/x-www-입니다. m-urlencoded의 WEB 상호작용에서는 둘 다 요청과 응답에 나타나는 본문 부분의 직렬화 방법을 나타냅니다.

제 생각에는 HTTP HEAD 부분이 HTTP 프로토콜의 핵심입니다. 구성하고 사용할 수 있는 부분이 너무 많고, 세부 사항도 너무 많습니다. 위 내용은 제 작업에서 가장 일반적으로 사용되는 부분입니다. 이 내용을 모두 소개하면 충분합니다. 이 책은 나와 있습니다. 관심이 있으시면 관련 정보를 찾을 수 있습니다. Rest API에서 콘텐츠 협상은 처음에 Rest를 사용하는 사람들을 혼동하는 경우가 많습니다. 헤더 Accept 및 Content-Type은 어떤 종류의 데이터가 허용되는지를 나타냅니다. Content-Type은 현재 요청에서 Body의 인코딩 방법을 나타냅니다. ASP.NET WEBAPI에서 요청에 Content-Type이 있지만 ACCEPT가 없으면 기본적으로 Content-Type의 콘텐츠가 응답에 대한 콘텐츠 협상으로 사용됩니다.

 

응답 부분도 헤더와 본문으로 구분됩니다. 응답 헤더와 요청 헤더의 가장 큰 차이점은 응답의 첫 번째 줄에 HTTP 코드가 있다는 점과, HTTP 코드는 API 호출로 사용됩니다 상태 표시도 매우 중요합니다. REST API에서 가장 일반적으로 사용되는 상태 코드는 일반적으로 2XX, 4XX 및 5XX의 세 세그먼트입니다. .1XX는 작업이 계속됨을 의미하고 3XX는 일반적으로 REST API에서 많이 사용되지 않는 리디렉션을 의미합니다. 가장 일반적으로 사용되는 세 가지 상태 세그먼트 중 2XX는 성공적인 실행을 나타내고, 4XX는 클라이언트 데이터 오류(예: 매개변수 확인 실패)를 나타내며, 5XX는 처리되지 않은 예외(예: 데이터베이스 연결 오류)와 같은 서버 측 처리 오류를 나타냅니다. 이러한 상태 코드를 통해 API 호출의 실행 상태를 초기에 판단할 수 있습니다.

 

헤더 뒤에 빈 줄(rn)이 있고 그 뒤에 Content가 있습니다. 여기에는 JSON, XML, 심지어 HTML과 같은 다양한 콘텐츠 유형에 따라 다양한 직렬화 방법으로 표시되는 특정 비즈니스 데이터가 있습니다. HTTP API를 배우면 웹 애플리케이션도 HTTP의 애플리케이션이라고 생각할 수 있지만, 상호 작용 방식은 일반적으로 요청으로 application/x-www-form-urlencoded를 사용하고 응답으로 text/html을 사용합니다. RestAPI는 다른 많은 코딩 방법과 상호 작용할 수 있으며 더 폭넓은 지원을 제공합니다. 웹 애플리케이션은 단지 HTTP 전송을 사용하는 애플리케이션 시나리오일 뿐이며 웹 페이지는 분리될 수 없습니다. 내 생각에 Nancy는 ASP.NET보다 이 작업을 더 잘한다고 생각합니다. Nancy는 RestAPI를 웹 페이지에서 분리하지 않는 반면 ASP.NET은 MVC 및 WEBAPI를 사용하여 둘을 분리합니다. application/json일 때 Json 데이터를 반환하고 text/html이 사용될 때 웹 페이지를 반환하려면 물론 이 두 가지 응용 프로그램 방법을 자르거나 병합하는 것은 나름의 장점과 단점이 있습니다.

제가 작성한 내용은 HTTP 프로토콜에 비해 너무 적습니다. 관심이 있으신 분은 WEB API에서 자주 사용되는 부분만 적어 두시면 됩니다. 이 지식:

위 내용은 ASP.NET WebAPI 사전 지식: HTTP 및 RestfulAPI의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!