Разве ресурсоориентированность на самом деле не объектно-ориентирована?
https://stackoverflow.com/questions/152871
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianВопрос
Когда вы думаете об этом, не сводится ли парадигма REST, ориентированная на ресурсы, к объектно-ориентированной (с ограниченной функциональностью, максимально использующей HTTP)?
Я не обязательно говорю, что это плохо, скорее, что если они по сути, то же самое очень похоже, тогда становится намного легче понять REST и последствия, которые влечет за собой такая архитектура.
Обновить: Вот более конкретные детали:
- Ресурсы REST эквивалентны открытым классам.Частные классы / ресурсы просто не доступны.
- Состояние ресурса эквивалентно общедоступным методам или полям класса.Частные методы / поля / состояние просто не отображаются (это не значит, что их там нет).
- Хотя, безусловно, верно, что REST не сохраняет состояние, зависящее от конкретного клиента, во всех запросах, это делает сохраняйте состояние ресурсов для всех клиентов.Ресурсы иметь состояние, точно так же, как классы имеют состояние.
- Ресурсы REST глобально однозначно идентифицируются с помощью URI точно так же, как объекты сервера глобально однозначно идентифицируются по их адресу базы данных, имени таблицы и первичному ключу.Конечно, (пока) нет URI для представления этого, но вы можете легко создать его.
Решение
REST похож на OO в том смысле, что они оба моделируют мир как сущности, которые принимают сообщения (т. Е. методы), но помимо этого они разные.
Объектная ориентация подчеркивает инкапсуляцию состояния и непрозрачность, используя как можно больше различных методов, необходимых для воздействия на государство.ОСТАЛЬНОЕ касается передачи (представления) состояния и прозрачность.Количество методов, используемых в REST, ограничено и единообразно по всем ВСЕ Ресурсы.Наиболее близким к этому в ООП является ToString() метод, который очень приблизительно эквивалентен HTTP GET.
Ориентация объекта - это с сохранением состояния--вы ссылаетесь на объект и можете вызывать методы для него, сохраняя состояние в течение сеанса, когда объект все еще находится в области видимости.ОТДЫХ - это лицо без гражданства--все, что вы хотите сделать с ресурсом, указано в одном сообщении, и все, что вам когда-либо нужно было знать об этом сообщении, отправляется обратно в одном ответе.
В объектной ориентации, не существует концепции универсальной идентичности объекта--объекты получают идентификатор либо из своего адреса в памяти в любой конкретный момент, UUID, специфичного для платформы, либо из ключа базы данных.В ПОКОЕ все ресурсы идентифицируются с помощью URI и не нуждаются в создании экземпляра или удалении - они всегда существуют в облаке, если только сервер не ответит 404 Не найдено или 410 Исчез, в этом случае вы знаете, что нет ресурса с этим URI.
ОТДЫХ имеет гарантии безопасность (например, полученное сообщение не изменит состояние) и идемпотентность (например, запрос PUT, отправленный несколько раз, имеет тот же эффект, что и только один раз).Хотя в некоторых руководствах по конкретным объектно-ориентированным технологиям есть что сказать о том, как определенные конструкции влияют на состояние, на самом деле в объектной ориентации нет ничего, что говорило бы о безопасности и идемпотентности.
Другие советы
Я думаю, что есть разница между утверждением, что концепцию можно выразить в терминах объектов, и утверждением, что концепция - это то же самое как ориентация объекта.
OO предлагает способ описания концепций REST.Это не означает, что REST сам реализует OO.
Вы правы.Дэн Коннолли писал статья об этом в 1997 году.Тот Самый Филдинговская диссертация тоже говорит об этом.
Объекты объединяют состояние и функцию воедино.Ресурсоориентированность заключается в явном моделировании состояния (данных), ограничении функции предопределенными глаголами с универсальной семантикой (в случае HTTP, GET / PUT / POST / DELETE) и оставлении остальной обработки клиенту.
В мире объектной ориентации нет эквивалента этим понятиям.
Только в том случае, если ваши объекты являются DTO (Объекты передачи данных) - поскольку на самом деле у вас не может быть иного поведения, кроме настойчивости.
Да, ваша параллельность объектной ориентации верна.
Дело в том, что большинство веб-сервисов (REST, RESTful, SOAP, ..) могут передавать информацию в виде объектов, так что это не то, что отличает их.SOAP, как правило, приводит к меньшему количеству сервисов с большим количеством методов.REST, как правило, приводит к увеличению количества служб (по 1 на каждый тип ресурса) с несколькими вызовами каждой.
Да, REST - это передача объектов.Но это еще не весь объект;просто текущее состояние объекта.Неявное предположение заключается в том, что определения классов на обеих сторонах REST потенциально схожи;в противном случае состояние объекта было принудительно преобразовано в какой-то новый объект.
REST заботится только о 4 событиях в жизни объекта: create (ОПУБЛИКОВАТЬ), retrieve (ПОЛУЧИТЬ), update (ПОМЕСТИТЬ) и delete.Это важные события, но есть только эти четыре.
Объект может участвовать во множестве других событий с множеством других объектов.Все остальное в этом поведении полностью выходит за рамки подхода REST.
Существует тесная взаимосвязь - REST перемещает объекты, - но утверждение, что они одинаковы, сводит ваши объекты к пассивным наборам битов без каких-либо методов.
REST - это не только объекты, но и свойства ::запрос post в /users/john/phone_number с новым номером телефона - это не добавление нового объекта, это установка свойства пользовательского объекта "john"
Это даже не все состояние объекта, а лишь изменение небольшой части состояния.
Это, конечно, не матч со счетом 1:1.
