일반적인 API 오류 및 해결 방법

웹사이트나 애플리케이션이던 소프트웨어를 구축할 때 소프트웨어 개발 주기에 품질 보증을 포함해야 합니다. 놓치면 최종 사용자의 경험을 확실히 망칠 버그가 있는 인스턴스를 릴리스할 가능성이 높습니다.

어떤 이해 관계자도 이런 일이 일어나기를 원하지 않을 것입니다. 그렇기 때문에 테스트는 성공적인 릴리스를 위해 주의를 기울이고 추가하는 기능에 대한 긍정적인 응답을 보장합니다. 여기에는 실제 고객이 확인하기 전에 흐름이 예상대로 작동하는지 확인하는 가장 일반적인 사용 사례 시나리오가 수반됩니다.

커버리지 제품군에 포함할 테스트를 고려할 때 가장 중요하고 널리 사용되는 유형 중 하나인 API 테스트에 주의하십시오. API(응용 프로그래밍 인터페이스) 는 모든 응용 프로그램에 존재하며 여러 소프트웨어 시스템 간의 적절한 통신을 담당합니다. API의 주요 기능에는 전송할 수 있는 데이터 요청과 이러한 요청을 처리하기 위한 조건을 지정하는 것이 포함됩니다. 

예를 들어 사용자가 장바구니에 일부 항목을 추가하고 API 요청을 트리거하는 해당 버튼을 누르고 응답을 수신하면 장바구니가 업데이트됩니다. 이 요청이 실패하면 "장바구니에 추가" 기능이 중단됩니다.

이것이 API 문제가 비즈니스에 영향을 미칠 수 있는 방식이며 모든 사람이 API를 적절하게 테스트해야 하는 한 가지 중요한 요소를 추가합니다. 이 테스트를 통합하려면 올바른 자동화 API 테스트 도구 로 시작하여 오류가 발생하지 않도록 해야 합니다.

다양한 API 오류가 있을 수 있으며 가장 많이 사용되는 5가지 오류에 대해 자세히 알려드리겠습니다. 

잘못된 HTTP 메서드

가장 단순하지만 널리 퍼진 API 오류는 잘못된 HTTP 메서드입니다. 종종 이 문제는 문서의 공백으로 인해 발생합니다. 예 중 하나는 데이터 옵션을 지정하는 GET 요청을 보내는 것일 수 있지만 -X GET 매개변수에 대한 언급은 건너뜁니다. 결과적으로 자동으로 POST 요청으로 변환됩니다. 또한 API 도구를 전환할 때 HTTP 메서드의 문제가 발생할 수 있습니다. 그 중 일부는 테스트 환경을 만들고 수정하는 한 가지 방법을 사용하고 다른 작업은 이러한 작업에 대해 별도의 방법을 사용하기 때문입니다. 그렇기 때문에 이러한 뉘앙스를 주의 깊게 확인하고 문서 작성에 일관된 접근 방식을 채택하는 것이 중요합니다. 

잘못된 프로토콜 사용

또 다른 일반적인 오류는 https://와 http:// 프로토콜 간의 불일치입니다. 일부 API는 프로토콜 중 하나만 지원할 수 있습니다(예: http). 따라서 이러한 경우 https://를 지정하면 잘못된 요청 처리가 발생합니다. 둘 다 지원하더라도 http://를 지정할 때 https://로 리디렉션하는 데 문제가 있을 수 있습니다. 사용하려는 타사 API 제공업체가 일부 변경을 수행하고 이에 대한 알림을 보내지 못하는 경우에도 발생할 수 있습니다. 따라서 이러한 측면을 수시로 다시 확인하는 것이 좋습니다. 자신만의 API를 생성하려면 https:// 프로토콜을 사용하는 것이 좋습니다. 이를 가능하게 하려면 SSL 인증서를 설치해야 합니다.호스트에게. 얼마 전 SSL 인증서는 비용이 많이 들었기 때문에 이에 대해 의구심이 들었지만 Letsencrypt 또는 Cloudflare와 같은 무료 공급자를 사용하면 그 어느 때보다 쉬워집니다.

의미 있는 오류 메시지의 부재

" 예기치 않은 API 오류가 발생한 적이 있다면", 당신은 이것이 얼마나 짜증나는지 압니다. 일반적으로 오류 메시지는 개발자가 오류의 정확한 원인 또는 최소한 오류를 검색할 위치를 지적하는 문제 해결을 용이하게 하기 위한 것입니다. 불행히도, 그러한 정보가 없는 오류는 시간 낭비를 초래하고 오류를 해결하는 데 필요한 시간을 증가시키며 결과적으로 받는 부정적인 피드백의 급증을 유발할 수 있습니다. 따라서 잠재적인 설명에 조금 더 시간을 할애하는 것이 좋습니다. 오류를 수정하고 문제를 해결해야 하는 사람들에게 정보를 제공하는 메시지를 만듭니다. HTTP 오류 코드는 수십 가지가 있지만 모두 사용할 필요는 없지만 표준 오류 코드(200,400, 500)를 유지하고 메시지에 힌트를 포함하여 무언가가 작동하지 않는 경우에도

권한 부여 문제

잘못된 권한 부여는 일반적으로 사용자 이름이나 암호가 올바르지 않다고 가정하므로 여기에서 모든 것이 명확해 보일 수 있지만 실제로 헤더에서 "인증"과 "인증"을 혼동하는 경우에도 오류가 발생합니다. 특히 OAuth 2 프로토콜을 사용할 때 유효합니다. 또한 구문이 중요합니다. 일부 단순하지만 덜 분명한 것들이 혼동을 일으킬 수 있기 때문입니다. 대부분의 경우 이들은 전달자 토큰, "Basic" 접두사의 공백, 이 접두사를 완전히 추가하기 위해 누락된 것, 그리고 "username: password" 쌍에서 콜론을 잃는 것입니다. 비밀번호가 필요하지 않은 일부 API에서 사용자 이름을 단독으로 사용하는 경우에도 이 콜론을 사용해야 합니다.

Content-Type 및 Accept 헤더 지정 실패

일부 API는 헤더에 Content-Type 또는 Accept 헤더가 포함되어 있지 않지만 허용된 데이터 형식에 해당하는 요청을 허용합니다. 다른 사람들은 더 세심하고 403 Permission Denied 오류 코드를 제공하여 요청을 허용하지 않습니다. 이 단계에서 요청 및 응답의 예상 데이터 유형에 대한 클라이언트와 서버 간의 상호 작용이 설정됩니다. 이 헤더 검사는 보안 침해 및 전반적인 해킹 시도의 위험을 낮추기 위해 구현되므로 사용 중 문제를 피하기 위해 이러한 헤더를 지정하는 것이 좋습니다.

마무리

회귀, 스모크 테스트 및 물론 개발 스프린트 중 단위 테스트를 포함한 다른 테스트 유형과 함께 API 테스트를 수행하면 소프트웨어 릴리스를 더 빠르게 수행하는 데 도움이 됩니다. 그 이면의 논리는 간단합니다. 버그, 결함 또는 비즈니스 요구 사항과의 불일치를 빨리 발견할수록 수정하기가 더 쉽습니다. 결과적으로 최종 사용자에게 최고 수준의 경험을 제공하여 프로세스에서 예기치 않은 버그 없이 소프트웨어와의 상호 작용을 즐길 수 있으므로 비즈니스에 더 많은 이익을 가져다 줄 수 있습니다.