REST не относится к службам данных CRUD. Да, вы можете использовать REST для предоставления сервисов, подобных CRUD, но это все равно, что сказать, что регулярные выражения предназначены для анализа адресов электронной почты.
Здесь - лучшая презентация, которую я когда-либо видел на дебатах REST против SOAP / RPC.
REST гораздо больше ориентирован на решение распределенного взаимодействия клиент-сервер, чем на взаимодействие между серверами. REST - это предоставление контента пользователям, чтобы они могли выбирать, что с ним делать. REST не предназначен для создания слоя доступа к данным на основе протокола Http, чтобы отделить логику приложения от его хранилища данных.
Atom Pub - хорошая реализация REST. Netflix API - один из лучших коммерческих REST API. API Twitter не справляется с большинством ограничений RESTful.
Если вы хотите получить точную информацию о REST, перейдите в следующие места:
Не слушайте крупных вендоров по теме, которую они более заинтересованы в том, чтобы сделать их существующие продукты модными.
Последующий:
Есть несколько причин, по которым я считаю, что интерфейсы REST более подходят для взаимодействия клиент-сервер, чем от взаимодействия сервер-сервер. Это только мое мнение, и я не пытаюсь утверждать, что такой точки зрения придерживается кто-либо, кроме меня!
Соотношение многих к 1
Преимущества кэширования и сервера без сохранения состояния становятся намного более очевидными, когда вы поддерживаете множество клиентов, обращающихся к одному серверу. Связь сервер-сервер часто бывает 1-1 и редко имеет большое количество серверов, взаимодействующих с одним сервером.
Слабая связь
REST - это слабая связь. Идея состоит в том, что вы можете продолжать развивать сервер без обновления клиентов. Если вы планируете внедрить службу REST на сервере A, который будет вызываться сервером B, который находится в той же комнате, преимущества слабой связи уменьшаются. Обновление программного обеспечения на обеих машинах не убьет вас.
гипермедиа
Гипермедиа ограничена возможностью предоставления пользователям выбора на основе текущего состояния приложения. Интерфейсы REST поддерживают специальное исследование гиперссылочной системы. Связь сервер-сервер имеет тенденцию фокусироваться на достижении конкретной задачи. например Обработайте этот пакет данных. Запустите эти события в соответствии с расписанием. По сути, там нет ни одного пользователя, который бы принимал решения о том, какой путь выбрать. Путь был заранее определен на основе параметров и условий.
Performance
В сценарии связи сервер-сервер может быть критически важно достичь максимальной пропускной способности. Бинарный протокол может быть более подходящим, чем Http. Задержка может быть критической в типе обмена данными между серверами. В клиент-серверной среде, где одним концом управляет человек, требования к производительности совершенно иные, и я считаю, что ограничения REST больше подходят для такого типа взаимодействия.
* * Взаимодействие тысячи сорок-девять
REST рекомендует использовать стандартные медиа-типы в качестве полезных нагрузок HTTP. Это поощряет случайное повторное использование предоставляемых услуг. Я думаю, что существует гораздо больше возможностей для повторного использования сервисов, предназначенных для использования клиентскими приложениями, чем тех, которые предназначены для других серверов.
При проектировании интерфейсов REST мне нравится думать, что потребитель сервиса - это часть программного обеспечения, которая находится под непосредственным контролем конечного пользователя. Неслучайно веб-браузер называется агентом пользователя.