그것은 매우 오래된 게시물이지만 비슷한 문제에 직면하여 내 경험을 여러분과 공유하고 싶습니다.
나머지 API를 사용하여 마이크로 서비스 아키텍처를 구축 중입니다. 나머지 GET 서비스가 있으며 요청 매개 변수를 기반으로 백엔드 시스템에서 데이터를 수집합니다.
나머지 API 디자인 문서를 따르고 쿼리 조건에 맞는 데이터가 없을 때 완벽한 JSON 오류 메시지와 함께 HTTP 404를 클라이언트에 다시 보냈습니다 (예 : 0 레코드 선택).
클라이언트로 전송할 데이터가 없을 때 내부 오류 코드 등을 포함한 완벽한 JSON 메시지를 준비하여 "Not Found"의 이유를 클라이언트에게 알리고 HTTP 404를 사용하여 클라이언트로 다시 보냈습니다. 잘 작동합니다.
나중에 HTTP 통신 관련 코드를 숨기는 쉬운 도우미 인 나머지 API 클라이언트 클래스를 만들었으며 코드에서 나머지 API를 호출 할 때이 도우미를 항상 사용했습니다.
그러나 HTTP 404에는 두 가지 기능이 있기 때문에 혼란스러운 추가 코드를 작성해야했습니다.
- 제공된 URL에서 나머지 API를 사용할 수없는 경우 실제 HTTP 404는 나머지 API 응용 프로그램이 실행되는 응용 프로그램 서버 또는 웹 서버에서 발생합니다.
- 클라이언트는 쿼리의 위치 조건에 따라 데이터베이스에 데이터가없는 경우에도 HTTP 404를 가져옵니다.
중요 : 내 나머지 API 오류 처리기는 백엔드 서비스에 나타나는 모든 예외를 포착합니다. 즉, 오류가 발생하면 나머지 API는 항상 메시지 세부 정보가 포함 된 완벽한 JSON 메시지로 반환됩니다.
이것은 두 가지 다른 HTTP 404 응답을 처리하는 클라이언트 도우미 메소드의 첫 번째 버전입니다.
public static String getSomething(final String uuid) {
String serviceUrl = getServiceUrl();
String path = "user/" + , uuid);
String requestUrl = serviceUrl + path;
String httpMethod = "GET";
Response response = client
.target(serviceUrl)
.path(path)
.request(ExtendedMediaType.APPLICATION_UTF8)
.get();
if (response.getStatus() == Response.Status.OK.getStatusCode()) {
// HTTP 200
return response.readEntity(String.class);
} else {
// confusing code comes here just because
// I need to decide the type of HTTP 404...
// trying to parse response body
try {
String responseBody = response.readEntity(String.class);
ObjectMapper mapper = new ObjectMapper();
ErrorInfo errorInfo = mapper.readValue(responseBody, ErrorInfo.class);
// re-throw the original exception
throw new MyException(errorInfo);
} catch (IOException e) {
// this is a real HTTP 404
throw new ServiceUnavailableError(response, requestUrl, httpMethod);
}
// this exception will never be thrown
throw new Exception("UNEXPECTED ERRORS, BETTER IF YOU DO NOT SEE IT IN THE LOG");
}
그러나 Java 또는 JavaScript 클라이언트가 두 가지 종류의 HTTP 404를 수신 할 수 있기 때문에 HTTP 404의 경우 응답 본문을 확인해야합니다. 응답 본문을 구문 분석 할 수 있으면 응답이있는 곳에서 응답을 얻었습니다. 클라이언트에게 다시 보낼 데이터가 없습니다.
응답을 파싱 할 수 없다면 웹 서버 (나머지 API 응용 프로그램이 아닌)에서 실제 HTTP 404를 다시 가져 왔습니다.
너무 혼란스럽고 클라이언트 응용 프로그램은 항상 HTTP 404의 실제 이유를 확인하기 위해 추가 구문 분석을 수행해야합니다.
솔직히 나는이 솔루션을 좋아하지 않습니다. 혼란스럽고 항상 고객에게 여분의 헛소리 코드를 추가해야합니다.
따라서이 두 가지 시나리오에서 HTTP 404를 사용하는 대신 다음을 수행하기로 결정했습니다.
- 더 이상 나머지 응용 프로그램에서 HTTP 404를 응답 HTTP 코드로 사용하지 않습니다.
- HTTP 404 대신 HTTP 204 (No Content)를 사용하려고합니다.
이 경우 클라이언트 코드가 더 우아해질 수 있습니다.
public static String getString(final String processId, final String key) {
String serviceUrl = getServiceUrl();
String path = String.format("key/%s", key);
String requestUrl = serviceUrl + path;
String httpMethod = "GET";
log(requestUrl);
Response response = client
.target(serviceUrl)
.path(path)
.request(ExtendedMediaType.APPLICATION_JSON_UTF8)
.header(CustomHttpHeader.PROCESS_ID, processId)
.get();
if (response.getStatus() == Response.Status.OK.getStatusCode()) {
return response.readEntity(String.class);
} else {
String body = response.readEntity(String.class);
ObjectMapper mapper = new ObjectMapper();
ErrorInfo errorInfo = mapper.readValue(body, ErrorInfo.class);
throw new MyException(errorInfo);
}
throw new AnyServerError(response, requestUrl, httpMethod);
}
이것이 문제를 더 잘 처리한다고 생각합니다.
더 나은 솔루션이 있으면 공유하십시오.