"SDK를 원하고 기본 프로토콜을 알고 싶을 때"(http://www.tbray.org/ongoing/When/199x/1999/08/18/BitsOnTheWire 참조)에 대한 논쟁이 있습니다."SDK vs the bit of the wire"논쟁은 무엇인가?
나는 이것이 무엇을 말하는지, 왜 그들이 상호 배타적인지 이해하지 못합니다.
각 접근 방식의 철학은 무엇이며 왜 서로 충돌합니까?
그들은 실제로 상호 배타적이지 않습니다. 연속체에 가깝지만 시스템 뒤에있는 개발 철학은 한쪽 또는 다른쪽으로 이끌 리는 경향이 있습니다.
기본적으로 통신 프로토콜의 비트는 비교적 단순한 (또는 비공식적 인) 사양을 통해 외부 개발자에게 설명 될 수 있도록 통신 프로토콜이 간단하다고 말합니다. 이는 예기치 않은 온갖 종류의 서비스에서 서비스를 사용할 수 있음을 의미하며 서비스 소비자는 공식 지원 플랫폼 일 필요는 없습니다.
반면에 애플과 마이크로 소프트 같은 모 놀리 식 제품을 제공하는 회사는 완전한 철저한 엔드 투 엔드 SDK를 만드는 또 다른 철학을 선택하는 데 사치를 가지고 있습니다. 이론적으로 이는 기본 프로토콜의 복잡성을 추상화하고 동시에 제품을 더 복잡한 작업을 수행하고 개발자 오류를 줄임으로써 개발자가 더 쉽게 사용할 수있게합니다. 물론 여전히 비트가 있으며 와이어를 계속 통과하며 리버스 엔지니어링 할 수 있습니다. 그러나 이해할 수 있도록 고안된 프로토콜을 사용하는 것보다 특히 비즈니스 이해를 돕기 위해 의도적으로 난독 화 또는 암호화 된 프로토콜을 사용하는 것보다 훨씬 어려울 것입니다.
클라이언트 C가 공급 업체 V가 제공하는 서비스 S와 대화해야한다고 가정 할 때 은 클라이언트 C에 공급 업체 V의 SDK 소프트웨어를 설치해야 S와 통신 할 수 있습니다. 손으로 벤더 V 문서가 정확히 인 경우을 비트 레벨까지 서비스 S로 얘기하면 클라이언트 C에 직접 소프트웨어 S로 문의하여 직접 서비스 S와 통신 할 수 있습니다.
그래서 ... SDK는 당신에게 번역기를 제공하고 Bits-on-the wire는 당신에게 로제타 스톤을 준다? – Fry
독점적 인 점은 서비스를 제공하는 사람은 누구나 SDK 또는 유선 프로토콜을 공개 된 고객 지향 인터페이스로 사용한다는 것입니다. 둘 다 제공하는 서비스를 가질 수 있고 고객이 집중할 서비스를 선택할 수있게 할 수는 있지만 사치가 될 수 있습니다.
문제 해결을 위해 특히 비트 수준에서 어떤 일이 일어나는지 파악하는 것이 도움이되지만 공급 업체의 SDK를 사용하면 공급 업체가 메시징에 적용 할 수있는 향후 변경 내용과 통합을 분리하는 가장 좋은 방법 일 수 있습니다 구조.
최신 SDK를 구하는 데 불편을 겪지는 않겠지 만 적어도 공급 업체가 제대로 작동한다면 코드 변경에 대해 걱정할 필요가 없습니다. 단지 새로운 SDK를 사용합니다.
예를 들어 지불 스위치 제품을 전문으로하는 ISD라는 회사와 협력했습니다. Google은 SDK에 코딩했습니다. 제품이 일부 버전 관리를 거쳤지만 클라이언트 시스템에서 DLL을 업데이트해야합니다. DLL은 동일한 공용 인터페이스를 유지했습니다.
SDK 경로로 이동하면 this story에서와 같이 와이어 사양에 비트를 제공하지 않는 것이 매우 중요합니다.
나는 이것이 진짜 질문이라고 생각하지 않는다. –