Saat mentransfer objek melalui API, seperti dalam format JSON schemaless, apa cara ideal untuk mengembalikan properti string yang tidak ada? Saya tahu bahwa ada berbagai cara untuk melakukan ini seperti dalam contoh di tautan yang tercantum di bawah ini.

• Hindari nol
• Kembali nol
• Hapus properti kosong

Saya yakin saya telah menggunakan null di masa lalu tetapi tidak memiliki alasan yang baik untuk melakukan itu. Tampaknya lurus ke depan untuk menggunakan null ketika berhadapan dengan database. Tetapi basis data tampak seperti detail implementasi yang tidak seharusnya menjadi perhatian pihak di sisi lain API. Misalnya mereka mungkin menggunakan datastore schemaless yang hanya menyimpan properti dengan nilai (non-null).

Dari sudut pandang kode, membatasi fungsi string hanya berfungsi dengan satu jenis, yaitu string(bukan nol), membuatnya lebih mudah untuk dibuktikan; menghindari nol juga merupakan alasan untuk memiliki Optionobjek. Jadi, jika kode yang menghasilkan permintaan / respons tidak menggunakan null, tebakan saya adalah kode di sisi lain API tidak akan dipaksa untuk menggunakan null juga.

Saya lebih suka ide menggunakan string kosong sebagai cara mudah untuk menghindari menggunakan null. Satu argumen yang saya dengar untuk menggunakan null dan terhadap string kosong adalah bahwa string kosong berarti properti itu ada. Meskipun saya memahami perbedaannya, saya juga bertanya-tanya apakah itu hanya detail implementasi dan apakah menggunakan string kosong atau kosong akan membuat perbedaan nyata. Saya juga bertanya-tanya apakah string kosong analog dengan array kosong.

Jadi, mana cara terbaik untuk melakukannya yang mengatasi masalah itu? Apakah itu tergantung pada format objek yang ditransfer (skema / skema)?

TLDR; Hapus properti nol

Hal pertama yang perlu diingat adalah bahwa aplikasi di tepi mereka tidak berorientasi objek (atau fungsional jika pemrograman dalam paradigma itu). JSON yang Anda terima bukan objek dan tidak boleh diperlakukan seperti itu. Itu hanya data terstruktur yang dapat (atau mungkin tidak) dikonversi menjadi objek. Secara umum, JSON yang masuk tidak boleh dipercaya sebagai objek bisnis hingga validasi. Hanya fakta bahwa itu deserialized tidak membuatnya valid. Karena JSON juga memiliki primitif terbatas dibandingkan dengan bahasa back-end, sering layak untuk membuat DTO yang selaras JSON untuk data yang masuk. Kemudian gunakan DTO untuk membangun objek bisnis (atau kesalahan mencoba) untuk menjalankan operasi API.

Ketika Anda melihat JSON hanya sebagai format transmisi, lebih masuk akal untuk menghilangkan properti yang tidak disetel. Lebih sedikit mengirim melalui kawat. Jika bahasa back-end Anda tidak menggunakan nulls secara default, Anda mungkin dapat mengkonfigurasi deserializer Anda untuk memberikan kesalahan. Sebagai contoh, pengaturan umum saya untuk Newtonsoft.Json menerjemahkan properti null / missing hanya ke / dari optiontipe F # dan jika tidak akan terjadi kesalahan. Ini memberikan representasi alami bidang mana yang opsional (yang optionbertipe).

Seperti biasa, generalisasi hanya membuat Anda sejauh ini. Mungkin ada kasus di mana properti default atau null lebih cocok. Tetapi kuncinya adalah tidak melihat struktur data di tepi sistem Anda sebagai objek bisnis. Objek bisnis harus membawa jaminan bisnis (mis. Nama setidaknya 3 karakter) ketika berhasil dibuat. Tetapi struktur data yang ditarik dari kawat tidak memiliki jaminan nyata.

Pembaruan: Saya telah mengedit jawabannya sedikit, karena mungkin menyebabkan kebingungan.

Pergi dengan string kosong adalah tidak pasti. String kosong masih merupakan nilai, itu hanya kosong. Tidak ada nilai yang harus ditunjukkan menggunakan konstruk yang tidak mewakili apa pun null,.

Dari sudut pandang pengembang API, hanya ada dua jenis properti:

• wajib (ini HARUS memiliki nilai jenis spesifik mereka dan TIDAK HARUS kosong),
• opsional (MUNGKIN ini mengandung nilai dari tipe spesifik mereka tetapi MUNGKIN juga mengandung null.

Ini membuatnya cukup jelas bahwa ketika sebuah properti wajib, yaitu. diperlukan, tidak pernah bisa null.

Di sisi lain, jika properti opsional dari suatu objek tidak disetel dan dibiarkan kosong, saya lebih suka menyimpannya dalam respon dengan nullnilai. Dari pengalaman saya, ini memudahkan klien API untuk mengimplementasikan parsing, karena mereka tidak diharuskan memeriksa apakah suatu properti benar-benar ada atau tidak, karena selalu ada di sana, dan mereka dapat dengan mudah mengonversi respons ke DTO khusus mereka, memperlakukan nullnilai-nilai sebagai opsional.

Termasuk / menghapus bidang secara dinamis dari kekuatan respons termasuk kondisi tambahan pada klien.

Apa pun caranya, apa pun yang Anda pilih, pastikan Anda tetap konsisten dan terdokumentasi dengan baik. Dengan begitu tidak masalah apa yang Anda gunakan untuk API Anda, selama perilakunya dapat diprediksi.

null Penggunaan tergantung pada Aplikasi / Bahasa

Pada akhirnya pilihan untuk digunakan atau tidaknya nullnilai aplikasi yang valid sebagian besar ditentukan oleh aplikasi Anda dan bahasa pemrograman / antarmuka / tepi.

Pada level fundamental, saya sarankan mencoba menggunakan tipe yang berbeda jika ada kelas nilai yang berbeda. nullmungkin menjadi opsi jika antarmuka Anda mengizinkannya dan hanya ada dua kelas properti yang Anda coba wakili. Menghilangkan properti mungkin menjadi opsi jika antarmuka atau format Anda memungkinkannya. Tipe agregat baru (kelas, objek, tipe pesan) dapat menjadi pilihan lain.

Sebagai contoh string Anda, jika ini dalam bahasa pemrograman, saya akan bertanya pada diri sendiri beberapa pertanyaan.

1. Apakah saya berencana menambahkan jenis nilai di masa mendatang? Jika demikian, Optionmungkin akan lebih baik untuk desain antarmuka Anda.
2. Kapan saya perlu memvalidasi panggilan konsumen? Secara statis? Secara dinamis? Sebelum? Setelah? Sama sekali? Jika bahasa pemrograman Anda mendukungnya, gunakan manfaat pengetikan statis karena menghindari jumlah kode yang harus Anda buat untuk validasi. Optionmungkin mengisi kasus ini dengan baik jika string Anda tidak dapat dibatalkan. Namun, Anda mungkin harus memeriksa input pengguna untuk nullnilai string, jadi saya mungkin akan menunda kembali ke pertanyaan pertama: berapa banyak tipe nilai yang ingin / ingin saya wakili.
3. Apakah nullindikasi kesalahan programmer dalam bahasa pemrograman saya? Sayangnya, nullsering kali nilai default untuk petunjuk atau referensi yang tidak diinisialisasi (atau tidak diinisialisasi secara eksplisit) dalam beberapa bahasa. Apakah nullsebagai nilai dapat diterima sebagai nilai default? Apakah aman sebagai nilai default? Kadang null- kadang merupakan indikasi nilai yang tidak dialokasikan. Haruskah saya memberi konsumen antarmuka saya indikasi tentang potensi manajemen memori ini atau masalah inisialisasi dalam program mereka? Apa modus kegagalan dari panggilan seperti itu dalam menghadapi masalah seperti itu? Apakah penelepon dalam proses yang sama atau utas dengan saya sehingga kesalahan seperti itu berisiko tinggi untuk aplikasi saya?

Bergantung pada jawaban Anda atas pertanyaan-pertanyaan ini, Anda mungkin dapat mengasah apakah nullantarmuka Anda cocok atau tidak .

Contoh 1

1. Aplikasi Anda sangat penting untuk keselamatan
2. Anda menggunakan beberapa jenis inisialisasi heap pada startup dan nullkemungkinan nilai string dikembalikan setelah kegagalan mengalokasikan ruang untuk string.
3. Ada potensi string tersebut mengenai antarmuka Anda

Jawab: nullmungkin tidak tepat

Dasar Pemikiran: nulldalam hal ini sebenarnya digunakan untuk menunjukkan dua jenis nilai yang berbeda. Yang pertama mungkin merupakan nilai default yang ingin ditetapkan pengguna antarmuka Anda. Sayangnya, nilai kedua adalah tanda untuk menunjukkan bahwa sistem Anda tidak berfungsi dengan benar. Dalam kasus seperti itu, Anda mungkin ingin gagal seaman mungkin (apa pun artinya bagi sistem Anda).

Contoh 2

1. Anda menggunakan struct C yang memiliki char *anggota.
2. Sistem Anda tidak menggunakan alokasi tumpukan dan Anda menggunakan pemeriksaan MISRA.
3. Antarmuka Anda menerima struct ini sebagai penunjuk dan memeriksa untuk memastikan bahwa struct tidak menunjuk ke NULL
4. Nilai default dan aman char *anggota untuk API Anda dapat ditunjukkan dengan nilai tunggalNULL
5. Setelah inisialisasi struct pengguna Anda, Anda ingin memberikan kemungkinan kepada pengguna untuk tidak menginisialisasi char *anggota secara eksplisit .

Jawab: NULLmungkin tepat

Dasar Pemikiran: Ada sedikit kemungkinan bahwa struct Anda melewati NULLpemeriksaan tetapi tidak diinisialisasi. Namun, API Anda mungkin tidak dapat menjelaskan hal ini kecuali Anda memiliki semacam checksum pada nilai struct dan / atau rentang memeriksa alamat struct. Linter MISRA-C dapat membantu pengguna API Anda dengan menandai penggunaan struct sebelum inisialisasi mereka. Namun, untuk char *anggota, jika penunjuk ke struct menunjuk ke struct yang diinisialisasi, NULLadalah nilai default dari anggota yang tidak ditentukan dalam penginisialisasi struct. Oleh karena itu, NULLdapat berfungsi sebagai nilai default aman untuk char *anggota struct di aplikasi Anda.

Jika itu pada antarmuka serialisasi, saya akan bertanya pada diri sendiri pertanyaan berikut tentang apakah akan menggunakan null pada string.

1. Apakah nullindikasi potensi kesalahan sisi klien? Untuk JSON dalam JavaScript, ini mungkin tidak karena nulltidak selalu digunakan sebagai indikasi kegagalan alokasi. Dalam JavaScript, ini digunakan sebagai indikasi eksplisit tentang tidak adanya objek dari referensi yang akan ditetapkan bermasalah. Namun, ada parser dan serialis non-javascript di luar sana yang memetakan JSON nullke nulltipe asli . Jika ini masalahnya, ini meminta diskusi tentang apakah nullpenggunaan asli atau tidak cocok untuk kombinasi bahasa, parser, dan serializer tertentu.
2. Apakah ketiadaan nilai properti secara eksplisit berdampak lebih dari nilai properti tunggal? Kadang-kadang a nullsebenarnya menunjukkan bahwa Anda memiliki tipe pesan baru seluruhnya. Mungkin lebih bersih bagi konsumen Anda dari format serialisasi untuk hanya menentukan jenis pesan yang sama sekali berbeda. Ini memastikan bahwa validasi dan logika aplikasi mereka dapat memiliki pemisahan yang bersih antara dua perbedaan pesan yang disediakan antarmuka web Anda.

Nasihat Umum

nulltidak dapat menjadi nilai di tepi atau antarmuka yang tidak mendukungnya. Jika Anda menggunakan sesuatu yang sifatnya sangat longgar pada pengetikan nilai properti (yaitu JSON), cobalah untuk mendorong beberapa bentuk skema atau validasi pada perangkat lunak edge konsumen (mis. Skema JSON ) jika Anda bisa. Jika itu adalah bahasa pemrograman API, validasikan input pengguna secara statis jika memungkinkan (melalui pengetikan) atau sekeras yang masuk akal dalam runtime (alias praktikkan pemrograman defensif pada antarmuka yang dihadapkan konsumen). Yang terpenting, dokumentasikan atau tentukan tepi sehingga tidak ada pertanyaan tentang:

• Jenis nilai apa yang diterima properti yang diberikan
• Rentang nilai apa yang valid untuk properti yang diberikan.
• Bagaimana jenis agregat harus disusun. Properti apa yang harus / harus / dapat hadir dalam tipe agregat?
• Jika itu adalah beberapa jenis wadah, berapa banyak barang yang dapat atau harus dimiliki oleh wadah tersebut, dan apa saja jenis nilai yang dimiliki wadah tersebut?
• Bagaimana urutan, jika ada, properti atau instance dari wadah atau tipe agregat dikembalikan?
• Apa efek samping dari penetapan nilai-nilai tertentu dan apa efek samping dari membaca nilai-nilai itu?

Berikut analisis pribadi saya terhadap pertanyaan-pertanyaan ini. Itu tidak didukung oleh buku, kertas, studi atau apa pun, hanya pengalaman pribadi saya.

String kosong sebagai null

Ini adalah jalan keluar bagi saya. Jangan mencampur semantik string kosong dengan yang tidak didefinisikan. Dalam banyak kasus, mereka dapat dipertukarkan dengan sempurna, tetapi Anda dapat mengalami kasus-kasus di mana yang tidak didefinisikan dan didefinisikan tetapi kosong berarti sesuatu yang berbeda.

Semacam contoh bodoh: katakanlah ada atribut yang menyimpan kunci asing, dan atribut itu tidak didefinisikan atau sedang null, itu berarti bahwa tidak ada hubungan yang didefinisikan, sedangkan string kosong ""dapat dipahami sebagai hubungan yang didefinisikan dan ID rekaman asing adalah string kosong itu.

Tidak didefinisikan vs null

Ini bukan topik hitam atau putih. Ada pro dan kontra untuk kedua pendekatan tersebut.

Dalam mendukung nullnilai-nilai yang mendefinisikan secara eksplisit , ada pro ini:

• Pesan-pesannya lebih deskriptif diri sehingga Anda bisa mengetahui semua kunci hanya dengan melihat pesan apa pun
• Terkait dengan poin sebelumnya, lebih mudah untuk membuat kode dan mendeteksi kesalahan pada konsumen data: lebih mudah untuk mendeteksi kesalahan jika Anda mengambil kunci yang salah (mungkin salah mengeja, mungkin API berubah, dll).

Dalam mendukung asumsi kunci tidak ada sama dengan semantik null:

• Beberapa perubahan lebih mudah diakomodasi. Misalnya, jika versi baru dari skema pesan menyertakan kunci baru, Anda dapat mengkode konsumen informasi untuk bekerja dengan kunci masa depan ini, bahkan ketika produsen pesan belum diperbarui dan belum melayani informasi ini.
• Pesan bisa kurang verbal atau lebih pendek

Seandainya API entah bagaimana stabil, dan Anda mendokumentasikannya dengan seksama, saya pikir sangat baik untuk menyatakan bahwa kunci yang tidak ada sama dengan arti null. Tetapi jika lebih berantakan dan kacau (seperti yang sering terjadi), saya pikir Anda dapat menghindari sakit kepala jika Anda secara eksplisit mendefinisikan setiap nilai dalam setiap pesan. Yaitu jika ragu, saya cenderung mengikuti pendekatan verbose.

Semua yang dikatakan, hal terpenting terpenting: nyatakan niat Anda dengan jelas dan konsisten. Jangan lakukan satu hal di sini dan yang lain di sana. Perangkat lunak yang dapat diprediksi adalah perangkat lunak yang lebih baik.

Saya akan memasok string kosong dalam situasi di mana string hadir, dan itu terjadi menjadi string kosong. Saya akan memberikan nol dalam situasi di mana saya ingin secara eksplisit mengatakan "tidak, data ini tidak ada". Dan hilangkan kunci untuk mengatakan "tidak ada data di sana, jangan repot-repot".

Anda menilai situasi mana yang bisa terjadi. Apakah masuk akal jika aplikasi Anda memiliki string kosong? Apakah Anda ingin membedakan antara mengatakan "tidak ada data" secara eksplisit dengan menggunakan nol dan secara implisit dengan tidak memiliki nilai? Anda seharusnya hanya memiliki kedua kemungkinan (null dan tidak ada kunci sekarang) jika keduanya perlu dibedakan oleh klien.

Sekarang perlu diingat bahwa ini semua tentang pengiriman data. Apa yang penerima lakukan dengan data adalah urusan mereka, dan mereka akan melakukan apa yang paling nyaman bagi mereka. Penerima harus dapat menangani apa pun yang Anda lemparkan padanya (mungkin dengan menolak data) tanpa menabrak.

Jika tidak ada pertimbangan lain, maka saya akan mengirimkan apa yang paling nyaman bagi pengirim, dan mendokumentasikannya . Saya lebih suka untuk tidak mengirim nilai yang tidak ada sama sekali karena ini cenderung meningkatkan kecepatan penyandian, transmisi dan penguraian JSON.

Meskipun saya tidak bisa mengatakan apa yang terbaik itu hampir pasti bukan detail implementasi yang sederhana , itu mengubah struktur bagaimana Anda dapat berinteraksi dengan variabel itu.

Jika sesuatu bisa menjadi nol Anda harus selalu memperlakukannya seolah-olah itu akan menjadi nol di beberapa titik , jadi Anda akan selalu memiliki dua alur kerja , satu untuk nol, satu untuk string yang valid. Split workflow tidak selalu merupakan hal yang buruk, karena ada sedikit penanganan kesalahan dan penggunaan case khusus yang dapat Anda manfaatkan, tetapi itu mengaburkan kode Anda.

Jika Anda selalu berinteraksi dengan string dengan cara yang sama , mungkin akan lebih mudah untuk fungsionalitas untuk tetap berada di kepala Anda .

Jadi seperti halnya dengan pertanyaan "apa yang terbaik", saya pergi dengan jawabannya: itu tergantung . Jika Anda ingin membagi alur kerja Anda dan menangkap secara lebih eksplisit ketika sesuatu tidak disetel, gunakan null. Jika Anda lebih suka program tetap seperti apa adanya, gunakan string kosong. Yang penting adalah Anda konsisten , pilih pengembalian bersama dan tetap dengan itu.

Mengingat Anda membuat API, saya akan merekomendasikan menempel pada string kosong karena ada lebih sedikit bagi pengguna untuk mengimbangi, karena sebagai pengguna API saya tidak akan tahu setiap alasan API Anda bisa memberi saya nilai nol kecuali jika Anda didokumentasikan dengan sangat baik, yang tidak akan dibaca oleh beberapa pengguna.

Dokumen!

TL; DR>

Lakukan sesuai keinginan Anda - terkadang konteks di mana ia digunakan penting. Contoh, Bind Variabel ke Oracle SQL: String Kosong ditafsirkan sebagai NULL.

Cukup saya katakan - Pastikan Anda mendokumentasikan setiap skenario yang disebutkan

• BATAL
• Kosong (kosong)
• Tidak ada (dihapus)

Kode Anda mungkin bertindak dengan cara berbeda - mendokumentasikan bagaimana kode Anda bereaksi terhadapnya:

• Gagal (Pengecualian dll), bahkan mungkin gagal validasi (mungkin pengecualian yang diperiksa) vs tidak dapat menangani situasi dengan benar (NullPointerException).
• Berikan standar yang masuk akal
• Kode berperilaku berbeda

Kemudian selain itu - terserah pada Anda untuk berperilaku secara konsisten, dan mungkin mengadopsi beberapa praktik terbaik Anda sendiri. Dokumentasikan perilaku yang konsisten. Contoh:

• Perlakukan Null dan Missing sama
• Perlakukan string kosong persis seperti itu. Hanya dalam kasus pengikat SQL, itu mungkin dianggap kosong. Pastikan SQL Anda berperilaku konsisten dan dengan cara yang diharapkan.

tl; dr - jika Anda menggunakannya: konsisten dalam artinya.

Jika Anda termasuk null, apa artinya? Ada alam semesta hal-hal yang bisa berarti. Satu nilai sama sekali tidak cukup untuk mewakili nilai yang hilang atau tidak diketahui (dan ini hanya dua dari segudang kemungkinan: misalnya Hilang - itu sudah diukur, tetapi kami belum mengetahuinya. Tidak diketahui - kami tidak mencoba mengukur saya t.)

Dalam contoh yang saya temui baru-baru ini, bidang dapat kosong karena tidak dilaporkan untuk melindungi privasi seseorang, tetapi bidang itu diketahui di sisi pengirim, tidak dikenal di sisi pengirim, tetapi diketahui oleh reporter asli atau tidak diketahui keduanya. Dan semua ini penting bagi penerima. Jadi biasanya satu nilai saja tidak cukup.

Dengan asumsi dunia terbuka (Anda benar-benar tidak tahu tentang hal-hal yang tidak disebutkan), Anda cukup meninggalkannya dan itu bisa apa saja. Dengan asumsi dunia tertutup (hal-hal yang tidak dinyatakan salah, misalnya dalam SQL) Anda sebaiknya memperjelas apa nullartinya dan konsisten dengan definisi itu karena Anda dapat ...