API에 상태 메서드가 필요합니까?

Question

나는 API를 구축하고 있으며 API의 상태를 반환하는 API에 메소드가 있는지의 여부가 의심 스럽습니다.

또는이 API 사용자가 필요한 메소드를 호출 할 수 있고 네트워크 문제로 인해 반환하지 않으면 필요에 따라 처리합니다.

Answer 1

상태를 반환하는 것이 매우 유용하다고 생각합니다. 한편으로는 '살아있는'것보다 더 많은 상태를 제공 할 수 있고 API를보다 강력하게 만들 수 있으며, 다른 한편으로는 사용자에게 더 유용합니다. 사용자에게 정확히 무슨 일이 일어나는지 알려줄 수 있기 때문에 (예 : '유지 보수').

하지만 네트워크 문제로 인해 WebService를 사용할 수없는 경우 물론 예외는 사용자에게 있습니다. 그러나 그것은 중요한 것이 아니라고 생각합니다. API로 제어 할 수있는 것이 아닙니다.

Answer 2

표준 HTTP 응답 상태 코드에 어떤 문제가 있습니까? 503 Service Unavailable이 떠오른다. HTTP 클라이언트는 이미 API에 특별한 코드를 쓰지 않고도이를 처리 할 수 ​​있어야합니다.

을 빈번히 사용할 수 없으며 클라이언트가 서버에 대해 값이 싼 것을 발견하면 비용이 많이 들지만 이제는 별도의 '상태 확인'URL을 사용하는 것이 적절할 수 있습니다 클라이언트가 서비스를 사용할 수 있음을 알리십시오 (상태 확인 URL의 GET 시점에).

Answer 3

대부분의 시간은 필요하지 않습니다. 최소한 단순한 참 또는 거짓을 리턴 할 때. 한 번 더 메소드를 호출해야하기 때문에 클라이언트 코드가 더 복잡해집니다. 클라이언트가 서비스에서 active = true를 받았다고하더라도 다음 유용한 호출은 여전히 ​​실패 할 수 있습니다. 클라이언트가 정상적인 실행 중에 필요한 호출을 만들어 네트워크, 시간 초과 및 HTTP 오류를 올바르게 처리하게하십시오. 이러한 경우에 매우 유용한 패턴을 Circuit Breaker이라고합니다. 상태 검사가 유용 할 수 있습니다

이유 : 모든 정상적인 통화가 비싼 것으로 간주하는 경우

• 먼저 호출 가벼운 상태 검사 방법의 장점이있을 수있다 (다만 고가의 전화를 피하기 위해).
• 서비스의 상태가 서로 다를 수 있으며 클라이언트는 이러한 상태에 따라 동작을 변경할 수 있습니다.

XMPP과 같은 상태 유지 프로토콜을 살펴 보는 것도 도움이 될 수 있습니다.

Answer 4

쓸모가 없습니다.

상태 반환 호출이 전달 된 직후 서비스가 실패 할 수 있기 때문에 반환되는 정보는 반환 된 시점과 완전히 다릅니다.

또한 들어오는 요청을로드 밸런싱하고 상태 요청이 실패한 노드로 라우팅되면 응답 (또는 부족)으로 인해 클라이언트에게 전체 API 서비스의 문제처럼 보일 것입니다. 그 동안 다른 모든 노드가 행복하게 요청을 처리 할 수 ​​있습니다. 이제 클라이언트는 전체 API 서비스가 다운되었지만 후속 요청은 정상적으로 작동 할 것이라고 생각합니다 (로드 밸런서가 실패한 노드를 제거하거나 다시 시작한다고 가정).

응용 프로그램의 요청에서 반환 된 HTTP 상태 코드가 올바른 사용 가능성을 나타내는 올바른 방법입니다. 고객은 물론 허용하고 처리하도록 코딩해야합니다.