REST қызметінде модельдеу операциялары

Мен бұл сұрақтың бұрын сұралғанын білемін. Менде мәселе шешілді және мен кез-келген жерде REST немесе HTTP қағидаларын бұзып жатқанын білгім келеді.

Менің жүйеде әдеттегі GET/POST/PUT әрекеттерін қолдайтын member деп аталатын ресурс бар. Қатысушы Active және Disabled мәртебесіне ие. Пайдаланушыны өшіру әрекетін модельдеу қажет. Мен түсінемін, неге REST тұрғысынан жаман идея болар еді

POST api/member/john.smith/disable

Төменде көрсетілгендей, мүшені ажырату туралы сұрауды білдіретін ресурсты қабылдау туралы шешім оқыдым

public class DisableMemberRequest
{
    public string Username {get; set;}
}

Содан кейін жоғарыдағы ресурста POST

POST api/DisableMemberRequest

Бұл тәсіл ақылдылыққа ие болғанымен, бұл таза API интерфейстері үшін дұрыс емес деп ойлаймын. Жоғарыда көрсетілген сұраудың жауапты болуы 200 OK немесе 201 Created немесе 202 қабылданған болуы керек.

Бұл ресурста DisabledMember және PUT деп аталатын жаңа ресурсты сақтауды ойлаймын, себебі төмендегідей белгілі бір мүшені өшіру керек

PUT api/disabledmember/john.smith

Бұл REST/HTTP перспективасынан маған өте жарамды дизайн сияқты көрінеді. Бірақ мен сарапшы емеспін және мұны ұзақ уақыт бойы жасаған адамдармен дәлелдеуге тура келеді.

EDIT

Осы беттегі бағдарламашылармен әрекеттескеннен кейін, бұл мәліметтерді қосып отырмын. Мүшені ажырату процесі тек мүше күйінің жалауын орнату туралы ғана емес. Мүше өшірілген кезде іске қосылу қажет басқа жұмыс ағындары бар.

7

9 жауаптар

Мүмкіндіктерді жоюдың бір жолы - мүгедектік мүшелер жиынтығын білдіретін ресурсты анықтау. Мүшені ажырату үшін сіз осы мүшені мүгедек мүшелер жиынына қосасыз. Бұл бір нәрсеге ұқсас еді.

POST /api/DisabledMembers
Content-Type: text/uri-list

http://example.org/api/members/john.smith

Егер сіз операцияны кері қайтарғыңыз келсе, сіз жасай аласыз

POST /api/ActiveMembers
Content-Type: text/uri-list

http://example.org/api/members/john.smith

Бұл әдіс GET/api/DisabledMembers әрекетін орындаудың керемет жаратылысы болатынын түсінеді. Сондай-ақ, text/uri-list пайдалану арқылы барлық мүшелерді бір мезгілде ажырату/қайта қосу оңай болады.

4
қосылды
Бұл құқықты алуға рұқсат етіңіз. PUT ұсынған пайдалы жүктемесі бар болса, POST пайдалы жүктемесі жоқ деп ойлайсыз ба? Мен бұл аспектімде өте айқын емеспін. Осы аспект туралы көбірек әңгімелейтін мақала/блог бар ма?
қосылды автор Suhas, көзі
PUT пайдаланатынымның себебі - бұл сұранысты өңдеуге арналған ресурстың идентификаторы клиентке белгілі, немесе басқаша айтқанда, PUT URL. POST әдетте клиент жасалатын ресурстың URL-мекен-жайын білмегенде қолданылады.
қосылды автор Suhas, көзі
Мен не істеуді жоспарлап отырғандығыма ұқсас. Жалғыз айырмашылық PUT орнына POST пайдаланылады
қосылды автор Suhas, көзі
@Suhas Қандай медиа түрі PUT болады? Менің ойымша, сіз бос денемен PUT және DELETE қалпына келтіру үшін.
қосылды автор Darrel Miller, көзі
@Suhas екеуі де өте сирек кездеседі. Дегенмен, мен білемін, HTTP spec да қарсылық жоқ.
қосылды автор Darrel Miller, көзі
@suhas PUT өте жарамды. Сіз айтып өткендей, uri-ді алдын-ала құрастыру өте қарапайым, және бұл идемпотент. Мәселен, PUT - семантиканың неғұрлым өкілі. Жалғыз әдеттен тыс нәрсе, әдетте, PUT-мен сақтағыңыз келетін нәрсені қойып отыр. Сіздің жағдайда, PUT-ды орындау әрекеті маңызды болып табылады. Шынында пайдалы жүктеме қажет емес.
қосылды автор Darrel Miller, көзі

Мүмкіндіктерді жоюдың бір жолы - мүгедектік мүшелер жиынтығын білдіретін ресурсты анықтау. Мүшені ажырату үшін сіз осы мүшені мүгедек мүшелер жиынына қосасыз. Бұл бір нәрсеге ұқсас еді.

POST /api/DisabledMembers
Content-Type: text/uri-list

http://example.org/api/members/john.smith

Егер сіз операцияны кері қайтарғыңыз келсе, сіз жасай аласыз

POST /api/ActiveMembers
Content-Type: text/uri-list

http://example.org/api/members/john.smith

Бұл әдіс GET/api/DisabledMembers әрекетін орындаудың керемет жаратылысы болатынын түсінеді. Сондай-ақ, text/uri-list пайдалану арқылы барлық мүшелерді бір мезгілде ажырату/қайта қосу оңай болады.

4
қосылды
Бұл құқықты алуға рұқсат етіңіз. PUT ұсынған пайдалы жүктемесі бар болса, POST пайдалы жүктемесі жоқ деп ойлайсыз ба? Мен бұл аспектімде өте айқын емеспін. Осы аспект туралы көбірек әңгімелейтін мақала/блог бар ма?
қосылды автор Suhas, көзі
PUT пайдаланатынымның себебі - бұл сұранысты өңдеуге арналған ресурстың идентификаторы клиентке белгілі, немесе басқаша айтқанда, PUT URL. POST әдетте клиент жасалатын ресурстың URL-мекен-жайын білмегенде қолданылады.
қосылды автор Suhas, көзі
Мен не істеуді жоспарлап отырғандығыма ұқсас. Жалғыз айырмашылық PUT орнына POST пайдаланылады
қосылды автор Suhas, көзі
@Suhas екеуі де өте сирек кездеседі. Дегенмен, мен білемін, HTTP spec да қарсылық жоқ.
қосылды автор Darrel Miller, көзі
@suhas PUT өте жарамды. Сіз айтып өткендей, uri-ді алдын-ала құрастыру өте қарапайым, және бұл идемпотент. Мәселен, PUT - семантиканың неғұрлым өкілі. Жалғыз әдеттен тыс нәрсе, әдетте, PUT-мен сақтағыңыз келетін нәрсені қойып отыр. Сіздің жағдайда, PUT-ды орындау әрекеті маңызды болып табылады. Шынында пайдалы жүктеме қажет емес.
қосылды автор Darrel Miller, көзі
@Suhas Қандай медиа түрі PUT болады? Менің ойымша, сіз бос денемен PUT және DELETE қалпына келтіру үшін.
қосылды автор Darrel Miller, көзі

Алғашқы екі ұсынысыңыз да біраз иіс, себебі оларда URL мекенжайында етістік бар. Жақсы RESTful сәулет тек зат қорларын анықтайды, себебі HTTP протоколы осы ресурстарға қолданылатын етістік жиынтығын анықтайды.

Басқа ұсыныс қызықты, бірақ PUT дегеніміз, сіз оны жай ғана орналастырған нәрсені ұсыну үшін GET Бұл тұрғыда мағынасы бар.

Сіз айтқан сөзден пайдаланушы тіркелгісін қосу немесе өшіру және « PUT немесе PATCH true дегенге false мәнін аударыңыз. Егер бұл біраз уақытты қажет етсе, өтпелі жағдайға ие және API-тың тұтынушыларына әсер етуі мүмкін нәрсе болуы мүмкін, сондықтан олар процесті біледі, процестің өзін өзіндік ресурс ретінде айқындауға болады:

Өшіруді бастаңыз:

POST api/members/deactivations

Өткізілген әрекеттер туралы деактивацияның немесе есептің ағымдағы күйін алыңыз:

GET api/members/deactivations/john.smith

Өшіруді тоқтатудан бас тарту (міндетті емес):

DELETE api/members/deactivations/john.smith

Есептік жазбаны қайта белсендіруге болатын болса, ол ұқсас үлгі бойынша жүруі мүмкін.

Егер сіз өзіңіздің қорларыңыз ретінде оларды ақтау үшін осы жұмыс ағындарына жеткілікті зат жоқ деп ойласаңыз, немесе GET дегенге жауап беруді білмесеңіз, онда бұл жұмыс процесі ол жай API пайдаланушысынан жасырынып, пайдаланушының active мәнін өзгертудің жанама әсері ретінде іске асуы мүмкін емес.

3
қосылды
Оның айырмашылығы, деактивация - басқа ресурстардан тәуелсіз өмірді түсінуге болатын «нәрсе», бірақ әлі де members -мен тығыз байланысты.
қосылды автор Paul Turner, көзі
DisableMemberRequest деп аталатын нәрсе деп ойлаймын, сіз deactivation деп аталады. Өшіру процесін болдырмау үшін DELETE пайдалану идеясын ұнатамын. Дегенмен, егер дезактивация ұзақ уақытқа созылатын процесс болса, бұл пайдалы.
қосылды автор Suhas, көзі

Алғашқы екі ұсынысыңыз да біраз иіс, себебі оларда URL мекенжайында етістік бар. Жақсы RESTful сәулет тек зат қорларын анықтайды, себебі HTTP протоколы осы ресурстарға қолданылатын етістік жиынтығын анықтайды.

Басқа ұсыныс қызықты, бірақ PUT дегеніміз, сіз оны жай ғана орналастырған нәрсені ұсыну үшін GET Бұл тұрғыда мағынасы бар.

Сіз айтқан сөзден пайдаланушы тіркелгісін қосу немесе өшіру және « PUT немесе PATCH true дегенге false мәнін аударыңыз. Егер бұл біраз уақытты қажет етсе, өтпелі жағдайға ие және API-тың тұтынушыларына әсер етуі мүмкін нәрсе болуы мүмкін, сондықтан олар процесті біледі, процестің өзін өзіндік ресурс ретінде айқындауға болады:

Өшіруді бастаңыз:

POST api/members/deactivations

Өткізілген әрекеттер туралы деактивацияның немесе есептің ағымдағы күйін алыңыз:

GET api/members/deactivations/john.smith

Өшіруді тоқтатудан бас тарту (міндетті емес):

DELETE api/members/deactivations/john.smith

Есептік жазбаны қайта белсендіруге болатын болса, ол ұқсас үлгі бойынша жүруі мүмкін.

Егер сіз өзіңіздің қорларыңыз ретінде оларды ақтау үшін осы жұмыс ағындарына жеткілікті зат жоқ деп ойласаңыз, немесе GET дегенге жауап беруді білмесеңіз, онда бұл жұмыс процесі ол жай API пайдаланушысынан жасырынып, пайдаланушының active мәнін өзгертудің жанама әсері ретінде іске асуы мүмкін емес.

3
қосылды
Оның айырмашылығы, деактивация - басқа ресурстардан тәуелсіз өмірді түсінуге болатын «нәрсе», бірақ әлі де members -мен тығыз байланысты.
қосылды автор Paul Turner, көзі
DisableMemberRequest деп аталатын нәрсе деп ойлаймын, сіз deactivation деп аталады. Өшіру процесін болдырмау үшін DELETE пайдалану идеясын ұнатамын. Дегенмен, егер дезактивация ұзақ уақытқа созылатын процесс болса, бұл пайдалы.
қосылды автор Suhas, көзі

мұнда .

Ойлаудың практикалық тәсілі немесе REST-ды бастапқы нүкте ретінде қолдану (кем дегенде ол мен үшін жұмыс істейді) келесі жолдарды ойластырады:

1) HTTP «GET/POST/PUT/DELETE» дегенді доменнің әрекеттерін модельдеу әдісі ретінде пайдаланыңыз. Дерекқормен айналысқан кездегідей, барлық әрекеттеріңіз CURD сілтемесі бойынша көрсетіледі.

2) URI/URL ресурстарды тек қана анықтау. URI-іңізде ешқашан 'әрекеттер' болмауы керек.

3) Деректер алмасу HTTP хабарламаларының корпусында болуы керек. Тек талқылауды оңайлату үшін, деректердің өзін қалай модельдеуге кіріспеу керек

Трагедияның шешімі таза көрінеді.

Мекенжайға жаңартылған @Suhas 'comments

REST конвенцияны атау туралы емес. Мұның бәрі REST API құрастыру кезінде «әрекеттердің» орнына ресурстар туралы ойлау туралы. Әрқашан URL/URI-дегі 'Nonce' ресурсы туралы ойлау керек. Сізде бұрыннан бар домендік әрекеттерді салыстыруға және URL мекенжайындағы ресурстарды басқаруға арналған барлық CURD әрекеттері бар.

Мен Трагедияның шешімін ұнатамын, тек пікірталас үшін, Tragedian-дің шешімдерін түрлі домендік пайдалануға сәйкес келетін «жақсы» үшін бірдей емес және әртүрлі URL-үлгісімен жинақтай аламыз. Төменде домен үшін ең жақсы шешім болмауы мүмкін, бірақ олар баламалы түрде RESTful.

Мүшелік жою

  • DELETE api/мүшелігі/[member-id]/

Мүшелік мәртебесін алу

  • GET api/мүшелігі/[member-id]/status/

Мүшелік қосу

  • POST api/мүшелігі/[member-id]/

Ресурс ретінде «DisabledMember» -мен мәселені шешу үшін жаңартылды

Егер «Suhas» ұсынғандай, «PUT DisabledMember» функциясын пайдалансаңыз, 'мүшені ажырату' керек Сонда 'DisabledMember' ресурсында келесі әрекеттер нені білдіреді?

DELETE DisabledMember → қайта белсендіріңіз?

POST DisabledMember -> ??

GET DisabledMember - бұл оңай☺

Бұл дизайнмен шын мәнінде ресурстағы 'disable' әрекетін «жасырады». Сіз оны қалаған нәрсені істеуге мәжбүр ете аласыз, бірақ ол мен үшін тыныш болмайды.

1
қосылды
Мен тек «іскерлік себептермен» дегенді айтқанымда. Мысалы: Егер DELETE бұғаттауына тыйым салсам DisabledMember - бұл бизнеске байланысты.
қосылды автор Suhas, көзі
Әрбір ресурс әрбір HTTP әрекетін қолдауы керек пе? DELETE/POST DisabledMember -де HTTP 405 рұқсат етілмеген
қосылды автор Suhas, көзі
Мен ресурс айналасында жобалау туралы ойланамын. Бірақ менің үшінші дизайным бойынша DisabledMember деп аталатын жаңа ресурсты енгізу туралы түсініктеме көрмеймін. Осы дизайнмен байланысты проблемалар бар ма?
қосылды автор Suhas, көзі
Менің екінші шешімім мен трагедиялық шешім арасындағы жалғыз айырмашылық - ол жақсы атау конвенциясына ие.
қосылды автор Suhas, көзі
REST конвенцияны атау туралы емес. Мұның бәрі REST API құрастыру кезінде «әрекеттердің» орнына ресурстар туралы ойлау туралы. Әрқашан URL/URI-дегі 'Nonce' ресурсы туралы ойлау керек. Сізде бұрыннан бар домендік әрекеттерді салыстыруға және URL мекенжайындағы ресурстарды басқаруға арналған барлық CURD әрекеттері бар.
қосылды автор Ming Chan, көзі
'DisabledMember' дизайнымен, іс жүзінде ресурстағы 'disable' әрекетін «жасырады». Сіз оны қалаған нәрсені істеуге мәжбүр ете аласыз, бірақ ол мен үшін тыныш болмайды.
қосылды автор Ming Chan, көзі
Бұл қажет емес, бірақ ол іскерлік логика себептері үшін көп болады; мысалы, Жоюға тыйым салу үшін, ол осы ресурсты жасағаннан кейін «алып тастауға» болмайды. Мен әдетте өзімнің жобалық таңдауымды жасауға көмектесу үшін CURD етістіктерінің барлығын ескеріп, ресурс атауы арқылы ойланамын.
қосылды автор Ming Chan, көзі

мұнда .

Ойлаудың практикалық тәсілі немесе REST-ды бастапқы нүкте ретінде қолдану (кем дегенде ол мен үшін жұмыс істейді) келесі жолдарды ойластырады:

1) HTTP «GET/POST/PUT/DELETE» дегенді доменнің әрекеттерін модельдеу әдісі ретінде пайдаланыңыз. Дерекқормен айналысқан кездегідей, барлық әрекеттеріңіз CURD сілтемесі бойынша көрсетіледі.

2) URI/URL ресурстарды тек қана анықтау. URI-іңізде ешқашан 'әрекеттер' болмауы керек.

3) Деректер алмасу HTTP хабарламаларының корпусында болуы керек. Тек талқылауды оңайлату үшін, деректердің өзін қалай модельдеуге кіріспеу керек

Трагедияның шешімі таза көрінеді.

Мекенжайға жаңартылған @Suhas 'comments

REST конвенцияны атау туралы емес. Мұның бәрі REST API құрастыру кезінде «әрекеттердің» орнына ресурстар туралы ойлау туралы. Әрқашан URL/URI-дегі 'Nonce' ресурсы туралы ойлау керек. Сізде бұрыннан бар домендік әрекеттерді салыстыруға және URL мекенжайындағы ресурстарды басқаруға арналған барлық CURD әрекеттері бар.

Мен Трагедияның шешімін ұнатамын, тек пікірталас үшін, Tragedian-дің шешімдерін түрлі домендік пайдалануға сәйкес келетін «жақсы» үшін бірдей емес және әртүрлі URL-үлгісімен жинақтай аламыз. Төменде домен үшін ең жақсы шешім болмауы мүмкін, бірақ олар баламалы түрде RESTful.

Мүшелік жою

  • DELETE api/мүшелігі/[member-id]/

Мүшелік мәртебесін алу

  • GET api/мүшелігі/[member-id]/status/

Мүшелік қосу

  • POST api/мүшелігі/[member-id]/

Ресурс ретінде «DisabledMember» -мен мәселені шешу үшін жаңартылды

Егер «Suhas» ұсынғандай, «PUT DisabledMember» функциясын пайдалансаңыз, 'мүшені ажырату' керек Сонда 'DisabledMember' ресурсында келесі әрекеттер нені білдіреді?

DELETE DisabledMember → қайта белсендіріңіз?

POST DisabledMember -> ??

GET DisabledMember - бұл оңай☺

Бұл дизайнмен шын мәнінде ресурстағы 'disable' әрекетін «жасырады». Сіз оны қалаған нәрсені істеуге мәжбүр ете аласыз, бірақ ол мен үшін тыныш болмайды.

1
қосылды
Мен тек «іскерлік себептермен» дегенді айтқанымда. Мысалы: Егер DELETE бұғаттауына тыйым салсам DisabledMember - бұл бизнеске байланысты.
қосылды автор Suhas, көзі
Әрбір ресурс әрбір HTTP әрекетін қолдауы керек пе? DELETE/POST DisabledMember -де HTTP 405 рұқсат етілмеген
қосылды автор Suhas, көзі
Мен ресурс айналасында жобалау туралы ойланамын. Бірақ менің үшінші дизайным бойынша DisabledMember деп аталатын жаңа ресурсты енгізу туралы түсініктеме көрмеймін. Осы дизайнмен байланысты проблемалар бар ма?
қосылды автор Suhas, көзі
Менің екінші шешімім мен трагедиялық шешім арасындағы жалғыз айырмашылық - ол жақсы атау конвенциясына ие.
қосылды автор Suhas, көзі
REST конвенцияны атау туралы емес. Мұның бәрі REST API құрастыру кезінде «әрекеттердің» орнына ресурстар туралы ойлау туралы. Әрқашан URL/URI-дегі 'Nonce' ресурсы туралы ойлау керек. Сізде бұрыннан бар домендік әрекеттерді салыстыруға және URL мекенжайындағы ресурстарды басқаруға арналған барлық CURD әрекеттері бар.
қосылды автор Ming Chan, көзі
'DisabledMember' дизайнымен, іс жүзінде ресурстағы 'disable' әрекетін «жасырады». Сіз оны қалаған нәрсені істеуге мәжбүр ете аласыз, бірақ ол мен үшін тыныш болмайды.
қосылды автор Ming Chan, көзі
Бұл қажет емес, бірақ ол іскерлік логика себептері үшін көп болады; мысалы, Жоюға тыйым салу үшін, ол осы ресурсты жасағаннан кейін «алып тастауға» болмайды. Мен әдетте өзімнің жобалық таңдауымды жасауға көмектесу үшін CURD етістіктерінің барлығын ескеріп, ресурс атауы арқылы ойланамын.
қосылды автор Ming Chan, көзі

Мүшенің белсенді және Disabled күйі бар

Осылайша мәртебе - мүше/ресурстың мүлкі. Бұл жағдайда неге сіз мүше ресурсында PUT әдісін «Disabled» күйіне орнатылған жаймен қолданғыңыз келмейді?

0
қосылды
Мүшенің клиенттері жаңартқысы келетін басқа да көптеген өрістер бар. Олар бұл жағдайды қолдануға тырысады. Бұл жаңартулар, әдетте, ешқандай басқа жұмыс үрдісіне жол бермейді. Олар деректер қорына қарапайым жаңартулар. Бірақ мүшені ажырату күрделі жұмыс үрдісі және оны мүше жаңартудан тұжырымдама ретінде бөлу қажет.
қосылды автор Suhas, көзі
Сұрау жолын білдіреді ме? Параметрлерде жіберу үшін поштадағы сұрау жолдарын қолданатынына күмәнданамын. Олардың бәрін басқаруға арналған бір лауазым маған БТЖ бұзу сияқты көрінеді.
қосылды автор Suhas, көзі
сізде мүшелер/{someId} астында ресурс бар. Бұл ресурсты шығарып алу үшін GET, DELETE - бұл ресурсты жою үшін, PUT - осы ресурсты жаңарту үшін пайдаланасыз. POST әдісі тегін, сондықтан оны пайдаланушыны өшіруді белсендіру үшін пайдалануға болады
қосылды автор maks, көзі
Егер сізде жұмыс процесін бастаудың бірнеше жағдайлары болса, онда POST әдісіне түрлі параметрлер бойынша сәйкестендіруге болады
қосылды автор maks, көзі

Мүшенің белсенді және Disabled күйі бар

Осылайша мәртебе - мүше/ресурстың мүлкі. Бұл жағдайда неге сіз мүше ресурсында PUT әдісін «Disabled» күйіне орнатылған жаймен қолданғыңыз келмейді?

0
қосылды
Мүшенің клиенттері жаңартқысы келетін басқа да көптеген өрістер бар. Олар бұл жағдайды қолдануға тырысады. Бұл жаңартулар, әдетте, ешқандай басқа жұмыс үрдісіне жол бермейді. Олар деректер қорына қарапайым жаңартулар. Бірақ мүшені ажырату күрделі жұмыс үрдісі және оны мүше жаңартудан тұжырымдама ретінде бөлу қажет.
қосылды автор Suhas, көзі
Сұрау жолын білдіреді ме? Параметрлерде жіберу үшін поштадағы сұрау жолдарын қолданатынына күмәнданамын. Олардың бәрін басқаруға арналған бір лауазым маған БТЖ бұзу сияқты көрінеді.
қосылды автор Suhas, көзі
сізде мүшелер/{someId} астында ресурс бар. Бұл ресурсты шығарып алу үшін GET, DELETE - бұл ресурсты жою үшін, PUT - осы ресурсты жаңарту үшін пайдаланасыз. POST әдісі тегін, сондықтан оны пайдаланушыны өшіруді белсендіру үшін пайдалануға болады
қосылды автор maks, көзі
Егер сізде жұмыс процесін бастаудың бірнеше жағдайлары болса, онда POST әдісіне түрлі параметрлер бойынша сәйкестендіруге болады
қосылды автор maks, көзі

Пайдаланушыны өшірудің қысқаша үрдісі болса, неге HTTP PATCH пайдалану керек?

Осыған ұқсас сұраққа жауапты қараңыз

0
қосылды
Мен сұрақтарға толықтырулар енгіздім. Мүшені ажырату қарапайым жаңарту емес.
қосылды автор Suhas, көзі