Membuat hubungan entitas di REST: Bolehkah saya membuat orang tua dengan memposting ke id anak?

Kami sedang merancang API REST untuk mengakses data pelanggan klasik. Salah satu elemen dalam API adalah aset pengguna. Aset ditambahkan di bawah layanan yang diberikan. API backend hanya akan menambahkan aset ke pengguna di bawah layanan yang diberikan. Jadi, tidak ada hubungan Pengguna - Aset, tetapi Pengguna - [Layanan] - Hubungan aset.

URI kami akan terlihat seperti ini:

/users/{id}/assets/{id}/services/{id}

Penggunaan API akan mengetahui id aset dan id layanan untuk membuat entri baru. Yang kami perjuangkan adalah penciptaan hubungan ini.

Salah satu cara mudah adalah memposting seluruh hubungan dengan /users/{id}/assets/

POST /users/{id}/assets    
{asset:${id}, service:{id}, attribute1:"{var}", attribute2:"{var}"}

tapi kemudian kita sebenarnya tidak menciptakan aset seperti yang ditunjukkan oleh URI, tetapi hubungan aset-layanan.

Sebagai alternatif, kami mempertimbangkan POST'ing ke URI yang membahas hubungan, seperti ini:

POST /users/{id}/assets/{id}/service/{id}
{attribute1:"{var}", attribute2:"{var}"}

Tetapi dalam kasus ini, jalur sumber daya /users/{id}/assets/{id}tidak akan ada sebelum POST dan akan dibuat sebagai efek samping.

Apakah POST ke jalur sumber daya yang belum ada sama sekali diizinkan?

Terima kasih atas pemikiran anda,

Gerard.

Sepertinya Anda menyarankan bahwa, setiap kali pengguna pertama kali memposting ke hubungan yang tidak ada, Anda akan membuatnya sebagai bagian dari posting.

Jika Anda bertanya apakah jenis pola akses saat ini adalah pola pengembangan yang valid dan dapat diterima, jawabannya adalah ya - pola ini berlaku, dan merupakan pola yang cukup umum untuk dilihat.

Ada beberapa poin di sini: Pertama: Anda tidak boleh meletakkan id saat membuat sumber daya baru karena id ini mungkin sudah ada, atau mungkin sistem menggunakan teknik khusus untuk menghasilkan id dan Anda memaksanya untuk menggunakan id Anda, dan untuk mengusulkan bahwa id harus dibuat oleh sistem atribut header lokasi harus diatur dalam kasus sumber daya penciptaan, untuk mendapatkan umpan balik dengan id yang dihasilkan.

Kedua: JSON Anda tidak benar, Anda harus berurusan dengan layanan sebagai objek lain di dalam objek aset juga seperti dalam sumber daya layanan "URI" Anda harus menghadapinya sebagai array.

POST /users/{id}/assets    
{asset:${id}, service:{id}, attribute1:"{var}", attribute2:"{var}"}

harus:

POST /users/{id}/assets    
{services:[{ attribute1:"var", attribute2:"var"}]}

Jika Anda akan menggunakan cara ini

Ketiga: Saya tidak suka menggunakan cara ini untuk mengusulkan desain, jika kasus ini gagal, bagaimana Anda bisa tahu itu gagal saat membuat aset atau layanan,

Inilah garis pemikiran yang berbeda:

POST /relationships
{ relationship:${id}, asset:{id}, service:{id}, user:{id}, data:"some data" }

Dengan cara ini Anda mendefinisikan hubungan sebagai tautan tiga arah antara aset, layanan, dan pengguna dan tidak menyiratkan hubungan hierarkis apa pun

Anda kemudian dapat mengambil hubungan tertentu dengan:

GET /relationships?id="2144321"

atau cari subset hubungan dengan:

GET /relationships?user="43434"

atau

GET /relationships?asset="12433"

Cara aslinya tidak salah, tetapi pendekatan ini dapat memberi Anda lebih banyak fleksibilitas mengenai siapa yang akan digunakan.