Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

REST vs. RPC in PHP [closed]

Tags:

json

rest

php

rpc

dojo

I'm building my own Ajax website, and I'm contemplating between REST and RPC.

If my server supported Servlets I'd just install persevere and end the problem, but my server doesn't support Servlets.

RPC is simpler to code (IMO) and can be written in PHP easily. All I need is a database query executer. I'm using the Dojo Toolkit and JSON.

Why should I choose REST over RPC or RPC over REST?

like image 808
the_drow Avatar asked Jul 08 '09 14:07

the_drow


People also ask

Which is better RPC or REST?

The most fundamental difference between RPC and REST is that RPC was designed for actions, while REST is resource-centric. RPC executes procedures and commands with ease. Alternatively, REST is ideal for domain modeling and handling large quantities of data.

Is RPC faster than REST?

“gRPC is roughly 7 times faster than REST when receiving data & roughly 10 times faster than REST when sending data for this specific payload. This is mainly due to the tight packing of the Protocol Buffers and the use of HTTP/2 by gRPC.”

Is RPC easier to maintain than JSON?

It would be better to choose JSON-RPC between REST and JSON-RPC to develop an API for a web application that is easier to understand. JSON-RPC is preferred because its mapping to method calls and communications can be easily understood.


1 Answers

The best way to understand it is to read Roy T. Fielding's dissertation on it, or relevant articles on his blog where he discusses the differences between pure REST and simply RPC architectures.

Another thing to note is that the Wikipedia article on REST is in dismal condition and Fielding himself, the 'inventor' of REST, suggests that the article is inaccurate.

The biggest thing people miss with REST is discoverability - resources should include URIs for other related resources inside their hypertext, instead of relying on URI naming conventions, which are out-of-band and non-standardized.

A big problem with popular RPC implementations like SOAP or XML-RPC is that they use HTTP underneath their own proprietary architecture, rather than taking advantage of all the different properties of HTTP like PUT, GET, DELETE etc. So this doesn't fit the traditional web stack as well - a cache server in the middle doesn't work, for example, without knowing about the meaning of the contents of the RPC call.

This is an incomplete introduction to REST and RPC but I think I've highlighted some of the important points that are often missed. Be careful, since there is a LOT of wrong information out there on REST.

That said, REST is not for everything. It's an architecture, so it's rather flexible how you can implement it. But if it doesn't make sense to access things primarily as resources, then REST may not fit, or it may only fit for parts of your application, which is fine.

like image 77
aehlke Avatar answered Sep 18 '22 23:09

aehlke