Geek Answers Handbook

Web Services - REST vs PHP JSON RPC

I am working on a project where I am trying to identify a software feature. Basically, I have my backend, and I was thinking of splitting the interface from the backend code using JSON-msgs. I'm a little confused as to what the difference is between a service and an API. I know that APIs can be built on top of services. But I have these two models - to access profile X using json-rpc

http://xyz.com/?request= {"jsonrpc": "2.0", "id": 1, "method": "getProfile", "params": {"id": "X"}}

or should be like this using REST -

http://api.xyz.com/X

thanks

+6
source share
2 answers

"Service" and "API" are a rather vague question. Often two terms are used interchangeably. "REST" and "RPC" are a little easier to explain.

Usually with REST, the URL is a specific resource, such as "user", "account", etc. Typically, you can create / retrieve / update / delete these resources using the HTTP methods POST / GET / PUT / DELETE. To update the profile for user 1125, you can send the following:

POST /user/1125 HTTP/1.1 Host: wherever.com Content-type: application/x-www-form-urlencoded firstName=Davey&lastName=Jones&email=dj%40thebrineydeep.com

What would you like to do with user 1125, you would send a request to the same URL. There are exceptions and variations of this idea, but that’s the point.

RPC services are more like using a feature library bound to a specific URL. You can have a bunch of related functions related to URL /services/json . Then, if you want to change the profile for the old Davey Jones, you would:

 POST /services/json HTTP/1.1 Host: wherever.com Content-type: application/json { "jsonrpc": "2.0", "id": 1, "method": "setProfile", "params": [ 1125, { "firstName": "Davey", "lastName": "Jones", "email": " dj@thebrineydeep.com " } ] }

I personally like JSON-RPC better because:

  • I don’t need to try to embed all my function calls in some resource mapping for the URL, which may not make sense
  • We are not trying to overload HTTP response codes to indicate API errors. Each request returns a 200 response (if there is no server error), and you know from the response body whether you have an error or not. JSON-RPC is particularly well-versed in error conditions.

Sometimes REST is better because:

  • Assigning resources to URLs sometimes works very well
  • Understanding by third parties is understanding
  • It offers a simpler model for easily finding easily identifiable information.

I don't think any of them are easier to code.

Change I modified the REST example to use more common form-encoded data instead of JSON. But, of course, you can specify any data format that you like using REST. It is not carved in stone.

+20
source

The REST URL does not match your JSON-RPC request.

At least it should be http://api.example.org/getProfile?id=X

There really isn’t much difference between the two. And your "REST" is not a real REST unless you return a data format that can reliably express links to different URLs, for example. XML or (X) HTML. Until this requirement is met, you should call it "RESTful" because you really only use HTTP methods to start the data and move the data back and forth.

It doesn’t matter what you use - if you do not know or do not have experience with software that helps you build one or the other solution faster than the other.

0
source

More articles:


All Articles