ОТДЫХ против RPC в PHP [закрыт]
Я создаю свой собственный веб-сайт Ajax, и я размышляю между REST и RPC.
Если бы мой сервер поддерживал сервлеты, я бы просто установил , продолжил и решил проблему, но мой сервер не поддерживает сервлеты.
RPC проще в программировании (IMO) и может быть легко написан на PHP. Все, что мне нужно, - это исполнитель запросов к базе данных. Я использую Инструментарий Dojo и JSON.
Почему я должен выбирать REST вместо RPC или RPC вместо REST?
3 answers
Хм... проще говоря, и то, и другое - очень абстрактные модели... настолько абстрактные, что они естественным образом встречаются повсюду...
REST - это идея обращения к ресурсам с глобальным идентификатором (URI в случае HTTP), доступ к которым осуществляется способом CRUD (с использованием POST, ПОЛУЧИТЬ, ПОМЕСТИТЬ и УДАЛИТЬ в случае HTTP... ну, по крайней мере, такова идея)...
RPC - это идея, когда вы вызываете процедуру на другой машине, передавая некоторые параметры, и принимая возвращаемое значение...
В Википедии есть хорошее короткое сравнение
Persevere создает сервис, который позволяет и то, и другое (по общему признанию, очень элегантно)... это спокойный (хотя для этого используются не только HTTP-функции) и предоставляет интерфейс RPC...
В конце концов, вы должны посмотреть, что должно делать ваше приложение... как и большинство людей, вы, вероятно, получите API RPC (будь то на основе XML или JSON или что-то еще), который включает транспортный уровень для частично спокойной подсистемы... это происходит потому, что наличие отдыха означает гибкость... если клиент может более или менее свободно просматривать данные на сервере (с помощью набора простых методов CRUD), это не зависит от ограниченного (специфичного для конкретной проблемы) набора методов, предоставляемых через API, и вы можете переключить логику клиента...
Лучший способ понять это - прочитать Роя Т. Диссертация Филдинга об этом или соответствующие статьи в его блоге , где он обсуждает различия между архитектурой pure REST и просто RPC.
Еще следует отметить, что статья в Википедии об ОТДЫХЕ находится в плачевном состоянии, и сам Филдинг, "изобретатель" ОТДЫХА, предполагает, что статья неточна.
Самое большое, чего не хватает людям в ОТДЫХЕ, - это открытость - ресурсы должны включать URI для других связанных ресурсов внутри их гипертекста, вместо того, чтобы полагаться на соглашения об именовании URI, которые являются внеполосными и нестандартизированными.
Большая проблема с популярными реализациями RPC, такими как SOAP или XML-RPC, заключается в том, что они используют HTTP под своей собственной проприетарной архитектурой, вместо того, чтобы использовать все различные свойства HTTP, такие как PUT, GET, DELETE и т.д. Таким образом, это также не соответствует традиционному веб-стеку - сервер кэша в середине не работает, для например, не зная о значении содержимого вызова RPC.
Это неполное введение в REST и RPC, но я думаю, что выделил некоторые важные моменты, которые часто упускаются. Будьте осторожны, так как в REST много неверной информации.
Тем не менее, ОТДЫХ не для всего. Это архитектура, поэтому ее реализация довольно гибкая. Но если нет смысла обращаться к вещам в первую очередь как к ресурсам, то ОТДЫХ может не подходит, или он может подходить только для частей вашего приложения, что нормально.
Существует три различных типа услуг:
- RPC API - клиент отправляет процедуру и параметры в службу, и служба отвечает за выполнение команды и возврат результата.
- API сообщений (API документов) - клиент отправляет доменные имена (элементы), которые обычно представляют собой более сложные структуры, чем вызовы API RPC, поскольку они, как правило, не подразумевают операции напрямую.
- API ресурсов - используется для доступа ресурсы (кортежи баз данных, файлы, изображения и т. Д.). В целом он также должен обеспечивать хорошее согласование типов носителей.
SOAP и REST представляют собой компиляцию стандартов из W3C, и основное различие заключается в том, что SOAP использует HTTP, SMTP и т. Д. В качестве транспортных протоколов, а REST использует его в качестве протокола приложения, он же должен поддерживать (ПОЛУЧАТЬ, ПОМЕЩАТЬ, НАЖИМАТЬ, УДАЛЯТЬ и ПУБЛИКОВАТЬ). SOAP также подразумевает использование XML, а REST может использовать любой тип данных (JSON, XML, HTTP и т. Д.). Кроме того, один из основных преимуществами SOAP является дескриптор службы (файл WSDL), который предоставляет возможность автоматической генерации соединителя службы (прокси) клиенту.
Не существует серебряной пули; тип и архитектура веб-службы зависят от реальных требований клиента и технологии.
Для получения общей идеи по этому вопросу см. Одну из книг с подписями Мартина Фаулера - Шаблоны проектирования сервисов