Я создаю свой собственный сайт Ajax, и я размышляю между REST и RPC.
Если мой сервер поддерживал Servlets, я бы просто установил persevere и устранил проблему, но мой сервер не поддерживает Servlets.
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 и т. Д. Таким образом, это не соответствует традиционный веб-стек, а сервер кэша посередине не работает, например, не зная о значении содержимого вызова RPC.
Это неполное введение в REST и RPC, но я думаю, что я выделил некоторые важные моменты, которые часто упускаются. Будьте осторожны, так как в REST есть много неправильной информации.
Тем не менее, REST не для всего. Это архитектура, поэтому довольно гибко, как вы можете ее реализовать. Но если не имеет смысла обращаться к вещам в первую очередь как к ресурсам, тогда REST может не соответствовать, или он может соответствовать только частям вашего приложения, что хорошо.
Существует три разных стиля услуг:
SOAP и REST представляют собой компиляцию стандартов W3C , и основное отличие состоит в том, что SOAP использует HTTP, SMTP и т. Д. В качестве транспортных протоколов, а REST использует его в качестве прикладного протокола, он должен поддерживать (GET, PUT, PUSH, DELETE и POST ). SOAP также подразумевает, что использование XML и REST может использовать любой тип данных (JSON, XML, HTTP и т. Д.). Кроме того, одним из основных преимуществ SOAP является дескриптор службы (WSDL-файл), который дает возможность автогенерации Service Connector (прокси) для клиента.
Нет серебряной пули ; тип и архитектура веб-службы зависят от реальных требований клиента и технологии.
Для общей идеи по этому вопросу см. Одну из подписных книг Мартина Фаулера – Шаблоны проектирования услуг