ASP.NET webapi Interview Questions
1.0.0
프로젝트가 마음에 들면 클릭하세요. Pull Request는 높이 평가됩니다. 기술 업데이트를 받으려면 @kansiris87을 팔로우하세요.
| 아니요. | 질문 |
|---|---|
| 1 | [REST란 무엇인가요?](#REST란 무엇인가요?) |
| 2 | [REST 원리를 설명하시겠습니까?](#REST 원리를 설명하시겠습니까?) |
| 3 | [REST와 SOAP의 차이점은 무엇인가요?](#REST와 SOAP의 차이점은 무엇인가요?) |
| 4 | [ASP.NET WEB API란 무엇인가요?](#ASP.NET WEB API란 무엇인가요?) |
| 5 | [ASP.NET WEB API를 선택하는 이유는 무엇입니까?](#ASP.NET WEB API를 선택하는 이유는 무엇입니까?) |
| 6 | [WCF와 ASP.NET WEB API, WCF REST와 웹 서비스의 차이점은 무엇입니까?](#WCF와 ASP.NET WEB API, WCF REST와 웹 서비스의 차이점은 무엇입니까?) |
| 7 | [WCF와 WEB API 중 무엇을 선택할 것인가?](#WCF와 WEB API 중 어느 것을 선택할 것인가?) |
| 8 | [ASP.NET MVC와 ASP.NET WEB API의 차이점은 무엇인가요?](#HASP.NET MVC와 ASP.NET WEB API의 차이점은 무엇인가요?) |
| 9 | [WEB API 방식으로 뷰를 반환할 수 있나요?](#WEB API 방식을 사용하여 뷰를 반환할 수 있나요?) |
| 10 | [ASP.NET MVC처럼 WEB API 액션 이름을 변경할 수 있나요?](#ASP.NET MVC처럼 WEB API 액션 이름을 변경할 수 있나요?) |
|1 | [WEB API 작업 메서드가 HTTP GET, POST, PUT 또는 DELETE로만 호출되도록 제한할 수 있나요?](#WEB API 작업 메서드가 HTTP GET, POST, PUT 또는 DELETE로만 호출되도록 제한할 수 있나요?)| |2 | [ASP.NET MVC에서 WEB API를 어떻게 호출하나요?](#ASP.NET MVC에서 WEB API를 어떻게 호출하나요?)| |3 | [ASP.NET API 라우팅은 ASP.NET MVC 라우팅과 어떻게 다른가요?](#ASP.NET API 라우팅은 ASP.NET MVC 라우팅과 어떻게 다른가요?)| |4 | [ASP.NET WEB API2에서 속성 라우팅을 활성화하는 방법은 무엇입니까?](#ASP.NET WEB API2에서 속성 라우팅을 활성화하는 방법은 무엇입니까?)| |5 | [ASP.NET WEB API2에서 어떻게 속성 라우팅을 정의하나요?](#ASP.NET WEB API2에서 어떻게 속성 라우팅을 정의하나요?)|
REST는 표현 상태 전송(Representational State Transfer)을 의미합니다. 분산 환경에서 데이터를 교환하기 위한 프로토콜입니다. REST는 각 서비스를 리소스로 취급하고 GET, POST, PUT 및 DELETE와 같은 HTTP 프로토콜 방법으로 데이터에 액세스하는 아키텍처 스타일입니다.
REST 스타일 아키텍처는 클라이언트와 서버로 구성됩니다. 클라이언트는 이러한 요청을 처리하는 서버에 요청을 시작하고 이러한 요청에 따라 응답을 반환합니다. 이러한 요청과 응답은 이러한 리소스의 표현 전송을 중심으로 구축됩니다.
REST는 HTTP 및 URI와 같은 웹 표준이 사용되는 방식을 정의하는 일련의 원칙입니다. 아래와 같이 다섯 가지 중요한 REST 원칙이 있습니다.
주소 지정 가능한 리소스 - 각 리소스는 URI(고유 식별자)로 식별되어야 합니다.
단순하고 균일한 인터페이스 - REST는 HTTP 프로토콜을 기반으로 하므로 HTTP GET, POST, PUT 및 DELETE 메서드를 사용하여 작업을 수행합니다. 이는 REST를 단순하고 균일하게 만듭니다.
표현 지향 - 자원의 표현이 교환됩니다. GET은 표현을 반환하는 데 사용되며 PUT, POST는 기본 리소스가 변경될 수 있도록 표현을 서버에 전달합니다. 표현은 XML, JSON 등과 같은 다양한 형식일 수 있습니다.
무상태 통신 - 애플리케이션에 상태가 있을 수 있지만 서버에 저장된 클라이언트 세션 데이터가 없습니다. 모든 세션별 데이터는 클라이언트가 보유 및 유지 관리해야 하며 필요에 따라 각 요청과 함께 서버로 전송되어야 합니다.
캐시 가능 - 클라이언트는 향후 사용을 위해 응답을 캐시할 수 있어야 합니다.
REST와 SOAP의 차이점은 다음과 같습니다. SOAP REST SOAP는 Simple Object Access Protocol을 의미합니다. REST는 REpresentational State Transfer를 의미합니다. HTTP 또는 때로는 TCP/IP, SMTP 위에 구축된 XML 기반 프로토콜입니다. REST는 프로토콜은 아니지만 아키텍처 스타일 즉 리소스 기반 아키텍처입니다. SOAP에는 상태 비저장 및 상태 저장 구현에 대한 사양이 있습니다. REST는 완전히 상태 비저장입니다. SOAP는 메시지 형식을 XML로 적용합니다. REST는 메시지 형식을 XML 또는 JSON으로 적용하지 않습니다. SOAP에는 정의된 표준 사양이 있습니다. 예를 들어 WS-Security는 보안을 구현하기 위한 사양입니다. 정의된 표준 사양이 없습니다. SOAP 메시지는 보내려는 실제 정보를 저장하기 위한 SOAP 헤더와 본문을 포함하는 봉투로 구성됩니다. REST는 HTTP 내장 헤더(다양한 미디어 유형 포함)를 사용하여 메타 정보를 전달하고 GET, POST, PUT 및 DELETE 동사를 사용하여 CRUD 작업을 수행합니다. SOAP는 인터페이스와 명명된 작업을 사용하여 서비스를 노출합니다. REST는 URI와 (GET, PUT, POST, DELETE) 같은 메서드를 사용하여 리소스를 노출합니다. REST에 비해 성능이 느립니다. REST는 SOAP에 비해 빠릅니다.
ASP.NET WEB API는 브라우저, 모바일, iPhone 및 태블릿을 포함한 광범위한 클라이언트에서 사용할 수 있는 HTTP 서비스를 구축하기 위한 프레임워크입니다. 라우팅, 컨트롤러, 작업 결과, 필터, 모델 바인더, IOC 컨테이너 또는 종속성 주입과 같은 MVC 기능이 포함되어 있다는 점에서 ASP.NET MVC와 매우 유사합니다. 그러나 이는 MVC 프레임워크의 일부가 아닙니다. 이는 핵심 ASP.NET 플랫폼의 일부이며 MVC 및 ASP.NET WebForms와 같은 다른 유형의 웹 응용 프로그램과 함께 사용할 수 있습니다. 독립형 웹 서비스 애플리케이션으로도 사용할 수 있습니다. ASP.NET WEB API 기능 1. HTTP 동사 GET, POST, PUT 및 DELETE와 함께 작동하므로 규칙 기반 CRUD 작업을 지원합니다. 2. 응답에는 Accept 헤더와 HTTP 상태 코드가 있습니다. 3. 응답은 WEB API의 MediaTypeFormatter에 의해 JSON, XML 또는 MediaTypeFormatter로 추가하려는 형식으로 형식화됩니다. 4. 이미지, PDF 파일 등과 같이 객체 지향적이지 않은 콘텐츠를 수용하고 생성할 수 있습니다. 5. OData를 자동으로 지원합니다. 따라서 IQueryable을 반환하는 컨트롤러 메서드에 새 [Queryable] 특성을 배치하면 클라이언트는 OData 쿼리 구성에 해당 메서드를 사용할 수 있습니다. 6. 애플리케이션이나 IIS에서 호스팅할 수 있습니다. 7. 또한 라우팅, 컨트롤러, 작업 결과, 필터, 모델 바인더, IOC 컨테이너 또는 종속성 주입과 같은 MVC 기능을 지원하여 더욱 간단하고 강력해집니다.
오늘날 웹 기반 애플리케이션만으로는 고객에게 다가가기에 충분하지 않습니다. 사람들은 매우 똑똑하며 일상 생활에서 아이폰, 모바일, 태블릿 등의 장치를 사용하고 있습니다. 이러한 장치에는 생활을 편리하게 해주는 많은 앱도 있습니다. 실제로 우리는 웹에서 앱 세계로 이동하고 있습니다.
따라서 빠르고 간단한 방법으로 서비스 데이터를 브라우저와 모든 최신 장치 앱에 노출하려면 브라우저 및 모든 장치와 호환되는 API가 있어야 합니다.
예를 들어 웹 애플리케이션과 전화 앱을 위한 트위터, 페이스북, Google API가 있습니다.
WEB API는 데이터와 서비스를 다양한 장치에 노출하기 위한 훌륭한 프레임워크입니다. 또한 WEB API는 .NET Framework를 통해 REST-ful 서비스를 구축하기 위한 이상적인 플랫폼인 오픈 소스입니다. WCF Rest 서비스와 달리 HTTP의 모든 기능(예: URI, 요청/응답 헤더, 캐싱, 버전 관리, 다양한 콘텐츠 형식)을 사용하며 WCF Rest 서비스와 달리 다양한 장치에 대한 추가 구성 설정을 정의할 필요가 없습니다.
웹 서비스는 필요하고 SOAP는 필요하지 않은 경우 ASP.NET WEB API가 최선의 선택입니다.
기존 WCF 메시지 파이프라인 위에 SOAP 기반이 아닌 간단한 HTTP 서비스를 구축하는 데 사용됩니다.
WCF REST 서비스처럼 지루하고 광범위한 구성이 없습니다.
WEB API를 이용한 간단한 서비스 생성. WCF REST 서비스를 사용하면 서비스 생성이 어렵습니다.
HTTP만을 기반으로 하며 REST 방식으로 쉽게 정의, 노출 및 소비할 수 있습니다.
경량 아키텍처이며 스마트폰과 같이 대역폭이 제한된 장치에 적합합니다.
오픈 소스입니다.
.NET Framework에는 웹 서비스, WCF 및 WEB API와 같은 HTTP 서비스를 생성할 수 있는 다양한 기술이 있습니다. 이 네 가지에는 다음과 같은 차이점이 있습니다.
웹 서비스
SOAP를 기반으로 하며 XML 형식으로 데이터를 반환합니다.
HTTP 프로토콜만 지원합니다.
오픈 소스는 아니지만 xml을 이해하는 모든 클라이언트에서 사용할 수 있습니다.
IIS에서만 호스팅할 수 있습니다.
WCF
또한 SOAP를 기반으로 하며 XML 형식으로 데이터를 반환합니다.
이는 웹 서비스(ASMX)의 발전이며 TCP, HTTP, HTTPS, 명명된 파이프, MSMQ와 같은 다양한 프로토콜을 지원합니다.
WCF의 주요 문제는 지루하고 광범위한 구성입니다.
오픈 소스는 아니지만 xml을 이해하는 모든 클라이언트에서 사용할 수 있습니다.
응용 프로그램이나 IIS 또는 창 서비스를 사용하여 호스팅할 수 있습니다.
WCF 휴식
WCF를 WCF Rest 서비스로 사용하려면 webHttpBindings를 활성화해야 합니다.
각각 [WebGet] 및 [WebInvoke] 속성을 통해 HTTP GET 및 POST 동사를 지원합니다.
다른 HTTP 동사를 활성화하려면 .svc 파일에서 해당 특정 동사의 요청을 수락하도록 IIS에서 일부 구성을 수행해야 합니다.
WebGet을 사용하여 매개변수를 통해 데이터를 전달하려면 구성이 필요합니다. UriTemplate을 지정해야 합니다.
XML, JSON 및 ATOM 데이터 형식을 지원합니다.
웹 API
이는 쉽고 간단한 방법으로 HTTP 서비스를 구축하기 위한 새로운 프레임워크입니다.
WEB API는 .NET Framework를 통해 REST-ful 서비스를 구축하기 위한 이상적인 플랫폼인 오픈 소스입니다.
WCF Rest 서비스와 달리 HTTP의 모든 기능(예: URI, 요청/응답 헤더, 캐싱, 버전 관리, 다양한 콘텐츠 형식)을 사용합니다.
또한 라우팅, 컨트롤러, 작업 결과, 필터, 모델 바인더, IOC 컨테이너 또는 종속성 주입, 단위 테스트와 같은 MVC 기능을 지원하여 더욱 간단하고 강력해집니다.
애플리케이션이나 IIS에서 호스팅할 수 있습니다.
경량 아키텍처이며 스마트폰과 같이 대역폭이 제한된 장치에 적합합니다.
응답은 WEB API의 MediaTypeFormatter에 의해 JSON, XML 또는 MediaTypeFormatter로 추가하려는 모든 형식으로 형식화됩니다.
다음 사항은 WCF와 WEB API 중에서 선택하는 데 도움이 됩니다.
단방향 메시징, 메시지 큐, 이중 통신 등과 같은 특별한 시나리오를 지원해야 하는 서비스를 만들려면 WCF를 선택하십시오.
TCP, 명명된 파이프 또는 UDP(WCF 4.5)와 같이 사용 가능한 경우 빠른 전송 채널을 사용할 수 있는 서비스를 만들고 다른 모든 전송 채널을 사용할 수 없을 때 HTTP도 지원하려는 경우 WCF를 선택합니다.
HTTP의 전체 기능(예: URI, 요청/응답 헤더, 캐싱, 버전 관리, 다양한 콘텐츠 형식)을 사용할 수 있는 리소스 지향 서비스를 HTTP를 통해 생성하려는 경우 WEB API를 선택하세요.
브라우저, 모바일, iPhone 및 태블릿을 포함한 광범위한 클라이언트에 서비스를 노출하려면 WEB API를 선택하십시오.
ASP.NET MVC와 WEB API에는 다음과 같은 차이점이 있습니다.
ASP.NET MVC는 뷰와 데이터를 모두 반환하는 웹 응용 프로그램을 만드는 데 사용되지만 ASP.NET WEB API는 뷰가 아닌 데이터만 반환하는 쉽고 간단한 방법으로 완전한 HTTP 서비스를 만드는 데 사용됩니다.
WEB API는 .NET Framework를 통해 REST-ful 서비스를 구축하는 데 도움이 되며 콘텐츠 협상도 지원합니다(클라이언트가 수용할 수 있는 최상의 응답 형식 데이터를 결정하는 것입니다. JSON, XML, ATOM 또는 기타 형식의 데이터일 수 있음) ), MVC에 없는 자체 호스팅입니다.
WEB API는 또한 요청의 Accept 헤더를 기반으로 JSON, XML 또는 기타 형식과 같은 특정 형식의 데이터 반환을 처리하므로 이에 대해 걱정할 필요가 없습니다. MVC는 JsonResult를 사용하여 JSON 형식의 데이터만 반환합니다.
WEB API에서는 요청이 HTTP 동사를 기반으로 하는 작업에 매핑되지만 MVC에서는 작업 이름에 매핑됩니다.
ASP.NET WEB API는 새로운 프레임워크이자 핵심 ASP.NET 프레임워크의 일부입니다. WEB API에 존재하는 모델 바인딩, 필터, 라우팅 및 기타 MVC 기능은 MVC와 다르며 새로운 System.Web.Http 어셈블리에 존재합니다. MVC에서 이러한 기능은 System.Web.Mvc 내에 존재합니다. 따라서 WEB API는 ASP.NET 및 독립형 서비스 계층과 함께 사용할 수도 있습니다.
단일 프로젝트에서 WEB API와 MVC 컨트롤러를 혼합하여 JSON, XML 또는 기타 형식으로 데이터를 반환하고 완전한 HTTP 서비스를 구축할 수 있는 고급 AJAX 요청을 처리할 수 있습니다. 일반적으로 이를 WEB API 자체 호스팅이라고 합니다.
MVC와 WEB API 컨트롤러가 혼합되어 있고 권한 부여를 구현하려면 MVC용 필터와 WEB API용 필터 두 개가 서로 다르기 때문에 두 개의 필터를 만들어야 합니다.
또한 WEB API는 경량 아키텍처이며 웹 애플리케이션을 제외하고 스마트폰 앱에서도 사용할 수 있습니다.
ASP.NET MVC와 달리 WEB API는 데이터만 반환하는 데 사용됩니다. 데이터는 문자열, JSON, XML, 텍스트 등이 될 수 있습니다. ASP.NET MVC와 같은 View를 반환할 수 없습니다.
ASP.NET MVC와 마찬가지로 아래와 같이 ActionName 특성을 사용하여 WEB API 작업 이름을 변경할 수도 있습니다.
[HttpGet] [ActionName("GetProducts")] public IEnumerable ProductList() { return db.Products.AsEnumerable(); }
ASP.NET MVC와 마찬가지로 HttpGet, HttpPost, HttpPut 또는 HttpDelete 특성을 적용하여 특정 HTTP 요청에 의해서만 호출되도록 WEB API 작업 메서드를 제한할 수도 있습니다.
HTTP Get 요청에 대한 작업 메서드만 제한하려면 아래와 같이 HttpGet 작업 메서드 선택기 속성으로 장식하세요.
[HttpGet] 공개 IEnumerable ProductList() { return db.Products.AsEnumerable(); }
ASP.NET WEB API는 아래와 같이 HttpClient 및 WEB API 주소를 사용하여 호출할 수 있습니다.
공용 클래스 ProductController : Controller { HttpClient Client = new HttpClient(); Uri BaseAddress = new Uri("http://localhost:131/"); 공개 ActionResult Index() { Client.BaseAddress = BaseAddress; HttpResponseMessage 응답 = Client.GetAsync("productservice/GetProducts").Result; if (response.IsSuccessStatusCode) { var data = response.Content.ReadAsAsync<IEnumerable>().Result; 뷰(데이터)를 반환합니다. } 반환 보기(); } }
ASP.NET MVC 및 ASP.NET WEB API는 모두 라우팅을 사용하여 들어오는 요청을 모니터링하며 작동하기 위해 하나 이상의 경로가 정의됩니다. 이 두 라우팅의 차이점은 다음과 같습니다.
WEB API 경로 패턴에서 {action} 매개변수는 선택사항이지만 {action} 매개변수를 포함할 수 있습니다. ASP.NET MVC에서는 {action} 매개변수가 필수입니다.
API 컨트롤러에 정의된 작업 메서드에는 HTTP 작업 동사(GET, POST, PUT, DELETE) 속성이 있거나 작업 메서드 이름에 대한 접두사로 HTTP 작업 동사 중 하나가 있어야 합니다. ASP.NET MVC에서는 기본적으로 HTTP GET 또는 POST 동사로 작업 메서드를 호출할 수 있으며 다른 HTTP 동사를 사용하려면 특성으로 정의해야 합니다.
ASP.NET MVC와 달리 Web API는 하나의 복합 형식만 매개 변수로 받을 수 있습니다.
ASP.NET WEB API2에서 특성 라우팅을 활성화하는 것은 간단합니다. WebApiConfig.cs 파일의 Register() 메서드에서 MapHttpAttributeRoutes() 메서드에 대한 호출을 추가하기만 하면 됩니다.
public static class WebApiConfig { public static void Register(HttpConfiguration config) { //특성 라우팅 활성화 config.MapHttpAttributeRoutes(); } }
특성 라우팅과 규칙 기반 라우팅을 결합할 수도 있습니다.
공개 정적 클래스 WebApiConfig { 공개 정적 무효 Register(HttpConfiguration config) {
//속성 라우팅 활성화 config.MapHttpAttributeRoutes(); // 규칙 기반 라우팅. config.Routes.MapHttpRoute( 이름: "DefaultApi",
RouteTemplate: "api/{controller}/{id}", 기본값: new { id = RouteParameter.Optional });
} }
ASP.NET MVC5와 마찬가지로 아래와 같이 컨트롤러 수준 및 작업 수준에서 WEB API2의 특성 라우팅을 정의할 수도 있습니다.
[RoutePrefix("서비스/사용자")] public class UserController : ApiController { //GET 경로: api/User public IEnumerable Get() { return new string[] { "value1", "value2" };
}
[Route("{id}")] //GET 경로: Service/User/1 public string Get(int id) { return "value"; }
[Route("")] //POST 경로: 서비스/사용자/ public void Post([FromBody]string value) { } }
• 작업 수준 라우팅 – 컨트롤러의 특정 작업에 적용되는 작업 수준의 경로를 정의할 수 있습니다.
공용 클래스 UserController : ApiController { //경로 가져오기: api/User
public IEnumerable Get() { return new string[] { "value1", "value2" };
}
[Route("Service/User/{id}")] //GET 경로: Service/User/1 public string Get(int id) { return "value"; } [Route("Service/User/")] //POST 경로: Service/User/ public void Post([FromBody]string value) { } }
