나는 웹 서비스를 개발하는 법을 배우고있다. 내가 아는 바로는 두 가지 방법 1. SOAP과 2.REST가 있습니다. 비누는 대부분 REST가 HTTP 요청 인 동안 XML을 사용하여 통신합니다. google api, twitter api와 같은 외부 API가 있거나 웹 서비스로 imdb movie api가있을 수 있습니까? 이러한 API의 대부분은 restAPI이므로 영화 정보 웹 서비스를 개발하면 안심할 수 있습니까? 나는 현재 api에 imdb http 요청을 사용하여 영화 정보를 반환하는 웹 서비스를 만드는 방법을 배우고 있습니다. 내부적으로 웹 서비스가 imdb api와 같이 다른 외부 API를 가질 수 있습니까?웹 서비스와 API는 어떻게 다릅니 까?
귀하의 혼란은 이해할 수 있습니다. 관련이 있지만 약간 다른 용어가 많이 있습니다. 명확히하기 :
API 응용 프로그램 프로그래머 인터페이스 (또는 API)는 일부 기능의 제공자와 일부 기능의 소비자 사이의 "계약"입니다. API는 입력, 유형 및 입력에 대한 전제 조건, 예상 출력 및 출력에 대한 사후 조건, 실패 모드 및 기능을 성공적으로 사용하는 데 필요한 기타 정보 (예 : 프로그래밍 언어 API 또는 웹 API의 컨텍스트에서 요청 경로).
서비스 API는 특히 특정 구현이 아닙니다. 일부 기능의 공급자 또는 소비자가 독립적으로 구성 요소를 개발하고 서로 성공적으로 (또는 대체 구현 자/소비자와) 통합 할 수있게 해주는 사양입니다. 반면에 서비스는 API의 특정 구현입니다. 예를 들어, Feedly와 (현재 사용하지 않는) Google 리더는 동일한 Google 리더 API를 구현하는 서비스입니다.
SOAP와 REST의 경우 SOAP과 REST 모두 HTTP를 사용합니다. 그러나 요청과 응답 구조에 약간 다른 접근 방식/스타일을 사용합니다. 웹 API는 정의상 RESTful 일 뿐이며 API가 아닙니다. 웹 API는 REST 원칙을 따르는 경우 RESTful입니다. 특히, URL이 자원에 해당하고 이러한 자원에서 작동하는 verb가 HTTP 메소드 (예 : GET, PUT, POST 및 DELETE) 인 경우 API는 RESTful입니다. 예를 들어, RESTful API에서 "GET"을 사용하여 자원을 검색하고 "PUT"을 첨부하여 자원을 "POST"로 ovewrited합니다. 항목 목록을 수정하기 위해 일반적으로 특정 요소와 요소 목록을 모두 참조하는 URL이 있습니다. 많은 소위 "REST"API는 실제로 가장 엄격하고 순수한 용어로 사용되지 않습니다. 예를 들어 많은 Google API는 REST의 많은 속성/아이디어를 공유하지만 수행 된 작업을 나타내는 URL의 경로에 동사를 포함하는 경우가 있습니다 (엄격한 의미에서 REST는 허용하지 않습니다. URL은 명사는 단 하나의 동사로 HTTP 메서드 사용).
마지막으로 마지막 질문에 답하기 위해 다른 내부 vs 외부 API를 사용할 수 있습니다. 즉, "API"라는 용어가 내부 버전에 실제로 적용되는지 여부는 논쟁의 여지가 있으며, 해당 기능의 내부 "소비자"와 "공급자"가 별도인지 여부에 달려 있습니다. 내부 버전이 내부 구현이 무엇이든지간에 "API"로 분류 될 수 있는지 여부는 다소 논란의 여지가 있습니다.