RESTful 서비스와 다양한 클라이언트 (Silverlight, iOS, Windows Phone 7 등)로 구성된 분산 애플리케이션을 설계하고 있습니다. 지금은 내 서비스, WCF 데이터 서비스 (OData) 또는 ASP.NET MVC 4와 함께 출시 될 새로운 ASP.NET 웹 API를 구현하는 데 사용해야하는 기술을 결정하고 있습니다.
저는 각각에 대한 몇 가지 프레젠테이션을 온라인으로 보았고 지금은 주로 URI 및 네이티브 하이퍼 미디어 기능에 내장 된 필터링 메커니즘 때문에 WCF 데이터 서비스를 선호하고 있습니다. 내가 볼 수있는 유일한 단점은 POX와 반대로 Atom Pub 사양의 장황함입니다.
결정을 내리기 전에이 두 기술에 대해 알아야 할 것이 있습니까? 누군가가 WCF 데이터 서비스보다 ASP.NET 웹 API를 선택하는 이유는 무엇입니까?
답변:
이것은 주관적인 질문이므로 여기에 주관적인 답변이 있습니다. IMO, WCF에는 간단한 RESTful 서비스에 너무 많은 오버 헤드가 있습니다. 반면 웹 API는 RESTful 서비스를 위해 특별히 설계되었습니다.
나는 이것에 대해 Dave Ward 와 동의 한다 . 자세한 내용은 그의 블로그를 확인하십시오.
저는 WebForms 프로젝트에서 ASMX에서 WCF로 이동하라는 압력에 대해 오랫동안 버텨 왔습니다. WCF의 복잡성을 받아들이는 것은 주로 덜 유연한 JSON 직렬화로 보상을 받았기 때문입니다. 대조적으로 저는 일부 프로젝트를 ASMX에서 Web API로 변환하기 시작했으며 Web API가 ASMX를 얼마나 쉽게 대체 할 수 있는지에 만족했습니다.
나는 마이크로 소프트가 마침내 ASMX의 단순성과 Web API를 통한 WCF의 힘 사이에서 좋은 균형을 찾았다 고 믿습니다.
MediaTypeFormatter응답 형식을 구현할 수있는 것 같습니다 . 샘플 은 code.msdn.microsoft.com/Contact-Manager-Web-API-0e8e373d 를 참조하십시오 .
현재 WebApi와 WCF 데이터 서비스 간에는 다른 주요 차이점이 있지만 아무도 언급하지 않은 것 같습니다. 나는 MS가 둘을 비교하는 좋은 기사로 나오기를 바랍니다.
나는 한동안 OData와 WebApi를 따라 왔습니다. 저는 항상 몇 가지 주요 차이점을 발견했습니다.
첫째, 당신의 상사가 "MS가 WebApi를 지원하고있다"라는 말이 무엇을 의미하는지 잘 모르겠습니다. 그들이 OData를 지원하지 않는다는 의미입니까 ?? IMO, 그들은 둘 다 지원하고 있으며 현재 최소한의 겹침이 있습니다. Windows Azure Data Market은 OData를 사용하여 데이터를 노출하고, Azure Table Storage는 OData를 사용하고, SharePoint 2010은 데이터에 대한 OData 쿼리를 허용하며, Excel PowerPivot과 같은 MS의 다른 제품도이를 지원합니다. 관계형 데이터와 관련하여 매우 강력한 쿼리 프레임 워크입니다. 그리고 RESTful이기 때문에 모든 언어, 프레임 워크, 장치 등을 통합 할 수 있습니다.
OData + WCF Data Services에 대해 내가 좋아하는 점은 다음과 같습니다.
OData + WCF Data Services는 마침내 웹을 통해 데이터를 쿼리 할 때 클라이언트 응용 프로그램이보다 "표현"되도록 허용했습니다. 이전에는 항상 ASMX 또는 WCF를 사용하여 조작하기 어렵고 UI가 약간 다른 것을 원할 때마다 지속적인 변경이 필요한 견고한 웹 API를 구축해야했습니다. 클라이언트 응용 프로그램은 반환 할 기준을 지정하는 매개 변수 만 지정할 수 있습니다. 또는 내가 한 것처럼 LINQ 식을 "직렬화"하고 매개 변수로 전달 Expressions<Func<T,bool>>하고 서버에서 다시 수화 합니다. 괜찮습니다. 작업을 완료했지만 클라이언트에서 LINQ를 사용하고 REST를 사용하여 웹을 통해 번역하고 싶습니다. 이것이 바로 OData가 허용하는 것입니다. 그리고 저는 솔루션의 "해킹"을 사용하고 싶지 않습니다.
DB 연결 문자열없이 "TRANSACT SQL"을 노출하는 것과 같습니다. Url과 whoala를 제공하기 만하면됩니다! 쿼리를 시작하십시오. 물론 WebApi와 WCF 데이터 서비스 모두 인증 / 승인을 지원하므로 액세스를 제어하고 역할 또는 기타 데이터 구성에 따라 추가 "Where"문을 추가 할 수 있습니다. SQL (View 빌드 또는 Stored Procs 등)보다는 Web Api Layer에서이 작업을 수행하고 싶습니다. 이제 응용 프로그램에서 쿼리를 직접 작성할 수 있으므로 OData를 활용하고 사용자가 자신의 결과를 정의 할 수있는 임시 및 BI보고 도구가 표시됩니다. 최소한의 제어 권한이있는 정적 보고서에 의존하지 않습니다.
Silverlight, Windows 8 Metro 또는 ASP.NET (MVC, WebForms 등)에서 개발할 때 Visual Studio의 "서비스 참조"를 WCF 데이터 서비스에 추가하기 만하면 LINQ를 사용하여 데이터를 쿼리 할 수 있습니다. 클라이언트의 "데이터 컨텍스트"는 변경 사항을 추적하고 변경 사항을 원자 적으로 서버에 다시 "제출"할 수 있음을 의미합니다. 이는 Silverlight 용 RIA 서비스와 매우 유사합니다. RIA Services 대신 WCF Data Services를 사용했지만 그 당시에는 DataAnnotations 또는 Actions를 지원하지 않았지만 지금은 지원합니다. :) WCF Data Services는 RIA Services에 비해 "투영"을 수행 할 수있는 또 다른 이점이 있습니다. 클라이언트에서. 엔터티에서 모든 속성을 반환하고 싶지 않은 경우 성능에 도움이 될 수 있습니다. "데이터 컨텍스트"보유
따라서 WCF Data Services는 특히 SQL Server 및 Entity Framework를 사용하는 경우 관계가있는 데이터가있는 경우 유용합니다. 아주 적은 코드로 REST를 통해 쿼리 가능한 데이터 + 작업 (작업 호출, 즉 워크 플로, 백그라운드 프로세스)을 신속하게 노출 할 수 있습니다. WCF 데이터 서비스가 방금 업데이트되었습니다. 새 릴리스가 출시되었습니다. 모든 새로운 기능을 확인하십시오.
WCF 데이터 서비스의 단점은 HTTP 스택을 통해 느슨해 진 "제어"입니다. 가장 큰 결함은 IQueryable<T>컬렉션을 반환 하는 메서드에 있습니다. RIA Services 및 WebApi와 달리 IQueryable 메서드에서 논리를 개발할 수있는 전체 액세스 권한이 없습니다. RIA Services 및 WebApi에서는 .NET을 반환하는 한 원하는 코드를 작성할 수 있습니다 IQueryable<T>. WCF Data Services에서는 Expression<Func<T,bool>>인터셉터 메서드를 사용하여 "Where"문을 추가하는 데만 액세스 할 수 있습니다 . 실망 스러웠습니다. 현재 응용 프로그램은 RIA 서비스를 사용하고 있으며 IQueryable 논리를 제어 할 수있는 기능이 정말 필요합니다. 나는 이것에 대해 틀렸기를 바라며 나는 무언가를 놓치고있다.
또한 WCF 데이터 서비스는 아직 모든 LINQ 연산자를 완전히 지원하지 않습니다. 그래도 WebApi 이상을 지원합니다.
WebApi는 어떻습니까 ???
WebApi는 실제로 WCF 데이터 서비스 / OData와 같은 엔터티 데이터 모델에 관한 것이 아니기 때문에 현재로서는 (내 이해에 따라) 클라이언트 (예 : Silverlight, ASP.NET 서버 측 코드 등)에서 "데이터 컨텍스트"지원이 없습니다. 이다. IQueryable / IEnumerable을 사용하여 모델 개체 컬렉션을 노출 할 수 있지만 "데이터 컨텍스트"가 없기 때문에 엔터티가 클라이언트에로드되면 사용할 기본 키 / 외래 키 "탐색 속성"(예 : customer.Invoices)이 없습니다. 비동기 적으로 (또는 $ expand를 사용하는 한 번의 호출로)로드하고 변경 사항을 관리합니다. RIA 서비스 또는 WCF 데이터 서비스에서와 같이 클라이언트에 코드 생성 된 엔터티 데이터 모델 "표현"이 없습니다. 나는 당신이 당신의 데이터를 대표하는 클라이언트에 모델을 가질 수 없거나 가질 수 없다고 말하는 것이 아닙니다. 그러나 데이터를 수동으로 채우고 웹을 통해 검색된 각 "고객"에 대해 설정할 "청구서"를 관리해야합니다. 이것은 특히 모든 Async 작업이 진행되는 경우 까다로울 수 있습니다. 어떤 전화가 먼저 돌아올 지 모릅니다. 여기에서는 설명하기 어려울 수 있지만 RIA 서비스의 "데이터 컨텍스트"에 대해 읽어 보거나WCF 데이터 서비스 . 따라서 LOB (기간 업무) 앱을 다룰 때 이것이 저에게 중요한 문제입니다. 이것은 주로 생산성과 유지 보수성을 기반으로합니다. 데이터 컨텍스트없이 앱을 명확하게 빌드 할 수 있습니다. 특히 Silverlight, WPF 및 Windows 8 Metro에서 작업을 더 쉽게 만듭니다. 관계형 엔터티를 비동기 적으로 메모리에로드하고 Two-Binding을 사용하면 정말 좋습니다.
그렇다면 언젠가 WebApi가 클라이언트에서 "데이터 컨텍스트"를 지원할 수 있다는 의미입니까? 그럴 수 있다고 생각합니다. 또한 더 많은 도구를 사용하면 Visual Studio 프로젝트에서 데이터베이스 스키마 (또는 Entity Framework)를 기반으로 모든 CRUD 메서드를 생성 할 수 있습니다.
또한 WCF Data Services 또는 WebApi를 사용할 때 .NET에서 .NET Frameworks로만 언급한다는 것을 알고 있지만 HTML / JS도 주요 플레이어라는 것을 잘 알고 있습니다. Silverlight UI 또는 ASP.NET 서버 측 코드 등을 다룰 때 얻은 이점을 언급했습니다. HTML5 / JavaScript에서 "IndexedDB"의 출현으로 "데이터 컨텍스트"와 JavaScript의 LINQ 프레임 워크도 사용할 수 있으므로 JavaScript에서 OData 서비스를 훨씬 쉽게 쿼리 할 수 있습니다 (현재 OData와 함께 DataJS를 사용할 수 있음). 또한 KnockoutJS를 사용하여 MVVM을 지원하고 HTML / JS의 바인딩도 지원합니다. :)
현재 사용할 플랫폼을 조사하고 있습니다. 둘 중 하나를 사용해도 좋겠지 만, 다음 애플리케이션이 주로 분석 (읽기 전용)에 관한 것이고 풍부한 표현 RESTful API를 원한다는 사실을 바탕으로 OData에 의지하는 경향이 있습니다. WebApi는 $ take, $ skip, $ filter, $ orderby over Collections 만 지원하기 때문에 OData + WCF Data Services가 제공한다고 생각합니다. Projections, Includes ($ expand) 등을 지원하지 않습니다. "업데이트 / 삭제 / 삽입"이 많지 않으며 데이터는 상당히 관계 적입니다.
나는 다른 사람들이 토론에 참여하여 그들의 생각을 전하기를 바랍니다. 아직 결정 중이며 다른 의견을 듣고 싶습니다. 둘 다 프레임 워크가 훌륭하다고 생각합니다. 선택해야하는지 궁금합니다. 필요한 경우 둘 다 사용하지 않는 것이 좋습니다. 클라이언트에서는 어쨌든 REST 호출을 구축하는 것이 전부입니다. 그냥 생각 :)
우리는 Web API가 앞으로 OData 서비스에 적합한 플랫폼을 제공하므로 OData 서버 스택을위한 플랫폼 에 주로 투자 할 것이라고 믿습니다 . 물론 OData 핵심 라이브러리와 클라이언트에 계속해서 상당한 리소스를 투입 할 것이지만 OData 서비스 생성을위한 스택으로서 WCF Data Services에 대한 투자 를 줄일 계획 입니다.
그래서 이제 모든 것이 충분히 명확 해 보입니다.
Web API와 WCF Data Services는 모두 OData를 즉시 지원합니다. WCFDS (WCF Data Services)를 사용하면 자동입니다. Web API IQueryable를 사용하여 컨트롤러에서 돌아와 메서드에 [Queryable]. 이것은 $filter당신이 이야기 했던 기능을 얻을 것 입니다. 그리고 이렇게하면 둘 다 accept=application/json요청 헤더를 넣어 응답에서 JSON을 자동으로 처리 할 수 있습니다 . WCFDS의 OData는 Web API보다 몇 가지 더 많은 OData 키워드를 지원하지만 ( $expand키워드 만 떠오르지 만 ) 시간이이 문제를 해결할 것이라고 확신합니다.
.NET 클라이언트와 HTML 페이지 모두 이러한 대안을 모두 쉽게 호출 할 수 있지만 LINQ를 좋아하고 .NET 클라이언트를 빌드하는 경우 WCFDS를 서비스 참조로 프로젝트에 추가 할 수 있습니다. 이를 통해 모든 HTTP 비즈니스를 모두 건너 뛰고 컬렉션을 직접 쿼리 할 수 있습니다.
결론은 .svc 파일을 ASP.Net MVC 프로젝트에 넣는 것을 방해하는 것이 없다는 것입니다. 둘 중 하나 또는 제안이 아닙니다. 서버에 데이터 서비스를 추가하면 많은 컨트롤러를 작성할 필요가 없지만 원하는 경우 추가 컨트롤러를 작성하는 것을 막지는 않습니다.
다시 말해 :
데이터 모델 (EDM 또는 기타)을 신속하게 노출하려고하고 많은 코드 나 비즈니스 논리가 필요하지 않은 경우 WCF Data Services를 사용하면이 작업이 정말 쉬워지고 좋은 시작점이 될 것입니다.
API를 빌드하고 OData 쿼리 구문 또는 형식을 사용하여 일부 리소스 (및 논리)를 노출하려는 경우 ASP.NET Web API 가 시작하기에 가장 좋은 곳일 것입니다.
Devaron은 내가 아직 찾지 못한 WCF 대 Web Api에 대한 가장 유익한 리뷰를 제공했습니다. 감사. 이제 WCF가 너무 복잡하다는 점에서 복잡성이 자동으로 부정적인 것이 아니라고 말할 것입니다. 당신은 미래에 당신에게 제공되는 호흡 공간에 대해 감사 할 것입니다. Microsoft 도구에서 늘 그렇듯이 당면 과제는 우리가 그 미래를 알거나 통제 할 수 없다는 것입니다. Microsoft가 더 통합 된 시스템으로 끝나고 몇 년 동안 유지되기를 바랍니다.
또한 구축해야 할 큰 시스템이 있으며 경로가 더 명확하지 않다는 점을 강조합니다. 이 모든 것이 해결되는 동안 나는 몇 달 더 연기 할 계획이다. 그리고 개인적으로 나는 datajs를 응원하고 있습니다 (JayData도 확인하십시오)
간단하게 말해서 기본 프로토콜에서 뒤로 물러나 개발자 / 사용자의 관점에서 살펴보세요. Web API는 WCF가 아닌 Microsoft의 첫 번째 클래스 HTTP 기반 Rest Framework입니다. 즉, 누락 된 Rest 기능, 사양은 Web API 파이프에 추가되며 반드시 WCF에 추가되지는 않습니다.
예, WCF에서 직접 구현할 수 있지만 문장에서 언급했듯이 직접 구현해야합니다.
오늘날 웹 API에 대한 2 단계 인증을 구현하는 예와 마찬가지로 주로 오픈 소스 프로젝트로 시작된 인증 / 승인 너겟 패키지 인 OWIN을 사용하여 15 분이 채 걸리지 않습니다.
기술 스택을 사용하는 경우 Microsoft 용 1 급 스택을 사용하는 것이 큰 차이를 만듭니다. Github에 수많은 MS가 게시 한 샘플 코드와 프로젝트가있을 것입니다.이 프로젝트는 간단하게 복사하여 자신의 프로젝트를 시작할 수 있습니다. 모든 레벨, 문서, 코드 샘플, 기능 세트, 지원, 도우미 API에서 차이를 만듭니다.
따라서 Restfull HTTP 기반 애플리케이션을 빌드하려면 웹 API (또는 이식성을 위해 ASP.NET Core)를 사용하고 WCF를 사용하지 않는 것이 좋습니다. 프로토콜이 HTTP가 아니고 실제로 HTTP 일 수없는 경우 WCF를 사용하십시오.
이것이이 질문에 대한 TL; DR 답변입니다.
WCF는 데이터 통신 및 전송을위한 WEB API의 스크루 드라이버에 대한 스위스 군용 칼입니다. WCF는 WEB API가 할 수있는 모든 작업을 수행 할 수 있지만 더 필요한 경우 (예 : TCP 프로토콜 사용) WCF를 사용하는 것이 좋습니다.
여기에 훌륭한 비교가 있습니다.
WEB API를 사용하는 가장 큰 이유는 경량이기 때문입니다. 이것은 구현이 더 간단하고 배우기 쉽고 유지 관리가 더 쉽다는 것을 의미합니다. HTTP를 통한 RESTful 웹 서비스가 필요한 웹을 위해 특별히 설계되었습니다. 이것은 이것을하고 잘합니다. 이것이 필요한 전부라면 WEB API가 아마도 갈 길일 것입니다.
또한 오픈 소스입니다 (관심 있다면)
WCF는 웹 API 이상의 기능을 수행합니다. 여러 전송 프로토콜, 여러 교환 패턴 (WEB API에는 SignalR 또는 웹 소켓과의 통합이 필요함)을 지원하고 SOAP 서비스를 WSDL로 설명 할 수 있으며 추가 보안 기능 등이 있습니다. 이 추가 기능이 필요한 경우 WCF를 사용하십시오.
OData는 간단합니다.
간단하고 표준적인 방식으로 쿼리 가능하고 상호 운용 가능한 RESTful API를 만들고 사용할 수있는 개방형 프로토콜입니다. 출처 : http://www.odata.org/
즉, 높은 수준에서 RESTful HTTP 요청에 대한 특정 문법을 표준화하는 것입니다. 모든 프로토콜과 동일한 이점을 제공합니다. 그리고 최소한 2013 년부터는 WCF와 WEB API 모두 OData를 사용할 수 있습니다. 따라서 OData에 대해 걱정할 가치가 없을 것입니다.