[웹 API 디자인] 12. API 요청을 하나의 하위 도메인으로 통합
API 요청을 하나의 하위 도메인으로 통합
우리는 최상위 도메인 이후에 나오는 것들에 대해 이야기했습니다. 이번에는 URL의 반대편에 있는 것들을 살펴보겠습니다.
Facebook, Foursquare, 그리고 Twitter가 이것을 다루는 방법은 다음과 같습니다:
Facebook은 두 개의 API를 제공합니다. 이전에는 api.facebook.com을 사용했으나, 이제는 소셜 그래프를 중심으로하는 graph.facebook.com으로 변경되었습니다.
graph.facebook.com
api.facebook.com
Foursquare은 하나의 API를 가지고 있습니다.
api.foursquare.com
Twitter는 세 개의 API를 가지고 있으며, 두 개는 검색과 스트리밍에 중점을 둡니다.
stream.twitter.com
api.twitter.com
search.twitter.com
페이스북과 트위터가 여러 개의 API를 가지게 된 배경은 타이밍과 인수합병에 많은 영향을 받았습니다. DNS의 CName 항목을 다른 클러스터로 요청을 보낼 수 있도록 재구성하는 것도 쉽기 때문입니다.
하지만 앱 개발자의 최선의 이익을 고려한 설계 결정을 내린다면, Foursquare의 예를 따르는 것을 권장합니다.
모든 API 요청을 하나의 API 서브도메인으로 통합하세요.
이렇게 하면 개발자들이 당신의 API를 사용하여 멋진 앱을 만드는 것이 더 깔끔하고 쉽고 직관적입니다.
Facebook, Foursquare 및 Twitter는 모두 전용 개발자 포털을 갖고 있습니다.
developers.facebook.com
developers.foursquare.com
dev.twitter.com
이것을 어떻게 구성해야 할까요?
API 게이트웨이는 최상위 도메인이어야 합니다. 예를 들어, api.teachdogrest.com
REST의 정신을 따르면 개발자 포털은 다음 패턴을 따르는 것이 좋습니다.
developers.yourtopleveldomain. 예를 들어, developers.teachdogrest.com
웹 리디렉션을 수행하세요.
그런 다음, 브라우저에서 들어오는 요청에서 개발자가 실제로 이동해야 할 위치를 감지할 수 있다면 선택적으로 리디렉션할 수 있습니다.
예를 들어 개발자가 브라우저에 api.teachdogrest.com을 입력하지만 GET 요청에 대한 다른 정보가 없는 경우, 개발자 포털로 안전하게 리디렉션하여 개발자가 실제로 이동해야 할 위치로 안내할 수 있습니다.
api -> developers (if from browser)
dev -> developers
developer -> developers
댓글남기기