Format respons JSON API standar?


697

Apakah ada standar atau praktik terbaik untuk menyusun respons JSON dari API? Jelas, setiap data aplikasi berbeda, sehingga banyak yang tidak saya pedulikan, melainkan "respons boilerplate", jika Anda mau. Contoh yang saya maksud:

Permintaan yang berhasil:

{
  "success": true,
  "payload": {
    /* Application-specific data would go here. */
  }
}

Permintaan gagal:

{
  "success": false,
  "payload": {
    /* Application-specific data would go here. */
  },
  "error": {
    "code": 123,
    "message": "An error occurred!"
  }
}

16
Orang-orang mungkin telah belajar dari SOAP dan tidak akan membangunnya lagi ...
Denys Séguret

18
@dystroy: Ingin menjelaskan komentar Anda?
FtDRbwLXw6

5
Saya benar-benar tertarik dengan pertanyaan ini karena saya harus merancang JSON API baru-baru ini dan mendapati diri saya bertanya-tanya apakah mereka merupakan standar yang mendefinisikan format respons. Milik Anda sebenarnya terlihat cukup bagus, dan terlihat layak digunakan jika Anda tidak menemukan standar. Sayang sekali bahwa jawaban yang diberikan tidak benar-benar menjawab pertanyaan itu.
Alex

13
@Alex sayangnya, itu karena ke mana pun Anda pergi, tidak ada standar. Tidak hanya di dalam JSON itu sendiri, tetapi dalam hal bagaimana menggunakannya untuk aplikasi RESTful, atau hal semacam itu. Semua orang melakukannya secara berbeda. Anda dapat merasa bebas untuk mengikuti praktik-praktik terbaik (tanggapan HTTP, struktur paket yang berarti, mata untuk menyusun data Anda untuk dikonsumsi oleh sistem Anda), tetapi semua orang yang merupakan distributor utama melakukan setidaknya satu hal yang berbeda dari yang lain. .. Tidak ada standar, dan kemungkinan tidak akan ada standar, jadi bangun sesuatu yang solid, dan bangunlah agar sesuai dengan Anda.
Norguard

Jawaban:


641

Ya, ada beberapa standar (meskipun beberapa kebebasan pada definisi standar) yang telah muncul:

  1. API JSON - API JSON mencakup pembuatan dan pembaruan sumber daya juga, bukan hanya tanggapan.
  2. JSend - Sederhana dan mungkin apa yang sudah Anda lakukan.
  3. OData JSON Protocol - Sangat rumit.
  4. HAL - Suka OData tetapi bertujuan untuk menjadi seperti HATEOAS .

Ada juga format deskripsi API JSON:

  • Kesombongan
    • Skema JSON (digunakan oleh kesombongan tetapi Anda bisa menggunakannya sendiri)
  • WADL di JSON
  • RAML
  • HAL karena HATEOAS dalam teori adalah menggambarkan diri.

19
Terima kasih. JSend khususnya adalah persis apa yang saya cari. Ini mirip dengan apa yang saya lakukan, tetapi memiliki beberapa manfaat bahwa metode saya tidak. Dalam keadilan untuk @trungly, JSend juga sangat dekat dengan jawabannya sendiri.
FtDRbwLXw6

8
Untuk tanggapan kesalahan secara khusus, saya juga menyukai Rincian Masalah untuk rancangan HTTP APIs RFC.
Pieter Ennes

1
Mungkin Anda ingin menambahkan code.google.com/p/json-service ke daftar format deskripsi?
emilesilvis

1
Saya pikir label "Standar yang disarankan untuk Rails" sedikit berlebihan - ini hanya solusi satu programmer. Tidak yakin apa yang menjadikannya "standar yang direkomendasikan" (khususnya jika Anda melihat popularitas permata - tidak terlihat seperti banyak orang yang menggunakan ini sama sekali)? Saya pribadi tidak berpikir sebagian besar programmer Rails akan merekomendasikan solusi ini karena menggunakan badan respons alih-alih tajuk HTTP untuk status
Iwo Dziechciarow

2
Panduan Gaya Google JSON juga merupakan referensi yang bagus
MRodrigues

195

Panduan Google JSON

Respon keberhasilan kembali data

{
  "data": {
    "id": 1001,
    "name": "Wing"
  }
}

Kembali respons kesalahan error

{
  "error": {
    "code": 404,
    "message": "ID not found"
  }
}

dan jika klien Anda adalah JS, Anda dapat menggunakannya if ("error" in response) {}untuk memeriksa apakah ada kesalahan.


13
Pertama-tama, panduan Google JSON merekomendasikan penggunaan tanda kutip ganda dan bukan tanda kutip tunggal.
rpozarickij

1
Saya tidak yakin apakah Anda bisa menangani ini dari Server Side JSON API seperti PlayJson, atau tidak masalah. @Sungguh, tautan Anda rusak
Rhys Bradbury

3
Bagaimana dengan kesalahan yang perlu memberikan daftar kegagalan (seperti masalah validasi)?
Xeoncross

1
@Xeoncross mengklik tautan pada kata tersebut error, halaman Google memberikan contohnya
MI Wright

@Xeoncross Anda dapat mengembalikan daftar kegagalan menggunakan error.errors [], didefinisikan sebagai: "Wadah untuk informasi tambahan tentang kesalahan. Jika layanan mengembalikan beberapa kesalahan, setiap elemen dalam array kesalahan mewakili kesalahan yang berbeda." Mungkin kesalahan tingkat atas akan menyebutkan "Permintaan gagal input validasi" dan array kesalahan [] akan memiliki satu entri untuk setiap kegagalan validasi spesifik yang terjadi.
James Daily

130

Saya kira standar de facto belum benar-benar muncul (dan mungkin tidak pernah). Tapi bagaimanapun, ini adalah pendapat saya:

Permintaan yang berhasil:

{
  "status": "success",
  "data": {
    /* Application-specific data would go here. */
  },
  "message": null /* Or optional success message */
}

Permintaan gagal:

{
  "status": "error",
  "data": null, /* or optional error payload */
  "message": "Error xyz has occurred"
}

Keuntungan: Elemen tingkat atas yang sama dalam kasus sukses dan kesalahan

Kekurangan: Tidak ada kode kesalahan, tetapi jika Anda mau, Anda bisa mengubah status menjadi kode (berhasil atau gagal), -atau- Anda bisa menambahkan item tingkat atas lain bernama "kode".


3
ya ini cara yang benar jika Anda menggunakan POJO untuk parsing json! ketika kita menggunakan POJO kita perlu format json statis, non dinamis!
LOG_TAG

Sederhana dan to the point. Lebih baik daripada jsend menurut saya karena jsend membedakan kesalahan dari gagal.
Josue Alexander Ibarra

1
Saya menggunakan pola ini juga, tapi dengan bidang yang disebut messagesyang merupakan array pesan bukannya string tunggal.
StockBreak

4
Jawabannya hampir merupakan salinan JSend yang terdokumentasi dengan baik yang sederhana dan sangat berguna. Mereka menyediakan status ketiga failuntuk masalah validasi tipikal, sementara errorhanya digunakan dengan fatals seperti kesalahan db.
s3m3n

untuk kesuksesan: jika ada 200di header mengapa Anda membutuhkan statusbidang? cukup kembalikan objek data secara langsung. Anda tahu ini dapat menyebabkan rasa sakit tambahan dengan bahasa FE yang diketik seperti TypeScript.
Deniss M.

84

Dengan asumsi pertanyaan Anda adalah tentang desain layanan web REST dan lebih tepatnya tentang keberhasilan / kesalahan.

Saya pikir ada 3 jenis desain.

  1. Gunakan hanya kode Status HTTP untuk menunjukkan jika ada kesalahan dan coba batasi diri Anda dengan yang standar (biasanya sudah cukup).

    • Pro: Ini adalah standar yang tidak tergantung pada api Anda.
    • Cons: Kurang informasi tentang apa yang sebenarnya terjadi.
  2. Gunakan Status HTTP + json body (bahkan jika itu adalah kesalahan). Tetapkan struktur yang seragam untuk kesalahan (mis: kode, pesan, alasan, jenis, dll) dan gunakan untuk kesalahan, jika itu berhasil maka kembalikan saja respons json yang diharapkan.

    • Pro: Masih standar saat Anda menggunakan kode status HTTP yang ada dan Anda mengembalikan json yang menjelaskan kesalahan (Anda memberikan informasi lebih lanjut tentang apa yang terjadi).
    • Cons: Output json akan bervariasi tergantung apakah itu kesalahan atau keberhasilan.
  3. Lupakan status http (mis: selalu status 200), selalu gunakan json dan tambahkan di root dari respons, boolean responseValid dan objek kesalahan (kode, pesan, dll.) Yang akan diisi jika itu adalah kesalahan jika tidak maka bidang lainnya (sukses) dihuni.

    • Pro: Klien hanya berurusan dengan tubuh respons yang merupakan string json dan mengabaikan status (?).

    • Cons: Standar kurang.

Terserah Anda untuk memilih :)

Tergantung pada API saya akan memilih 2 atau 3 (saya lebih suka 2 untuk json rest apis). Hal lain yang saya alami dalam merancang REST Api adalah pentingnya dokumentasi untuk setiap sumber daya (url): parameter, tubuh, respons, header dll + contoh.

Saya juga akan merekomendasikan Anda untuk menggunakan jersey (implementasi jax-rs) + genson (perpustakaan penyatuan data java / json). Anda hanya perlu melepaskan jersey genson + di classpath Anda dan json didukung secara otomatis.

EDIT:

  • Solusi 2 adalah yang paling sulit untuk diterapkan tetapi keuntungannya adalah Anda dapat menangani pengecualian dengan baik dan tidak hanya kesalahan bisnis, upaya awal lebih penting tetapi Anda menang dalam jangka panjang.

  • Solusi 3 adalah mudah diimplementasikan pada kedua sisi server dan klien tetapi tidak begitu baik karena Anda harus merangkum objek yang ingin Anda kembalikan dalam objek respons yang juga berisi kesalahan responseValid +.


2
Anda mengatakan bahwa saya harus "Tentukan struktur kesalahan yang seragam" dan saran serupa lainnya, tetapi inilah tepatnya yang saya tanyakan. Saya kira jawabannya adalah bahwa "tidak, tidak ada standar atau praktik terbaik sehubungan dengan struktur ini."
FtDRbwLXw6

7
Sebagai catatan: kode status HTTP bukan header.
pepkin88

3
"responsnya bukan json tetapi html." salah! html tidak ada hubungannya dengan penanganan kesalahan. responsnya bisa berupa tipe konten apa pun yang Anda dukung.
oligofren

2
@ ア レ ッ ク ス Kode status HTTP adalah kode 3 digit di baris status dari header respons HTTP. Setelah baris itu adalah bidang header, bahasa sehari-hari juga disebut header.
pepkin88

1
@ ア レ ッ ク ス Halaman Wikipedia di HTTP dengan baik menjawab pertanyaan Anda, Anda dapat memeriksanya di sana: en.wikipedia.org/wiki/… (tautan ke bagian Pesan tanggapan)
pepkin88


19

Berikut ini adalah format instagram json yang digunakan

{
    "meta": {
         "error_type": "OAuthException",
         "code": 400,
         "error_message": "..."
    }
    "data": {
         ...
    },
    "pagination": {
         "next_url": "...",
         "next_max_id": "13872296"
    }
}

19

Saya tidak akan sombong untuk mengklaim bahwa ini adalah standar sehingga saya akan menggunakan formulir "Saya lebih suka".

Saya lebih suka respon singkat (ketika meminta daftar / artikel saya ingin array artikel JSON).

Dalam desain saya, saya menggunakan HTTP untuk laporan status, 200 mengembalikan hanya payload.

400 mengembalikan pesan tentang apa yang salah dengan permintaan:

{"message" : "Missing parameter: 'param'"}

Kembali 404 jika model / pengontrol / URI tidak ada

Jika ada kesalahan dengan pemrosesan di sisi saya, saya mengembalikan 501 dengan pesan:

{"message" : "Could not connect to data store."}

Dari apa yang saya lihat cukup banyak kerangka ISTIRAH cenderung sepanjang garis ini.

Alasan :

JSON seharusnya merupakan format payload , ini bukan protokol sesi. Seluruh gagasan payload sesi-ish verbose berasal dari dunia XML / SOAP dan berbagai pilihan salah arah yang menciptakan desain-desain besar itu. Setelah kami menyadari semua itu adalah sakit kepala besar, inti dari REST / JSON adalah untuk KISS, dan mematuhi HTTP. Saya tidak berpikir bahwa ada sesuatu yang jauh standar di kedua JSend dan terutama tidak dengan yang lebih banyak di antara mereka. XHR akan bereaksi terhadap respons HTTP, jika Anda menggunakan jQuery untuk AJAX Anda (seperti umumnya), Anda dapat menggunakan try/ catchdan done()/ fail()callback untuk menangkap kesalahan. Saya tidak bisa melihat bagaimana merangkum laporan status di JSON lebih berguna dari itu.


2
"JSON adalah format payload ...". Tidak, JSON adalah format serialisasi data. Anda dapat menggunakannya untuk mengirimkan apa pun yang Anda inginkan, termasuk protokol sesi atau hanya muatan sederhana. Komentar KISS Anda tepat sasaran dan independen dari JSON. Lebih baik untuk menjaga JSON fokus pada apa itu (data keberhasilan atau alasan kegagalan data seperti yang Anda gambarkan) daripada mencemari dengan beberapa kecelakaan baik yang terus-menerus harus disusun dan kemudian dihapus. Kemudian Anda bisa pergi jauh-jauh dan menyimpan data JSON Anda seperti di Couchbase dan mengembalikannya ke aplikasi.
Dirk Bester

1
Mungkin saya seharusnya merumuskannya sebagai "seharusnya menjadi format muatan", tetapi selain itu, saya mendukung komentar saya. Anda bisa meletakkan data sesi / kesalahan sebagai atribut tag tubuh dalam dokumen HTML, tetapi itu tidak membuatnya menjadi cara yang tepat atau masuk akal untuk melakukannya.
Bojan Markovic

16

Untuk apa nilainya, saya melakukan ini secara berbeda. Panggilan yang berhasil hanya memiliki objek JSON. Saya tidak memerlukan objek JSON tingkat lebih tinggi yang berisi bidang keberhasilan yang menunjukkan bidang benar dan muatan yang memiliki objek JSON. Saya baru saja mengembalikan objek JSON yang sesuai dengan 200 atau apa pun yang sesuai dalam kisaran 200 untuk status HTTP di header.

Namun, jika ada kesalahan (sesuatu dalam 400 keluarga) saya mengembalikan objek kesalahan JSON yang terbentuk dengan baik. Sebagai contoh, jika klien mem-POSTing Pengguna dengan alamat email dan nomor telepon dan salah satunya rusak (yaitu saya tidak bisa memasukkannya ke dalam basis data saya) saya akan mengembalikan sesuatu seperti ini:

{
  "description" : "Validation Failed"
  "errors" : [ {
    "field" : "phoneNumber",
    "message" : "Invalid phone number."
  } ],
}

Bit penting di sini adalah bahwa properti "bidang" harus cocok dengan bidang JSON persis yang tidak dapat divalidasi. Ini memungkinkan klien untuk mengetahui apa yang salah dengan permintaan mereka. Juga, "pesan" ada di lokasi permintaan. Jika kedua "alamat email" dan "nomor telepon" tidak valid maka array "kesalahan" akan berisi entri untuk keduanya. Badan respons JSON 409 (Konflik) mungkin terlihat seperti ini:

{
  "description" : "Already Exists"
  "errors" : [ {
    "field" : "phoneNumber",
    "message" : "Phone number already exists for another user."
  } ],
}

Dengan kode status HTTP dan JSON ini, klien memiliki semua yang mereka butuhkan untuk merespons kesalahan dengan cara yang deterministik dan tidak membuat standar kesalahan baru yang mencoba menyelesaikan menggantikan kode status HTTP. Catatan, ini hanya terjadi untuk kisaran 400 kesalahan. Untuk apa pun dalam kisaran 200 saya hanya bisa mengembalikan apa pun yang sesuai. Bagi saya itu sering merupakan objek JSON seperti HAL tapi itu tidak terlalu penting di sini.

Satu hal yang saya pikirkan tentang menambahkan adalah kode kesalahan numerik baik dalam entri array "kesalahan" atau root dari objek JSON itu sendiri. Tapi sejauh ini kami belum membutuhkannya.


9

Tidak ada kesepakatan tentang format respons api sisanya dari raksasa perangkat lunak besar - Google, Facebook, Twitter, Amazon, dan lainnya, meskipun banyak tautan telah disediakan dalam jawaban di atas, di mana beberapa orang telah mencoba untuk membakukan format respons.

Karena kebutuhan API dapat berbeda, sangat sulit untuk mengajak semua orang bergabung dan menyetujui beberapa format. Jika Anda memiliki jutaan pengguna yang menggunakan API Anda, mengapa Anda mengubah format respons Anda?

Berikut ini adalah pendapat saya tentang format respons yang terinspirasi oleh Google, Twitter, Amazon, dan beberapa posting di internet:

https://github.com/adnan-kamili/rest-api-response-format

Menyombongkan file:

https://github.com/adnan-kamili/swagger-sample-template


1
upvote untuk sisa-api-respons-format amplop-gratis
Kerem Baydoğan

@adnan kamilli - >>> StatusCode: 304, ReasonPhrase: 'Not Modified', Versi: 1.1, Konten: <null>, Header: {} <<<< apakah ini respons yang tepat dari restApi?
Arnold Brown

@ArnoldBrown Untuk titik akhir API mana - tindakan Anda mengembalikan kode ini?
adnan kamili

ini merupakan respons balik api yang digunakan untuk mengunggah gambar (data formulir) - Api yang ditulis klien.
Arnold Brown

7

Inti dari JSON adalah bahwa ia sepenuhnya dinamis dan fleksibel. Tekuk sesuai keinginan Anda, karena itu hanya satu set objek dan array JavaScript berseri, yang di-root dalam satu node.

Apa jenis rootnode terserah Anda, apa isinya terserah Anda, apakah Anda mengirim metadata beserta responsnya terserah Anda, apakah Anda menyetel tipe mime ke application/jsonatau membiarkannya seperti text/plainterserah Anda ( selama Anda tahu cara menangani kasing tepi).

Bangun skema ringan yang Anda sukai.
Secara pribadi, saya telah menemukan bahwa pelacakan analitik dan penyajian mp3 / ogg dan penyajian galeri gambar serta perpesanan teks dan paket jaringan untuk game online, dan posting blog dan komentar blog semuanya memiliki persyaratan yang sangat berbeda dalam hal apa yang ada. dikirim dan apa yang diterima dan bagaimana mereka harus dikonsumsi.

Jadi hal terakhir yang saya inginkan, ketika melakukan semua itu, adalah mencoba untuk membuat masing-masing sesuai dengan standar boilerplate yang sama, yang didasarkan pada XML2.0 atau semacamnya.

Yang mengatakan, ada banyak yang bisa dikatakan untuk menggunakan skema yang masuk akal bagi Anda dan dipikirkan dengan baik.
Cukup baca beberapa respons API, catat apa yang Anda suka, kritik apa yang tidak Anda sukai, tuliskan kritik itu dan pahami mengapa mereka salah, dan kemudian pikirkan tentang bagaimana menerapkan apa yang Anda pelajari pada apa yang Anda butuhkan.


1
Terima kasih atas tanggapannya, tetapi sekali lagi, saya tidak khawatir tentang muatannya sendiri. Sementara contoh Anda semua memiliki persyaratan yang sangat berbeda dalam hal apa yang dikirim / diterima dalam muatan dan bagaimana muatan itu dikonsumsi, mereka semua harus menyelesaikan masalah yang sama sehubungan dengan respons itu sendiri . Yaitu, mereka semua perlu menentukan apakah permintaan itu berhasil. Jika ya, lanjutkan dengan pemrosesan. Jika tidak, apa yang salah. Pelat ini yang umum untuk semua respons API yang saya maksudkan dalam pertanyaan saya.
FtDRbwLXw6

Entah mengembalikan status 200 untuk semuanya, dan menentukan sendiri payload kesalahan khusus, atau mengembalikan status sepadan dengan kesalahan, dengan dan / atau tanpa rincian lebih lanjut di dalam tubuh payload (jika didukung). Seperti yang saya katakan, skema terserah Anda - termasuk informasi meta / status apa pun. Ini adalah batu tulis kosong 100% untuk dilakukan dengan apa yang Anda harap berdasarkan gaya arsitektur pilihan Anda.
Norguard

2
Saya menyadari bahwa itu adalah batu tulis kosong yang harus dilakukan sesuka saya. Tujuan dari pertanyaan saya adalah untuk menanyakan apakah ada standar yang muncul sejauh struktur berjalan. Saya tidak bertanya "apa itu JSON dan bagaimana cara menggunakannya", melainkan, "Saya tahu cara menggunakan JSON untuk mengembalikan / menyusun apa pun yang saya inginkan, tetapi saya ingin tahu apakah ada struktur standar yang digunakan atau menjadi populer. " Maaf jika saya salah menjawab pertanyaan. Terima kasih atas tanggapan Anda.
FtDRbwLXw6

7

JSON-RPC 2.0 mendefinisikan format permintaan dan respons standar, dan menghirup udara segar setelah bekerja dengan REST API.


Satu-satunya hal yang JSON-RPC_2.0 tawarkan untuk pengecualian adalah kode kesalahan? Kode kesalahan numerik tidak dapat mewakili dengan tepat masalah yang terjadi.
AgilePro

@ AggPro Setuju, kode kesalahan numerik tidak terlalu bagus, dan saya berharap para penulis spec telah mengizinkan codebidang tersebut menjadi sebuah String. Untungnya spec memungkinkan kita untuk memasukkan informasi apa pun yang kita inginkan ke dalam databidang kesalahan . Dalam proyek JSON-RPC saya, saya biasanya menggunakan kode numerik tunggal untuk untuk semua kesalahan lapisan aplikasi (sebagai lawan dari salah satu kesalahan protokol standar). Lalu saya menaruh informasi kesalahan terperinci (termasuk kode string yang menunjukkan jenis kesalahan nyata) di databidang.
dnault

2

Bagi mereka yang datang kemudian, selain jawaban yang diterima yang mencakup HAL, JSend, dan JSON API, saya akan menambahkan beberapa spesifikasi lain yang layak dilihat:

  • JSON-LD , yang merupakan Rekomendasi W3C dan menentukan cara membangun Layanan Web yang dapat dioperasikan di JSON
  • Tipe Ion Hypermedia untuk REST, yang mengklaim dirinya sebagai "tipe hypermedia berbasis JSON yang sederhana dan intuitif untuk REST"

1

Kerangka dasar yang disarankan terlihat baik-baik saja, tetapi objek kesalahan seperti yang didefinisikan terlalu terbatas. Orang sering kali tidak dapat menggunakan nilai tunggal untuk mengungkapkan masalah, dan sebagai gantinya diperlukan rantai masalah dan sebab .

Saya melakukan sedikit riset dan menemukan bahwa format yang paling umum untuk kesalahan pengembalian (pengecualian) adalah struktur dari formulir ini:

{
   "success": false,
   "error": {
      "code": "400",
      "message": "main error message here",
      "target": "approx what the error came from",
      "details": [
         {
            "code": "23-098a",
            "message": "Disk drive has frozen up again.  It needs to be replaced",
            "target": "not sure what the target is"
         }
      ],
      "innererror": {
         "trace": [ ... ],
         "context": [ ... ]
      }
   }
}

Ini adalah format yang diusulkan oleh standar data OASIS OASIS OData dan tampaknya menjadi opsi paling standar di luar sana, namun tampaknya tidak ada tingkat adopsi yang tinggi dari standar apa pun pada saat ini. Format ini konsisten dengan spesifikasi JSON-RPC.

Anda dapat menemukan pustaka sumber terbuka lengkap yang mengimplementasikannya di: Mendocino JSON Utilities . Pustaka ini mendukung Objek JSON serta pengecualian.

Detailnya dibahas dalam posting blog saya tentang Penanganan Kesalahan di API JSON REST


0

Tidak ada standar yang melanggar hukum atau melarang selain akal sehat. Jika kita mengabstraksikan ini seperti dua orang berbicara, standar adalah cara terbaik mereka dapat secara akurat memahami satu sama lain dalam kata-kata minimum dalam waktu minimum. Dalam kasus kami, 'kata-kata minimum' adalah mengoptimalkan bandwidth untuk efisiensi transportasi dan 'memahami secara akurat' adalah struktur untuk efisiensi parser; yang akhirnya berakhir dengan semakin sedikit data, dan struktur umum; sehingga dapat melewati lubang pin dan dapat diurai melalui lingkup umum (setidaknya pada awalnya).

Hampir dalam setiap kasus yang disarankan, saya melihat respons terpisah untuk skenario 'Sukses' dan 'Kesalahan', yang merupakan semacam ambiguitas bagi saya. Jika tanggapan berbeda dalam kedua kasus ini, lalu mengapa kita benar-benar perlu memasang bendera 'Sukses' di sana? Tidakkah jelas bahwa tidak adanya 'Kesalahan' adalah 'Sukses'? Mungkinkah memiliki respons di mana 'Sukses' BENAR dengan set 'Kesalahan'? Atau bagaimana, 'Sukses' itu SALAH tanpa set 'Kesalahan'? Hanya satu bendera saja tidak cukup? Saya lebih suka memiliki bendera 'Kesalahan' saja, karena saya percaya akan ada lebih sedikit 'Kesalahan' daripada 'Sukses'.

Juga, haruskah kita benar-benar membuat 'Galat' menjadi bendera? Bagaimana jika saya ingin merespons dengan beberapa kesalahan validasi? Jadi, saya merasa lebih efisien untuk memiliki simpul 'Kesalahan' dengan setiap kesalahan sebagai anak dari simpul itu; di mana simpul 'Kesalahan' kosong (dihitung ke nol) akan menunjukkan 'Sukses'.


-2

Respons Terbaik untuk apis web yang dapat dengan mudah dipahami oleh pengembang seluler.

Ini untuk Respon "Sukses"

{  
   "ReturnCode":"1",
   "ReturnMsg":"Successfull Transaction",
   "ReturnValue":"",
   "Data":{  
      "EmployeeName":"Admin",
      "EmployeeID":1
   }
}

Ini untuk Respons "Kesalahan"

{
    "ReturnCode": "4",
    "ReturnMsg": "Invalid Username and Password",
    "ReturnValue": "",
    "Data": {}
}

2
Akan lebih baik untuk membakukan properti Anda. Semua itu adalah nilai "Kembali ...". Tetapi data tidak diawali. Saya akan mengatakan, letakkan semua awalan "Kembali".
z0mbi3

Termasuk "Kembali" juga cukup berlebihan.
Jack Marchetti
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.