AM
Если же пытаться как-то в одном "логическом" запросе удалить сразу группу ресурсов, то, мне кажется, это неприемлемо.
Size: a a a
2020 November 30
AM
Если же пытаться как-то в одном "логическом" запросе удалить сразу группу ресурсов, то, мне кажется, это неприемлемо.
> Типа сделать не один запрос с кучей id
Вот об этом как раз речь, мол неприемлемо
Вот об этом как раз речь, мол неприемлемо
AN
Если в целом речь про подход REST Full без RPC. Я же правильно помню, что там говорится как раз про работу с ресурсами, по одиночке. И если нужно удалить 10 записей, то делай 10 запросов, так?
ЕР
Если в целом речь про подход REST Full без RPC. Я же правильно помню, что там говорится как раз про работу с ресурсами, по одиночке. И если нужно удалить 10 записей, то делай 10 запросов, так?
Нет, там такого не говорится
ЕР
Как тебе удобнее, так и делай
AM
Нет, там такого не говорится
А как тогда подразумевать идентификатор ресурса в запросах и текст, связанный с этим?
AN
Нет, там такого не говорится
Я может не правильно выражаюсь, речь не про транспорт в виде реста, а прям архитектурный подход.
ЕР
А как тогда подразумевать идентификатор ресурса в запросах и текст, связанный с этим?
Коллекция ресурсов - тоже ресурс
AM
Возможно, группу ресурсов можно обозначить одним ресурсом другого типа и тогда будет приемлемо. Но тогда это будет "статически", а не "динамически", мне кажется
ЕР
Я может не правильно выражаюсь, речь не про транспорт в виде реста, а прям архитектурный подход.
Ты не используешь этот подход. Забей.
AM
Коллекция ресурсов - тоже ресурс
Согласен. И, в принципе, идентификатор тоже может быть составлен из идентификаторов других ресурсов, насколько я сейчас понял
AM
Возможно, группу ресурсов можно обозначить одним ресурсом другого типа и тогда будет приемлемо. Но тогда это будет "статически", а не "динамически", мне кажется
Если сделать правильно, то вот тут я некорректно выразился (во второй части)
ЕР
Я может не правильно выражаюсь, речь не про транспорт в виде реста, а прям архитектурный подход.
Ну то есть, можешь вбить rest в поиск по пхп/сф/ооп чатикам, и просто понять что всё, что нынче зовётся "rest" никакого четкого определения не имеет, и к изначальному описанию от Филдинга так же мало имеет отношения
ЕР
Поэтому пытаться выяснить какой REST "правильный" чутка бессмысленно
ЕР
В REST по Филдингу ключевое это вообще управление ресурсами через представления(html), а не вот эти вот все жсончики с данными
AM
В REST по Филдингу ключевое это вообще управление ресурсами через представления(html), а не вот эти вот все жсончики с данными
Так json тоже представление.
AM
Зависит что в целом приложением является и насколько детально абстрагироваться
ЕР
Так json тоже представление.
Не
AM
Почему?
ЕР
Мы в терминах REST же