0

I'm currently developing a web application with a senior developer. We've agreed to use REST API for client-server communication and he sent me the parameters and the expected responses.

But the design does not seem to be RESTful. Rather it looks like JSON-RPC over http utilizing only the POST method.

For example, to register a user you send a POST request to the server the following parameters.

{
  id: 1,
  method: "RegisterUser",
  params: {
    firstName: "John",
    lastName: 'Smith',
    country: 'USA',
    phone: "~",
    email: "~",
    password: "~"
  }
}

And the expected response is

{
  id: 1
  result: "jwt-token",
  error : null 
}

Multiple requests are sent to the same URL and the server sends back the response based on the 'method' in the parameters. For example, to get a user info, you send a { method: "GetUserInfo", params: { id: ~ }} to the same URL. All responses have the status code 200, and the errors are handled by the error in the response body. So even if the status code is 200, if error is not null it means something is wrong.

The way I'm used to doing is sending a POST request to 'users/' with a request body when registering a new user, sending a GET request to 'users/1' to retrieve a user information, etc.

When I asked why he'd decided to do it this way, he said in his previous job, trying to add more and more APIs was a pain when following RESTful API design. Also, he said he didn't understand why RESTful API uses different HTTP verbs when all of them could be done with POST.

I tried to come up with the pros of REST API over JSON-RPC over http with POST.

  1. GET requests are cached by the browser, but some browsers may not support POST request caching.

  2. If we are going to open the API to outside developers, this might cause discomfort for them since this is not a typical REST API.

In what circumstance would the JSON-RPC over http style be better the REST RESTful APIs? Or does it just not matter and just a matter of preferance?

Kevin Park
  • 318
  • 5
  • 8

3 Answers3

1

it looks like JSON-RPC over http utilizing only the POST method.

Yes, it does.

The way I'm used to doing is sending a POST request to 'users/' with a request body when registering a new user, sending a GET request to 'users/1' to retrieve a user information, etc.

That's not quite it either.

Riddle. How did you submit this question to stack overflow? Well, you probably followed a book mark you had saved, or followed a link from google. Maybe you submitted a search or two, eventually you clicked the "Ask Question", which took you to a form. After filling in the details of the form, you hit the submit button. That took you to a view of your question, that include (among other things) a link to edit the question. You weren't interested in that, so you were done -- except for refreshing the page from time to time hoping for an answer.

That's a REST api. You, the agent, follow links from one state to another, negotiating stack overflows "submit a question" protocol.

Among other things to notice: the browser didn't need to know in advance what URLs to send things to, or which http method to use, because the HTML had encoded those instructions into it. The browser just need to understand the HTML standard, so that it could understand how to find the links/forms within the representation.

Now, REST is just a set of architectural constraints, that boil down to "do it the way a web server does". You don't need to use HTML as your media type; you don't need to design for web browsers as your clients. But, to do REST, you do need hypermedia; and clients that understand that hypermedia type -- so it is going to be a lot easier for you to choose one of the standardized media types.

Are there more reasons why I should prefer RESTful API over JSON-RPC over http with POST? Or does it just not matter?

Roy Fielding, in 2008, offered this simple and correct observation

REST is intended for long-lived network-based applications that span multiple organizations. If you don’t see a need for the constraints, then don’t use them.

For instance, the folks working on GraphQL decided that the properties that the REST constraints induce weren't valuable for their use case; not nearly as valuable as being able to delivery to the client a representation tuned to a clients specific needs.

Horses for courses.

VoiceOfUnreason
  • 52,766
  • 5
  • 49
  • 91
  • Thank you for the detailed explanation. However, looking at your answer I think I should rephrase my question like this. In what circumstance would the JSON-RPC over http style be better the REST RESTful APIs? – Kevin Park Jul 16 '17 at 10:16
1

Use RESTful APIs when you are performing standard create, read, update and delete actions on resources. The CRUD actions should behave the same way for each resource, unless you have some before and after hooks. Any new developer coming to the project will easily understand your API if it follows the standards.

Use JSON-RPC when you are performing actions that don't necessarily map cleanly to any CRUD. For instance, maybe you want to retrieve counts or summary data of a specific resource collection. You could do this with REST, but it might require you to think of it as some sort of "summary" resource that you read from. It's easier to do with JSON-RPC, since you can just implement a procedure that runs the appropriate query in your database and returns an appropriate result object.

Or what if you want to make an API call that lets a user delete or update all of instances of a resource(s) that meet some condition, without knowing ahead of time what those instances are?

You can also use JSON-RPC in cases where you need to have a lot of side effects for standard CRUD actions and it's inconvenient to make hooks that run before or after each action.

You don't have to go all in with one of the other, you can use both. Have standard RESTful endpoints where appropriate and another RPC endpoint for handling JSON-RPC calls.

Eddy Borja
  • 1,638
  • 17
  • 21
0

Use REST when you write public web services. REST is standardized and predictable, it will help consumers to write client apps. Also, GET HTTP method is widely used to retrieve resources from public web services.

Use JSON RPC when you write back-end for an application (i.e. not public web services). JSON RPC style is more flexible and more suitable for register, login, and getProductsByFilters methods. There is no reason to use GET with JSON RPC, only POST should be used.

Yuriy N.
  • 4,936
  • 2
  • 38
  • 31