스키마없는 JSON 형식과 같이 API를 통해 객체를 전송할 때 존재하지 않는 문자열 속성을 반환하는 이상적인 방법은 무엇입니까? 아래 나열된 링크의 예와 같이 다른 방법으로이 작업을 수행 할 수 있습니다.

• null을 피하십시오
• null을 반환
• 빈 속성 제거

나는 과거에 null을 사용했다고 확신하지만 그렇게 할 이유가 없습니다. 데이터베이스를 다룰 때 null을 사용하는 것이 당연합니다. 그러나 데이터베이스는 API의 다른 쪽 당사자와 관련해서는 안되는 구현 세부 사항처럼 보입니다. 예를 들어 값이 null 인 속성 만 저장하는 스키마가없는 데이터 스토어를 사용하고있을 것입니다.

코드 관점에서 문자열 함수를 한 유형 (예 string: 널 아님)으로 만 작동하도록 제한 하면 쉽게 증명할 수 있습니다. null을 피하는 것도 Option객체 를 갖는 이유입니다 . 따라서 요청 / 응답을 생성하는 코드가 null을 사용하지 않으면 API의 반대쪽에있는 코드도 null을 사용하지 않아야합니다.

나는 null을 사용하지 않는 쉬운 방법으로 빈 문자열을 사용하는 아이디어를 좋아합니다. null을 사용하고 빈 문자열에 대해 들었던 한 가지 주장은 빈 문자열은 속성이 존재한다는 것을 의미합니다. 차이점을 이해하지만 그것이 구현의 세부 사항인지 여부와 null 또는 빈 문자열을 사용하여 실제 차이를 만드는지 궁금합니다. 빈 문자열이 빈 배열과 비슷한 지 궁금합니다.

그렇다면 이러한 문제를 해결하는 가장 좋은 방법은 무엇입니까? 전송되는 객체의 형식 (스키마 / 스키마 없음)에 따라 달라 집니까?

TLDR; null 속성 제거

가장 먼저 염두에 두어야 할 것은 가장자리에있는 응용 프로그램 이 객체 지향적 이지 않다는 것입니다 (해당 패러다임에서 프로그래밍하는 경우에는 기능 이 아님 ). 받는 JSON은 객체가 아니므로 그렇게 취급해서는 안됩니다. 그것은 단지 객체로 변환되거나 변환되지 않는 구조화 된 데이터입니다. 일반적으로 들어오는 JSON은 유효성이 검증 될 때까지 비즈니스 오브젝트로 신뢰되지 않아야합니다. 역 직렬화되었다는 사실만으로는 유효하지 않습니다. JSON에는 백엔드 언어에 비해 프리미티브가 제한되어 있기 때문에 수신 데이터에 대해 JSON 정렬 DTO 를 만드는 것이 좋습니다. 그런 다음 DTO를 사용하여 API 조작을 실행하기위한 비즈니스 오브젝트 (또는 오류 시도)를 구성하십시오.

JSON을 전송 형식으로 볼 때 설정되지 않은 속성을 생략하는 것이 더 좋습니다. 전선을 통해 전송하는 것이 적습니다. 백엔드 언어가 기본적으로 null을 사용하지 않는 경우 오류를 발생 시키도록 deserializer를 구성 할 수 있습니다. 예를 들어, Newtonsoft.Json에 대한 공통 설정은 null / missing 속성을 F # option형식으로 만 변환하고 그렇지 않으면 오류가 발생합니다. 이것은 어떤 필드가 선택적인지에 대한 자연스러운 표현을 제공합니다 ( option유형).

항상 그렇듯이 일반화는 지금까지만 가능합니다. 기본 또는 null 속성이 더 적합한 경우가 있습니다. 그러나 핵심은 시스템 가장자리의 데이터 구조를 비즈니스 객체로 보는 것이 아닙니다. 비즈니스 오브젝트는 성공적으로 작성 될 때 비즈니스 보증 (예 : 이름을 3 자 이상)해야합니다. 그러나 데이터 구조가 완전히 보장되지는 않습니다.

업데이트 : 혼란을 초래할 수 있기 때문에 답변을 약간 편집했습니다.

빈 문자열로가는 것은 결정적인 숫자입니다. 빈 문자열은 여전히 ​​값이며 단지 비어 있습니다. 아무것도 나타내는 구성을 사용하여 값을 표시해서는 안됩니다 null.

API 개발자의 관점에서 볼 때 두 가지 유형의 속성 만 있습니다.

• 필수 (이들은 특정 유형의 값을 가져야하며 절대로 비워서는 안 됨)
• 선택 사항입니다 (이러한 유형의 값을 포함 할 수도 있지만를 포함 할 수도 있습니다) null.

이것은 재산이 의무적 일 때 즉, 명백하다는 것을 분명히한다. 필요하지 않습니다 null.

반면에 객체의 선택적 속성을 설정하지 않고 비워두면 null값이 있는 응답으로 유지하는 것이 좋습니다 . 내 경험상 API 클라이언트가 속성이 실제로 존재하는지 여부를 확인할 필요가 없기 때문에 API 클라이언트가 구문 분석을 더 쉽게 수행 할 수 있습니다. 항상 존재하기 때문에 응답을 사용자 정의 DTO로 변환하여 null값을 처리 할 수 있습니다. 선택적으로.

클라이언트의 추가 조건을 포함하여 응답력에서 필드를 동적으로 포함 / 제거합니다.

어느 쪽을 선택하든 일관성있게 문서화해야합니다. 그렇게하면 동작이 예측 가능한 한 API에 사용하는 것이 중요하지 않습니다.

null 사용법은 응용 프로그램 / 언어에 따라 다름

궁극적 null으로 유효한 응용 프로그램 값 으로 사용할지 여부 는 응용 프로그램 및 프로그래밍 언어 / 인터페이스 / 에지에 따라 결정됩니다.

기본적으로 고유 한 값 클래스가있는 경우 고유 한 유형을 사용하는 것이 좋습니다. null인터페이스에서 허용하고 표시하려는 속성의 클래스가 두 개만있는 경우 옵션이 될 수 있습니다. 인터페이스 나 형식에서 허용하는 경우 속성을 생략해도됩니다. 새로운 집계 유형 (클래스, 객체, 메시지 유형)이 다른 옵션 일 수 있습니다.

문자열 예제의 경우 이것이 프로그래밍 언어 인 경우 몇 가지 질문을합니다.

1. 향후 유형의 값을 추가 할 계획입니까? 그렇다면 Option인터페이스 디자인에 더 좋을 것입니다.
2. 소비자 통화의 유효성을 언제 확인해야합니까? 정적으로? 동적으로? 전에? 후? 조금도? 프로그래밍 언어에서 지원하는 경우 유효성 검사를 위해 작성해야하는 코드 양을 피할 수 있으므로 정적 입력의 이점을 사용하십시오. Option문자열이 null이 아닌 경우이 경우를 가장 잘 채울 수 있습니다. 그러나 null어쨌든 사용자 입력에서 문자열 값 을 확인해야 할 것이므로 첫 번째 질문 줄로 다시 돌아 가야 할 것입니다. 얼마나 많은 유형의 값을 나타내고 싶습니까?
3. 가 null내 프로그램 언어의 프로그래머 오류를 나타내는? 불행하게도, null일부 언어에서 초기화되지 않은 (또는 명시 적으로 초기화되지 않은) 포인터 또는 참조의 기본값이 종종 있습니다. 가 null기본 값으로 허용되는 값으로? 그것은이다 안전 기본 값으로? 때때로 null할당 해제 된 값을 나타냅니다. 인터페이스 소비자에게 프로그램에서 이러한 잠재적 메모리 관리 또는 초기화 문제에 대한 표시를 제공해야합니까? 그러한 문제에 직면했을 때 그러한 통화의 실패 모드는 무엇입니까? 호출자가 광산과 동일한 프로세스 또는 스레드에있어 그러한 오류가 내 응용 프로그램에 높은 위험을 줄 수 있습니까?

이러한 질문에 대한 답변에 따라 null인터페이스에 적합한 지 여부를 결정할 수 있습니다.

실시 예 1

1. 어플리케이션은 안전에 중요합니다
2. 시작시 일부 유형의 힙 초기화를 사용하고 null있으며 문자열에 공간을 할당하지 못한 경우 다시 전달 될 수있는 문자열 값입니다.
3. 그러한 문자열이 인터페이스에 부딪 칠 가능성이 있습니다.

답 : null아마 적절하지 않습니다

이론적 근거 : null이 경우 실제로 두 가지 유형의 값을 나타내는 데 사용됩니다. 첫 번째는 인터페이스 사용자가 설정하고자하는 기본값 일 수 있습니다. 불행하게도, 두 번째 값은 시스템이 올바르게 작동하지 않음을 나타내는 플래그입니다. 이러한 경우 가능한 한 안전하게 (시스템에 의미가있는) 실패하려고합니다.

실시 예 2

1. char *멤버 가있는 C 구조체를 사용하고 있습니다.
2. 시스템은 힙 할당을 사용하지 않으며 MISRA 검사를 사용하고 있습니다.
3. 인터페이스는이 구조체를 포인터로 받아들이고 구조체가 가리 키지 않는지 확인합니다. NULL
4. char *API 멤버 의 기본 및 안전한 값은 단일 값으로 표시 될 수 있습니다.NULL
5. 사용자의 구조체 초기화시 char *멤버를 명시 적으로 초기화하지 않을 가능성을 사용자에게 제공하려고합니다 .

답 : NULL적절할 수 있습니다

근거 : 구조체가 NULL검사를 통과 했지만 초기화되지 않은 경우는 거의 없습니다 . 그러나 구조체 값에 대한 체크섬 및 / 또는 구조체 주소의 범위 확인이 없으면 API가이를 설명하지 못할 수 있습니다. MISRA-C 린 터는 초기화 전에 구조체 사용을 플래그 지정하여 API 사용자를 도울 수 있습니다. 그러나 char *멤버의 경우 구조체에 대한 포인터가 초기화 된 구조체를 가리키는 경우 NULL구조체 초기화 프로그램에서 지정되지 않은 멤버의 기본값입니다. 따라서 애플리케이션에서 구조체 멤버 NULL의 안전한 기본값으로 사용될 수 있습니다 char *.

직렬화 인터페이스에있는 경우 문자열에서 null을 사용할지 여부에 대해 다음과 같은 질문을합니다.

1. 가 null잠재적 인 클라이언트 측 오류를 나타내는? JavaScript의 JSON null의 경우 할당 실패를 나타내는 데 반드시 필요한 것은 아니므 로 아마도 아니요 입니다. JavaScript에서는 문제가있는 참조에서 객체가 없음을 명시 적으로 나타내는 데 사용됩니다. 그러나 JSON null을 기본 null유형에 매핑하는 비 JavaScript 파서 및 직렬 변환기가 있습니다 . 이 경우 null특정 언어, 파서 및 시리얼 라이저 조합에 기본 사용법이 적합한 지 여부에 대한 논의를 요구합니다 .
2. 속성 값이 명시 적으로 없으면 단일 속성 값 이상에 영향을 줍니까? 때로는 a null는 실제로 새 메시지 유형이 있음을 나타냅니다. 직렬화 형식의 소비자가 완전히 다른 메시지 유형을 지정하는 것이 더 깨끗할 수 있습니다. 이를 통해 유효성 검사 및 응용 프로그램 논리가 웹 인터페이스가 제공하는 두 가지 메시지를 명확하게 분리 할 수 ​​있습니다.

일반적인 조언

null이를 지원하지 않는 에지 또는 인터페이스의 값이 될 수 없습니다. 속성 값 (예 : JSON)을 입력 할 때 본질적으로 매우 느슨한 것을 사용하는 경우 가능한 경우 소비자 엣지 소프트웨어 (예 : JSON 스키마 ) 에서 스키마 또는 유효성 검사를 시도하십시오 . 프로그래밍 언어 API 인 경우 가능한 경우 (입력을 통해) 또는 런타임에 감지 할 수있을 정도로 크게 ( 사용자 인터페이스에 대한 방어 프로그래밍 ) 사용자 입력을 정적으로 확인합니다 . 중요하게도, 가장자리를 문서화하거나 정의하여 다음과 같은 의문의 여지가 없습니다.

• 특정 속성이 허용하는 유형의 가치
• 주어진 속성에 유효한 값 범위
• 집계 유형을 구성하는 방법 집계 유형에는 어떤 속성이 있어야합니까?
• 컨테이너 유형 인 경우 컨테이너가 보유 할 수있는 항목 수와 컨테이너가 보유하는 값의 유형은 무엇입니까?
• 컨테이너 또는 집계 유형의 속성 또는 인스턴스가 반환되는 순서는 무엇입니까?
• 특정 값을 설정하면 어떤 부작용이 발생하며 해당 값을 읽을 때의 부작용은 무엇입니까?

여기에 이러한 질문에 대한 개인적 분석이 있습니다. 그것은 어떤 책, 종이, 연구 또는 내 개인적인 경험으로 뒷받침되지 않습니다.

빈 문자열 null

이것은 나에게 아무런 문제가되지 않습니다. 빈 문자열의 의미와 정의되지 않은 문자열의 의미를 혼합하지 마십시오. 많은 경우에 그것들은 완벽하게 상호 교환 가능할 수 있지만 정의되지 않고 정의되었지만 비어있는 것이 다른 것을 의미하는 경우가 발생할 수 있습니다.

일종의 어리석은 예 : 외래 키를 저장하는 속성이 있고 해당 속성이 정의되지 않았거나 또는 정의되어 null있음을 의미한다고 가정 해 봅시다 . 빈 문자열 ""은 정의 된 관계로 이해 될 수 있습니다. 외부 레코드의 ID는 빈 문자열입니다.

정의되지 않음 vs null

이것은 흑백 주제가 아닙니다. 두 가지 접근 방식에는 장단점이 있습니다.

명시 적으로 null값을 정의하기 위해 다음과 같은 장점이 있습니다.

• 메시지는 메시지를 보면서 모든 키를 알 수 있다는 점에서 더 자기 설명 적입니다.
• 이전 요점과 관련하여 데이터 소비자의 오류를 코딩하고 감지하는 것이 더 쉽습니다. 잘못된 키를 가져 오면 철자가 틀리거나 API가 변경되었을 수 있습니다.

존재하지 않는 키는 null다음 의 의미와 같다고 가정합니다 .

• 일부 변경 사항은 수용하기가 더 쉽습니다. 예를 들어, 새 버전의 메시지 스키마에 새 키가 포함 된 경우 메시지 생성자가 업데이트되지 않았고 아직이 정보를 제공하지 않는 경우에도이 미래 키를 사용하도록 정보 소비자를 코딩 할 수 있습니다.
• 메시지가 덜 간결하거나 짧을 수 있습니다

API가 어떻게 든 안정적이며 철저하게 문서화하는 경우 존재하지 않는 키가의 의미와 같다는 것을 언급하는 것이 null좋습니다. 그러나 그것이 더 혼란스럽고 혼란 스럽다면 (매우 자주있는 것처럼) 모든 메시지에서 모든 값을 명시 적으로 정의하면 두통을 피할 수 있다고 생각합니다. 즉, 의심스러운 경우 자세한 접근 방식을 따르는 경향이 있습니다.

무엇보다도, 가장 중요한 것은 의도를 명확하게 설명하고 일관성을 유지하는 것입니다. 여기서 하나는저기서는하지 마십시오. 예측 가능한 소프트웨어가 더 나은 소프트웨어입니다.

문자열이있는 상황에서 빈 문자열을 제공하고 빈 문자열이됩니다. 명시 적으로 "이 데이터가 없습니다"라고 말하고 싶은 상황에서 null을 제공합니다. "데이터가없고 귀찮게하지 마십시오"라고 말하는 키를 생략하십시오.

이러한 상황 중 어떤 것이 일어날 수 있는지 판단합니다. 애플리케이션에 빈 문자열이있는 것이 합리적입니까? 널을 사용하여 명시 적으로 "데이터 없음"이라고 말하고 값이없는 것으로 암시 적으로 구별하고 싶습니까? 클라이언트가 둘을 구별해야하는 경우에는 두 가지 가능성 만 있어야합니다 (널이 있고 키가 없음).

이제 이것은 데이터 전송에 관한 것임을 명심하십시오. 수신자가 데이터를 사용하여 수행하는 작업은 비즈니스이며 가장 편리한 작업을 수행합니다. 리시버 는 충돌없이 던지는 모든 것을 처리 할 수 ​​있어야합니다 (아마도 데이터를 거부함으로써).

다른 고려 사항이 없으면 보낸 사람에게 가장 편리한 것을 전송하고 문서화 합니다. JSON의 인코딩, 전송 및 구문 분석 속도를 향상시킬 수 있기 때문에 부재 한 값을 보내지 않는 것이 좋습니다.

최선의 것을 말할 수는 없지만 단순한 구현 세부 사항 은 아니지만 확실하게 변수와 상호 작용하는 방법의 구조를 변경합니다.

무언가 가 null 일 수있는 경우 항상 어느 시점에서 null 인 것처럼 취급해야 하므로 항상 2 개의 워크 플로가 있습니다 . 하나는 null이고 다른 하나는 유효한 문자열입니다. 분할 오류 워크 플로는 유용 할 수있는 약간의 오류 처리 및 특수한 경우가 있기 때문에 반드시 나쁜 것은 아니지만 코드를 난독 처리합니다.

당신이 경우 항상 상호 작용하는 것과 같은 방식으로 문자열 아마의 기능에 대한 더 쉬울 것이다 당신의 머리에서 숙박 .

그래서 내가 대답으로 남아있어 어떤 "무엇 최고"질문과 같은 : 그것은 의존한다 . 워크 플로를 분할하고 무언가가 설정되지 않은 경우보다 명시 적으로 캡처하려면 null을 사용하십시오. 오히려 프로그램이 계속 그렇게하려면 빈 문자열을 사용하십시오. 중요한 것은 당신이 일관 되고 공통의 수익을 선택하고 그것에 충실한다는 것입니다.

당신이 API를 작성하는 고려, 내가 추천 할 것입니다 빈 문자열로 고집 사용자가 있기 때문에, 보상하기 위해 더 적은 거기로 나는 당신의 API가 나에게 널 (null) 값을 줄 수있는 모든 이유를 알 수 없습니다하는 API의 사용자로 '당신이하지 않는 한을 문서화가 잘되어있어 일부 사용자는 읽을 수 없습니다.

문서!

TL; DR>

적합하다고 생각되는대로, 때로는 그것이 사용되는 상황이 중요합니다. 예, 변수를 Oracle SQL에 바인드 : 빈 문자열은 NULL로 해석됩니다.

간단히 말하겠습니다-언급 된 각 시나리오를 문서화하십시오

• 없는
• 공백 (빈)
• 누락 (제거)

코드가 다른 방식으로 작동 할 수 있습니다. 코드가 어떻게 반응하는지 문서화하십시오.

• 실패 (예외 등), 유효성 검사에 실패하거나 (확인 된 예외 일 수 있음) 상황을 올바르게 처리 할 수 ​​없습니다 (NullPointerException).
• 합리적인 기본값 제공
• 코드가 다르게 동작

그런 다음 그 외에도-일관되게 행동하고 자신의 모범 사례를 채택하는 것은 귀하의 몫입니다. 일관된 행동을 문서화하십시오. 예 :

• 널 처리 및 누락
• 빈 문자열을 그대로 취급하십시오. SQL 바인드의 경우에만 공백으로 간주 될 수 있습니다. SQL이 일관되고 예상 된 방식으로 작동하는지 확인하십시오.

tl; dr-사용하는 경우 의미가 일관성이 있어야합니다.

포함했다면 null무슨 뜻입니까? 의미하는 바에는 우주가 있습니다. 하나의 값만으로는 누락되거나 알 수없는 값을 나타내기에 충분하지 않습니다 (이 값은 무수한 가능성 중 두 가지에 불과합니다. 예 : 누락-측정되었지만 아직 알 수 없음. 알 수 없음-측정하지 않았습니다) 그것.)

내가 최근에 접한 예에서, 누군가의 개인 정보를 보호하는 것으로보고되지 않았기 때문에 필드가 비어있을 수 있지만 발신자 측에 알려졌지만 발신자 측에 알려지지 않았지만 원래 기자에게 알려 지거나 둘 다에 알려지지 않았습니다. 그리고이 모든 것들이 수신자에게 중요했습니다. 따라서 일반적으로 하나의 값으로는 충분하지 않습니다.

개방 된 세계 가정 (단지 언급되지 않은 사항에 대해 알지 못함)을 그대로두면 아무 것도 될 수 있습니다. 닫힌 세계 가정 (예를 들어 SQL에서 언급되지 않은 것은 거짓 임)을 사용하면 null의미를 명확하게 하고 가능한 한 그 정의와 일관성을 유지하는 것이 좋습니다 ...