웹 API는 http 프로토콜을보다 기본적으로 활용합니다. Odata는 많은 대기업들이 수용 한 공개 표준입니다. Odata와 관련된 경험과 최근에 Web API를 발견하고 조사를 한 경험 만 말할 수 있습니다.
OData는 실제 표준이기 때문에 멋지다. 데이터베이스를 쉽게 만들고 HTTP를 통해 노출 할 수 있습니다. 즉, 구성없이 테이블 구조를 탐색 할 수 있습니다 (느슨하게 말하십시오). 간단한 LINQ를 포함 할 수있는 URL을 통해 쿼리를 실행할 수도 있습니다.
/products/orders/[put some linq-ish query here]
이것은 틀림없이 좋거나 나쁘다. 인증은 표준이며 구축되었습니다.
웹 API는 내 관점에서 더 흥미 롭습니다. HTTP 기능 (오류 메시지 등)을 활용했으며 실제 RESTful 요청에 대해 "기본"입니다. 나는 그것을 너무 많이 연주하지 않았습니다. 그러나 나는 MVC와 웹 API가 언젠가 다시 "결혼"될지도 모른다는 일종의 "들었다"고 들었습니다.
내가 OData를 가지고 놀 때 Stored Proc를 만들고 엔티티 표면에 매핑하고 강력한 반환 유형을 구성 한 다음 URL 요청과 BANG에 연결하면 RESTful 요청이 입력 된 결과 저장 프로 시저에 매핑됩니다. 그것은 매우 간단했고, 내가 필요한 것을 정확히 얻을 수있었습니다.
결론적
으로 WCF API를 너무 자세하게 사용할 기회는 없었지만 REST에 대한 순수한 접근 방식이기 때문에 클라이언트 개발에 갈 길이라고 말하고 싶습니다. "똑바로"앞뒤로 전화를 걸고 "모델보기"를 검색하려는 경우보다 기본적인 상호 작용을 제공합니다.
반면에. 클라이언트 상호 작용을 기반으로 데이터에 대해 복잡한 (ish) 쿼리를 작성하고 쿼리 논리를 "빌드"하고이를 매개 변수로 전달하려는 경우 Odata가 작동 할 수 있습니다.
내가 보는 방법은 데이터를 구조적 형식 (테이블 / 관계 구조)으로 노출 한 다음 클라이언트에서 직접 쿼리하면 Odata가 가장 잘 작동하는 것입니다. 또한 "기타"가 데이터 (올바른 인증 등)에 액세스 할 수 있도록하는 것이 좋습니다. 이것이 OData 프로토콜을 준수하는 이유입니다.
URL (/ products / orders / 22)을 지시하고 "숨겨진"관리 코드 및 데이터 구조에서 복잡한 "결과 세트"를 작성하고 HTTP 응답 메시지의 이점을 얻을 수있는 RESTful 요청을 원하는 경우 웹 API가 아마도 가장 좋은 방법 일 것입니다 ..
다시 말하지만, 이것은 모두 연구와 장난감에서 비롯됩니다. 프로덕션 / 풀 블로우 앱 시나리오에서 구현하지 않았습니다. 나는 그들이 강점과 약점을 가지고 있다고 생각하며, 분명히 약간의 중복이 있습니다.