SOAP 오류 또는 결과 개체?
동료 와이 문제에 논의하고 있었는데 이미 이르지 논의하고 있습니다. 나는 이것에 대한 내 의견을 가지고 있다고 생각합니다.
SOAP 오류를 반환 해야하는시기와 오류 정보가 있는 결과 개체 를 반환해야하는시기는 언제 입니까? 이는 다양한 시스템 (.NET, Java 등)에서 사용할 수있는 일반 웹 서비스에 대한 가정합니다. 결과에는 오류 플래그, errorType (특별한 예외 유형과 유사) 및 메시지가 있습니다.
시기 할 몇 가지 사항 :
- 데이터 유효성 검사 오류가 결함입니까?
- 오류 (매우 예외적 인 경우)와 결과 개체 ( "예상 된"오류의 경우)의 조합이있을 때?
- SOAP를 어떻게 그룹화 할 것인지 (중요 [null 참조] 대 유효성 검사 [우편 번호])?
- Fail-fast vs 오류 확인을 기억해야 함
- 모범 사례, 패턴, 표준 등
기사 링크가 유효합니다. 내가 당신의 의견을 원하는 것 같지만 사실을 고수하십시오 (y와 z 때문에 x가 더 좋습니다 ...)
대부분의 SOAP 클라이언트는 오류를 실행 예외로 변환합니다 (클라이언트 언어가 지원하는 경우). "오류를 염두에두고"오류 값을 반환하는 대신 예외를 던지고 싶습니까? "라는 질문을 다시 표현할 수 있다고 생각합니다. 일반적으로 해당 API 디자인과 해당 주제에 대한 많은 의견을있을 것입니다.
즉, 오류를 반환하는 것이 일반적으로 클라이언트에게 도움이되지 않습니다.
클라이언트는 오류 코드를 수동으로 열거하고 처리해야하지만 스텁 코드가 적절한 유형의 예외를 생성하고 던지도록 허용해야합니다. 오류 코드를 사용하면 클라이언트가 수퍼 클래스에 의한 예외 처리와 같은 객체 지향 기술을 사용하지 않습니다.
WSDL의 일부로 오류 코드를 작성하지; 클라이언트는 자신이 무엇인지 또는 언제 발생하는지에 대한 문서가 없습니다. 유형이 지정된 오류는 WSDL의 일부로 (제한적으로) 자체 문서화됩니다.
오류 메시지에는 클라이언트가 오류보고 및 복구에 사용할 수있는 오류 관련가 있습니다. 예를 들어 실제 유효하지 않은 입력 요소와 이유가 포함 된 입력 유효성 검사 오류를 수정했습니다. 오류 코드와 불투명 한 많은이 포함 된 결과를 반환하는 경우 클라이언트는 오류 메시지를 사용자에게 많은 수밖에는 이로 인해 국제화, UI 일관성 등이 깨집니다.
구체적인 질문에 답 :
유효성 검사 오류는 결함입니다. AJAX 클라이언트에서 웹 서비스를 호출 오류 처리 기능이 상상해. 서비스가 예상치 못한 응답과 함께 400 성공 코드가 아닌 5xx HTTP 코드를 반환하기를 원합니다.
아니요. API는 일관된 오류보고 인터페이스를 제공해야합니다. WSDL 디자인은 API 디자인입니다. 클라이언트가 두 개의 고유 한 오류 처리기를 구현하도록 강요 준비하는 클라이언트의 삶이 더 많은 것을 지원합니다.
결함 설계는 요청 / 응답 모델을 반영하고 서비스 추상화에 많은 정보를 표시해야합니다. NullReference 오류를 설계하지 않습니다. XYZServiceRuntimeFault를 설계하십시오. 클라이언트가 잘못된 요청을 자주 제공하는 경우 클라이언트가 잘못된 데이터가있는 위치를 신속하게 제공 할 수 있습니다.
결과 개체는 결과 만 포함해야합니다. 결과 개체가 다른 시스템에서 오류 플래그 목록을 제공하는 경우에 "isError"가 발생합니다. 유효하지 않은 결과가 유효하거나 유효하지 않습니다.
오류가 발생하면 항상 SOAPFault를 발생합니다. 유효성 검사는 오류이며 유효성 검사가 데이터베이스를 열 수없는 것보다 덜 심각하게 생각하는 것은 악마의 함정입니다. 두 경우 모두 동일한 영향을 미칩니다. 요청 한대로 작업을 완료 할 수 없습니다.
따라서 유효한 결과 개체를 사용하고있는 경우에는 SOAP 오류를 발생합니다. 오류, 유효성 검사 실패, 경고, 버스 오류 등을 포함하되 이에 국한되지 않습니다.
예외가 발생하기 전날에는 선택의 여지가 없었고 결과적으로 많은 API가 일관성이 없었고 대부분의 API는 오류를 반환하는 방법이 달랐습니다. 각 API 항목이 오류를 반환하는 방법과 종종 더 많이 사용하는 방법을 찾아야하기 때문에 끔찍하고 혼란스럽고 개발 속도가 끔찍하고 혼란 스럽습니다.
SOAPFaults / Exceptions로 유효성 검사를 처리하는 것은 생각할 때 더 많은 것이 일단 생각해 보면 일반적으로 더 많은 것입니다. 원래 요청을 필요로하지 않는 방식으로 문제가 발생하는 요소를 발견하는 데 충분한 정보를 포함하는 유효성 검사 클래스를 디자인해야합니다. 이렇게하면 유효성 검사 오류를 일반적으로 처리 할 수 있습니다.
결과 개체에 오류가 포함되어있는 경우, 예를 들어 창고에있는 누군가가 재고 관리 영역 이 있기 때문에 제품이 품절되었습니다 .
심각한 오류와 유효성 검사 오류를 구분하는 것은 현명하지 않습니다. 심각도 수준의 할당은 매우 주관적이기 때문에 제 생각에는 유효한 비교가 아닙니다. 예를 들어, 화학 물질에 대한 정보를 소방관에게 제공하는 시스템에서 위험은 화재 트럭이 경고 그래픽을로드하려고 할 때 null 참조가 아닌 UN 1298 및 UN 1436을 운반하고 있음을 의미 할 수 있습니다.
결함을 간결하게 포토하고 그에 따라 처리 할 수 있도록 결함을 설계하십시오. 충분한 정보를 전달하는지 확인하십시오. Abritrary 분류는 결함 자체를 보유 할 수 있기 때문에 충분한 정보를 얻었을 때 결함이 있습니다.
예외로 전환 된 SOAPFault는 가장 확실한 방법입니다.
모범 사례, 참조 등
클라이언트가 결과로 반환 된 오류를 처리 할 준비가되어 있다는 것을 알지 못한다면 짧은 대답은 비누 오류를 사용하는 것입니다. 나는 또한 다른 답변에서 언급했듯이 예외와 오류 결과 사이의 비유를 생각했습니다.
클라이언트의 요구에 따라 예외 및 결과 오류로 합리적으로 처리 될 수있는 회색 영역이 있습니다. 그런 다음 이러한 유형의 오류가 반환되는 방식을 변경하는 매개 변수를 서비스에 제공 할 수 있습니다. 기본값은 SOAP 오류를 사용하는 것이지만 클라이언트가 오류 결과를 얻기 위해 매개 변수를 설정하면 결과의 일부로이를 처리 할 의사가 있음을 나타냅니다. 저에게는 유효성 검사 오류가이 회색 영역에 있습니다. 대부분의 클라이언트의 경우 결함으로 간주되어야하지만 클라이언트가 데이터를 사용하여 UI에 유효성 검사 오류를 마크 업하려는 경우 결과의 일부로 유효성 검사 오류를 반환하는 것이 더 유용 할 수 있습니다.
서비스 설계에서 따르는 규칙은 다음과 같습니다.
- 응답 개체에 대한 비즈니스 수준 응답 (비즈니스 예외 포함)
- Soap Fault에 대한 기술 / 통합 수준 오류
서비스 소비자는 모든 종류의 비즈니스 응답이 응답 개체로 제공되어 서비스 (비즈니스) 사용자에게 제공된다는 것을 신뢰할 수 있습니다. Soap Fault는 비즈니스 응답을 전달할 수없는 경우에만 사용됩니다.
Soap Faults는 모니터링을 통해 지원 경고 / 조치를 트리거해야합니다.
참고 URL : https://stackoverflow.com/questions/2823100/soap-faults-or-results-object
'ProgramingTip' 카테고리의 다른 글
| NSManagedObjectContext를 생성 한 단일 또는 큐가 소유하고 Apple이 말하는 것은 무엇을 의미합니까? (0) | 2020.12.05 |
|---|---|
| 일대일 최대 수용 모드 : 전체 객체를 가져 오지 않고 getId () (0) | 2020.12.04 |
| 파일 열기 대화 상자를 사용하여 폴더를 선택할 수 있습니까? (0) | 2020.12.04 |
| data.frame 또는 대규모 행 행 (0) | 2020.12.04 |
| 자바 펼쳐에서 클래스 클래스 속성을 추가 할 수없는 이유는 무엇입니까? (0) | 2020.12.04 |