REST против RPC в PHP

Ответ 1

Ухм... чтобы это было просто, обе очень абстрактные модели... так абстрактны, они, естественно, происходят повсюду...

REST - это идея иметь ресурсы, адресованные глобальным идентификатором (URI в случае HTTP), к которым обращаются в CRUD (используя POST, GET, PUT и DELETE в случае HTTP... ну, по крайней мере, эта идея)...

RPC - это идея, когда вы вызываете процедуру на другой машине, передаете некоторые параметры и принимаете возвращаемое значение...

В Википедии есть хорошее короткое сравнение

Persevere создает сервис, который позволяет (и очень элегантно, по общему признанию)... RESTful (хотя он не только использует HTTP-функции для достижения этого) и предоставляет интерфейс RPC...

В конце концов, вы должны посмотреть, что нужно делать вашему приложению... как и большинство людей, вы, вероятно, закончите с API RPC (основываясь на XML или JSON или что-то еще), который включает в себя транспортный уровень для частично подсистемы RESTful... это потому, что наличие RESTfulnes означает гибкость... если клиент может более или менее свободно перемещаться по данным на сервере (через набор простых CRUD-методов), он не зависит от ограниченного (специфичного для конкретной задачи ) набор методов, открытых через API, и вы можете сдвинуть логику навстречу...

Ответ 2

Лучший способ понять это - прочитать статью Роя Т. Филдинга о нем или соответствующие статьи в своем блоге где он обсуждает различия между чистой REST и просто архитектурой RPC.

Еще одно замечание: статья Википедии о REST находится в ужасном состоянии, и сам Филдинг, "изобретатель" REST, предполагает, что статья неточна.

Самое большое, что люди пропускают с REST - это открытость - ресурсы должны включать URI для других связанных ресурсов внутри их гипертекста, вместо того чтобы полагаться на соглашения об именах URI, которые являются внеполосными и нестандартизированными.

Большая проблема с популярными реализациями RPC, такими как SOAP или XML-RPC, заключается в том, что они используют HTTP под собственной собственной архитектурой, вместо того, чтобы использовать все различные свойства HTTP, такие как PUT, GET, DELETE и т.д. t подходит и к традиционному веб-стеклу - кэш-сервер посередине не работает, например, не зная о значении содержимого вызова RPC.

Это неполное введение в REST и RPC, но я думаю, что я выделил некоторые важные моменты, которые часто упускаются. Будьте осторожны, так как в REST есть много неправильной информации.

Тем не менее, REST не для всего. Это архитектура, поэтому она довольно гибкая, как вы можете ее реализовать. Но если нет смысла обращаться к вещам в основном как к ресурсам, тогда REST может не соответствовать, или он может соответствовать только частям вашего приложения, что хорошо.

Ответ 3

Существует три разных стиля сервисов:

• RPC API - клиент отправляет процедуру и параметры для обслуживания, а служба отвечает за выполнение команды и возвращает результат.
• API сообщений (Document API) - клиент отправляет DOM (элементы), которые обычно являются более сложными структурами, чем вызовы API RPC, поскольку они, как правило, не подразумевают операции напрямую.
• API ресурсов - используется для доступа к ресурсам (кортежи баз данных, файлы, изображения и т.д.). В общем случае он также должен обеспечить хорошее согласование типа носителя.

SOAP и REST являются компиляцией стандартов W3C, и основное различие заключается в том, что SOAP использует HTTP, SMTP и т.д. в качестве транспортных протоколов и REST использует его как протокол приложения, AKA, который он должен поддерживать (GET, PUT, PUSH, DELETE и POST). SOAP также подразумевает, что использование XML и REST может использовать любой тип данных (JSON, XML, HTTP и т.д.). Кроме того, одним из основных преимуществ SOAP является дескриптор службы (файл WSDL), который дает возможность автогенерации Service Connector (прокси) для клиента.

Нет серебряная марка; тип и архитектура веб-службы зависят от фактических требований клиента и технологии.

Для общей идеи по этому вопросу см. одну из подписных книг Мартина Фаулера - Шаблоны проектирования услуг