Comments 13
Давайте сразу поймем отличия: "В чем разница между PUT и PATCH?". Этот вопрос вы также можете часто слышать на собеседовании.
Справедливости ради, разницы нет никакой. Patch, put, get, post и другие - просто один из параметров запроса, сервер волен обрабатывать как ему вздумается. Поэтому правильный ответ - зависит от реализации сервера.
В том же json-rpc вообще все запросы - POST
Что происходит за кулисами: Запрос: «Обнови запись с ID=789, заменив старые данные на эти».
Вот ни разу не догма. За кулисами может быть, например, такое:
Удали старую версию записи с ID=789, и создай вместо неё новую, с ID=789 и новыми данными.
Или такое:
Создай новую запись с ID=789, новыми данными, и установи значение поля version на единицу больше максимального для уже имеющихся записей с ID=789.
И даже такое:
Установи у имеющейся записи с ID=789 значение поля actual=FALSE, и cоздай новую запись с ID=789, новыми данными и actual = TRUE.
Аналогично - для DELETE.
В общем, маппинг операции на фронте на операцию на бэке - он ни разу не 1:1 (хотя может и оказаться таковым). И маппинг операции на бэке на операцию в СУБД тоже не 1:1.
PS. Но вообще - сплошная вода, тянет разве что на введение к статье на заявленную тему...
Просто мысли вслух по поводу круда (не статьи), если позволите.
Мы можем создать элемент, прочитать его, обновить и удалить. А как насчёт получить список элементов?
В этом месте говорят: легко! Это тоже Read, но не элемента, а коллекции.
Но по такой логике создание и удаление элемента — это просто обновление коллекции, верно. Тогда зачем в C.R.U.D нужны C и D?
А как насчёт получить список элементов?
Для получения списка надо прочитать каждый из элементов этого списка.
Это тоже Read, но не элемента, а коллекции.
А не надо слушать кого попало. Различайте чтение элемента и организацию цикла по чтению каждого из элементов. Цикл и его организация (включая и накопление результата) - с точки зрения процесса чтения элемента штука совершенно внешняя, чуждая, инородная, и даже как бы ненужная.
по такой логике создание и удаление элемента — это просто обновление коллекции, верно
Совершенно очевидно, что это неверно.
Для получения списка надо прочитать каждый из элементов этого списка.
Я имею в виду самый обычный листинг. Чтобы получить список файлов в папке, не обязательно же читать их содержимое?
Совершенно очевидно, что это неверно.
Understandable, have a nice day.
Я имею в виду самый обычный листинг. Чтобы получить список файлов в папке, не обязательно же читать их содержимое?
Чтобы получить список файлов в папке ака листинг вашим методом, файлам вообще не требуется существовать. Достаточно, чтобы существовали записи о файлах в файле папки. И обращаетесь вы вовсе не к файлам, а к файлу папки. Метаданные файла - не являются составной частью файла.
Я вас не понимаю.
Пишу: для получения списка элементов (например, имена файлов или список урлов, ничего не писал про их содержимое!), нужно прочитать объект-коллекцию (например, директорию), вы говорите, что это штука инородная и чуждая.
А потом говорите, что чтобы получить метаданные файла нужно прочитать файл директории.
Ну как так?
Давайте вернёмся к исходной формулировке ситуации.
Мы можем создать элемент, прочитать его, обновить и удалить. А как насчёт получить список элементов?В этом месте говорят: легко! Это тоже Read, но не элемента, а коллекции.
Что такое коллекция в данном случае? в вашем понимании.
Если ориентироваться на вашу (странную) фразу "Это тоже Read, но не элемента, а коллекции", то создаётся весьма странная ситуация - коллекция, по вашему мнению, не имеет никакого отношения к элементу, в неё входящему, и наоборот. Изменение элемента - на коллекции никак не отразится. Очевидно, что это не так, и изменяющая операция над элементом изменяет и коллекцию. И, соответственно, чтение коллекции и чтение элементов коллекции - не одно и то же.
Вам требуется получить некий список. То есть набор записей, каждая из которых содержит значение некоего (возможно, идентифицирующего, но в общем случае необязательно, и даже, возможно, неуникального или пустого) свойства одного экземпляра (элемента) этого списка. Расскажите, как вы намерены получить значение этого свойства, не обращаясь к самому элементу? Коллекция содержит ссылки на элементы в форме идентифицирующих значений атрибутов, но за любым другим атрибутом придётся лезть в соответствующий экземпляр.
Как я говорил выше, то, что вам нужно, с точки зрения экземпляра сущности Элемент Коллекции есть внешнее и в области его видимости несуществующее. А снаружи это есть метаданные коллекции экземпляров.
API — это мост между пользователем и системой,
Каким еще нафиг пользователем? API — это мост для общения между двумя системами.
Именно эти операции [CRUD] лежат в основе всей архитектуры веб-приложений (соцсетей, интернет-магазинов, банковских приложений), API и баз данных.
Я написал за свою жизнь более десятка разных API и это никогда не был CRUD. Вы бы полегче с обобщениями, в сложных системах CRUD занимает сто пятое место и общение с пользователем вообще — это то, что можно безболезненно доверить джунам и ллмкам.
Что такое CRUD и почему это важно для всех в IT