Здравствуйте, Проектирую rest, попутно появились следующие вопросы: 1.) Как правильно осуществлять создание сущностей? Просто отправкой post массива с описанием сущности на соотв. урл? 2.) Считается ли пакетное создание сущностей хорошей практикой? Например, если я хочу создать сразу n сущностей, я не делаю n запросов, а заливаю сразу n сущностей в одном запросе - это ок? 3.) Допустимо ли использовать get-параметры для урлов, не предназначенных для get запросов? Например если делать post/patch/delete на урл http://mysite.com/api/v1/cars?xml=1 (чтобы получить ответ сервера в формате xml вместо json).
Проблема rest в том, что в теории все знают как это делать, а когда доходит до деталей, оказывается что про это ни кто не в курсе ) 1. Создание - post на соответствующий ресурс, изменение - put/patch на нужную сущность, удаление - delete. 2. Если записей действительно много, то можно выделить отдельный метод на пакетное добавление. 3. Формат логичнее определять по "расширению", типа api/v1/cars.json или cars.xml Вменяемый док http://www.restapitutorial.ru/resources.html. А вообще, я бы сам с удовольствием почитал про такие моменты, как действительно сложные выборки, нестандартные действия, короче всё что отличается от "выбрал все записи из бложика" и "добавил новую запись в бложик". p.s. Ну и главное имхо тут всё задокументировать: какие ресурсы доступны, как их можно фильтровать, форматы выдачи, описание полей и прочее.
romach, спасибо за ответ, он полезен. 1. Да, ок. Я читал материалы по rest, просто боялся что-то упустить. 2. Тут как раз дело в том, что отдельный метод запиливать не хочется. Хочешь - заливай одну сущность, хочешь - несколько - мне кажется это удобным, но не хочется идти в разрез с устоявшейся практикой, если такая имеется. 3. Get параметр xml привел просто для примера, могут быть и другие конфигурируемые параметры. Например http://mysite.com/api/v1/cars?showAllErrors=true&ignoreValidation=true и т.д. При не-get запросах можно передавать их в теле (в пост параметрах), но тогда теряется унификация урла: чтобы получить список авто с этими же параметрами будет такой урл как выше (get запрос), а post запрос (на добавление авто) будет отправляться просто на http://mysite.com/api/v1/cars а параметры пойдут не в заголовках, а в теле запроса, в итоге в зависимости от типа запроса получаются как бы разные урлы. По-моему не то у фейсбука, не то у твиттера в API в качестве get параметра передается номер версии API вне зависимости от типа запроса. Т.е. урлы одинаковые при любых запросах и мне кажется что это хорошо. Да, конечно. API будет для внешних пользователей и хочется свести к минимуму персональные разъяснения касательно работы с API.
никогда не понимал необходимости рест =) Одного пост достаточно, а хттп стоит использовать только как транспорт. Разрабам никогда не хватает хттп для нормального взаимодействия, и начинаются шаманства с изобретением своих собственных кодов ответа и прочая муть.
igordata, как архитектурный принцип rest удобен понятной структурой урлов и запросов. Насчет метода отправки запроса - при формировании запроса особой разницы нет, будет это post или delete (например), но на этапе разбора на сервере код получается чуть удобнее и опять-же понятнее для других. Пришел delete - понятно что делаем, пришел post - тоже. Т.е. не надо искать какой-то отдельный параметр, отвечающий за тип операции. По поводу кодов ответа - согласен, но есть альтернативы. Например, использовать свой код ответа в теле ответа сервера (куда можно запихнуть пояснения и пр. кастомную инфу), для заголовков используя стандартный 200 если запрос в принципе дошел и обработан. Такая практика мне кажется более разумной, т.к. она более гибкая плюс становится возможным отличать ошибки API от системных серверных ошибок.
С последним согласен, хотя оно и не соответствует канону. igordata, главная фишка реста, что он как методология понятен всем, что облегчает документирование и избавляет пользователя от необходимости долго раскуривать замысел авторов. Это что-то типа PSR в PHP, можно и не соблюдать, но если ты работаешь в команде или делаешь опенсорс, то так всем будет проще.
Это только для начала. Потом начинаются велосипеды, т.к. хочется больше, чем рест. Я за пост. Постом отправляешь что делать, и параметры. А код 200 означает, что сервер получил и понял тебя, даже если ответил "ошибка отвали".