Как правилно да проектирам комуникационен протокол между клиент и уеб услуга

Създавам някаква уеб услуга с публичен API, достъпен през HTTP. Тъй като API трябва да е публичен, искам да взема предвид всички клопки предварително - в противен случай ще трябва да направите нова версия на протокола и да поддържате и двете - ужас :)

Не е много ясно обаче как да се организира прехвърлянето на данни обратно към клиента. В момента кодирам информация за резултата от заявката с HTTP статус ( 200 , 403 , 404 , 500 и т.н.) и ако е необходимо нещо друго, тогава просто предавам стойностите на клиента в плътен текст в дадения ред, разделени с разделителен знак (например 17:150:наденица ) в тялото на отговора.

Мислех, че има смисъл да използвам XML за това, защото сега всеки го прави - вероятно с причина. Но след като проучих тази тема, разбрах, че с този подход е обичайно да се прехвърлят параметри на заявката към сървъра под формата на XML.

Как да бъдем? Да използвате прост разделен низ от параметри или да преминете към XML? Все още ли е възможно да се изпращат данни към сървъра под формата на параметри на заявката?

Интересуват се от отговори по отношение на това какво е прието или не и колко лошо е да се отклоняваш от приетото. Физически всичко може да се направи.

Първо, забравете за XML, бюрократите са го измислили. Така че нека го използват в своите банки и данъчни власти. За анализиране и кодиране на JSON са достатъчни няколко функции от по 10 реда. За да анализирате XML, дори ако съдържа няколко стойности, трябва да заредите чудовищни ​​библиотеки.

Второ, тъй като правите уеб приложение, използвайте възможностите на HTTP протокола. Това означава REST идеология, а не RPC. Тоест, вместо някакви „процедури“ или „функции“, вие танцувате от обекти и стандартни действия. Например имате обект сobj_id идентификатор. За всеки достъп до него, URL на формата

Освен това са възможни 4 действия на този URL адрес (http глагол): GET example.com/path/to/obj_id — получаване на данни за обект PUT example.com/path/to/obj_id — промяна на обект DELETE example.com/path/to/obj_id — изтриване на обект POST example.com/path/to/ — създаване на нов обект в /path/to папка GET example.com/path/to/ — получаване всички обекти в /path folder /to

В зависимост от резултата от операцията, трябва да върнете правилните кодове за грешка (200 OK, 404 Not Found, 403 Forbidden и т.н.).