Як правильно спроектувати протокол обміну даними між клієнтом та веб-сервісом
Я створюю деякий веб-сервіс з публічним API, доступним через HTTP. Так як API передбачається публічним, хочеться врахувати всі підводні камені заздалегідь - інакше доведеться робити нову версію протоколу і підтримувати обидві - жах :)
Однак не дуже зрозуміло, як оформити передачу даних назад клієнту. На даний момент, інформацію про результат запиту я кодую HTTP статусом ( 200 , 403 , 404 , 500 , etc.), а якщо потрібно ще щось, то я просто передаю клієнту суцільним текстом значення в заданому порядку, розділені символом-розділювачем ( наприклад, 17:150: ковбаса) у тілі відповіді.
Я подумав було, що має сенс використовувати для цього XML, бо зараз усе так роблять — мабуть, недарма. Але, повивчивши цю тему, зрозумів, що при такому підході прийнято параметри запиту на сервер передавати у вигляді XML.
Як бути? Використовувати простий рядок параметрів із роздільниками або переходити на XML? Чи можна при цьому надсилати дані серверу у вигляді параметрів запиту?
Цікавлять відповіді з погляду того, що прийнято чи не прийнято і наскільки це погано відходити від прийнятого. Фізично як завгодно можна зробити.
По-перше, забудьте про XML, його вигадали чиновники. Ось нехай вони його і використовують у своїх банках та податкових. Для парсингу та кодування JSON достатньо пари функцій по 10 рядків кожен. Для парсингу XML, навіть якщо в ньому є кілька значень, потрібно підвантажувати монструозні бібліотеки.
По-друге, якщо ви робите веб-додаток, використовуйте можливості протоколу HTTP. Це означає ідеологія REST, а чи не RPC. Тобто замість якихось там «процедур» чи «функцій», ви танцюєте від об'єктів та стандартних дій. Наприклад, у вас є об'єкт зідентифікатор obj_id. Для будь-якого доступу до нього використовується URL виду
Далі по цьому URL-і можливі 4 дії (http verb): 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/to
Залежно від результату операції, ви повинні повертати правильні коди помилок (200 OK, 404 Not Found, 403 Forbidden тощо).