API는 초콜릿 상자와 같아서 무엇을 얻는지 절대 알 수 없습니다.

API를 통합하는 작업을 받았다고 상상해 보십시오. 파트너 API이고 코드가 제어할 수 없으며 널리 사용되지 않습니다. 그러나 적어도 몇 가지 문서가 있습니다. 빠르게 뛰어듭니다. 엔드포인트, 필수 매개변수, 권한 부여 목록이 있지만 누락된 것이 있습니다. API 응답에 대한 정보는 전혀 없으며, 일반적인 응답이 어떻게 보여야 하는지도, 가능한 오류는 말할 것도 없습니다. 이제 HTTP 클라이언트를 꺼내서 어떻게 작동하는지 보기 위해 요청으로 API를 찌르기 시작할 때입니다.

문서화되지 않은 응답을 처리하는 것은 그리 큰 문제가 아닙니다. JSON을 시각화하고(예: JSON Crack ) 해당 스키마를 추론하는(예: MakeTypes ) 도구가 있습니다. 이미 설정한 가정을 완전히 버리는 극단적인 경우입니다.

최근에 나는 그런 API로 작업했습니다. 설명서에는 엔드포인트가 존재하고 일부 특정 매개변수가 필요하다고만 언급되어 있습니다. API의 이상한 맞춤형 인증 스키마를 파악한 후 끝점을 살펴보기 시작했습니다.

가장 먼저 눈에 띄는 것은 응답의 콘텐츠 유형이었습니다. API가 JSON으로 응답하는 동안 content-type 헤더는 응답을 HTML로 표시합니다. 이로 인해 대부분의 HTTP 클라이언트에서 자동 구문 분석(및 구문 강조 표시 및 서식 지정)이 중단되지만 응답은 여전히 ​​수동으로 구문 분석할 수 있습니다. 일부 응답에 데이터와 함께 HTML 경고가 포함되었을 때 재미가 시작되었습니다. 예를 들면 다음과 같습니다.

<br />
<b>Warning</b>: Undefined array key "TEST" in <b>/some/source/file</b> on line <b>123</b>
<br />
<br />
{"foo":"bar"}

기술적으로 API는 일관되게 동작했습니다. 즉, HTML로 응답한다고 주장했고 실제로 그렇게 했습니다. 그러나 실제로 이 동작은 API를 소비자에게 거의 쓸모 없게 만듭니다. 물론 응답을 검색하고 JSON 부분만 구문 분석할 수 있습니다. 영리한 해킹을 찾는 것은 재미있지만 일반적으로 장기적으로 지속 가능하지 않습니다. 소스 파일 구조를 노출하는 오류 메시지를 유지하는 것은 말할 것도 없이 security risk . API 제공자에게 문제를 보고했습니다(아무도 이전에 이 문제를 보고하지 않았다는 사실에 놀랐습니다). 그들은 응답에 신속했고 내 제안에 따라 API를 개선했습니다.

다른 개발자처럼 기술적 문제를 해결하는 것을 좋아하지만 때로는 사람들과 대화하는 것이 정말 더 쉽습니다. 그러나 문서화되지 않은 놀라운 동작을 하는 API를 조사하는 데 얼마나 많은 시간이 낭비되는지 생각하면 답답합니다. 또한 내부 및 파트너 API에 대해서도 더 나은 개발자 경험을 옹호해야 하지만 API를 .

이제 당신에게: 당신이 처리한 가장 이상한 API 동작은 무엇이었습니까?

표지 사진 출처: Lukas on Pexels .