Я создаю свой собственный сайт Ajax, и я размышляю между REST и RPC.
Если мой сервер поддерживает сервлеты, я просто установил persevere и устранил проблему, но мой сервер не поддерживает сервлеты.
RPC проще кодировать (IMO) и может быть легко написан на PHP. Все, что мне нужно, это исполняемый файл запроса к базе данных. Я использую Dojo Toolkit и JSON.
Почему я должен выбрать REST над RPC или RPC над REST?
Ухм... чтобы это было просто, обе очень абстрактные модели... так абстрактны, они, естественно, происходят повсюду...
REST - это идея иметь ресурсы, адресованные глобальным идентификатором (URI в случае HTTP), к которым обращаются в CRUD (используя POST, GET, PUT и DELETE в случае HTTP... ну, по крайней мере, эта идея)...
RPC - это идея, когда вы вызываете процедуру на другой машине, передаете некоторые параметры и принимаете возвращаемое значение...
В Википедии есть хорошее короткое сравнение
Persevere создает сервис, который позволяет (и очень элегантно, по общему признанию)... RESTful (хотя он не только использует HTTP-функции для достижения этого) и предоставляет интерфейс RPC...
В конце концов, вы должны посмотреть, что нужно делать вашему приложению... как и большинство людей, вы, вероятно, закончите с API RPC (основываясь на XML или JSON или что-то еще), который включает в себя транспортный уровень для частично подсистемы RESTful... это потому, что наличие RESTfulnes означает гибкость... если клиент может более или менее свободно перемещаться по данным на сервере (через набор простых CRUD-методов), он не зависит от ограниченного (специфичного для конкретной задачи ) набор методов, открытых через API, и вы можете сдвинуть логику навстречу...
Лучший способ понять это - прочитать статью Роя Т. Филдинга о нем или соответствующие статьи в своем блоге где он обсуждает различия между чистой REST и просто архитектурой RPC.
Еще одно замечание: статья Википедии о REST находится в ужасном состоянии, и сам Филдинг, "изобретатель" REST, предполагает, что статья неточна.
Самое большое, что люди пропускают с REST - это открытость - ресурсы должны включать URI для других связанных ресурсов внутри их гипертекста, вместо того чтобы полагаться на соглашения об именах URI, которые являются внеполосными и нестандартизированными.
Большая проблема с популярными реализациями RPC, такими как SOAP или XML-RPC, заключается в том, что они используют HTTP под собственной собственной архитектурой, вместо того, чтобы использовать все различные свойства HTTP, такие как PUT, GET, DELETE и т.д. t подходит и к традиционному веб-стеклу - кэш-сервер посередине не работает, например, не зная о значении содержимого вызова RPC.
Это неполное введение в REST и RPC, но я думаю, что я выделил некоторые важные моменты, которые часто упускаются. Будьте осторожны, так как в REST есть много неправильной информации.
Тем не менее, REST не для всего. Это архитектура, поэтому она довольно гибкая, как вы можете ее реализовать. Но если нет смысла обращаться к вещам в основном как к ресурсам, тогда REST может не соответствовать, или он может соответствовать только частям вашего приложения, что хорошо.
Существует три разных стиля сервисов:
SOAP и REST являются компиляцией стандартов W3C, и основное различие заключается в том, что SOAP использует HTTP, SMTP и т.д. в качестве транспортных протоколов и REST использует его как протокол приложения, AKA, который он должен поддерживать (GET, PUT, PUSH, DELETE и POST). SOAP также подразумевает, что использование XML и REST может использовать любой тип данных (JSON, XML, HTTP и т.д.). Кроме того, одним из основных преимуществ SOAP является дескриптор службы (файл WSDL), который дает возможность автогенерации Service Connector (прокси) для клиента.
Нет серебряная марка; тип и архитектура веб-службы зависят от фактических требований клиента и технологии.
Для общей идеи по этому вопросу см. одну из подписных книг Мартина Фаулера - Шаблоны проектирования услуг