I'm new to API design. I've been reading numerous threads RESTful vs RPC patterns for API design, but I feel like none directly addressed my exact use case, so I just wanted to get a second opinion.

Let's say I want to build a web app which recommends neighbourhoods to live based on two criteria:

  • Your income (i.e. what you can afford in terms of rent)
  • Where your office is (i.e. commuting times)

I can think of three possible ways of doing this:

  1. RPC: probably the most straightforward of the three. I define a method on the server called "getNeighbourhoods" which takes the user's income / office location as input, finds the neighbourhoods within the price range (by querying the database) and within commuting distance (by calling an external API, for example, to get the drive time between two locations), and returns a list of eligible neighbourhoods with their details. All logic is on the server side. My client just sends the criteria by POST and receives a list of recommended neighbourhoods or a single best neighbourhood.
    POST /getNeighbourhoods { office_location: foo, income: bar }
    One issue with this is that it's tightly coupled to the client, and I'd need to take precaution in sending sensitive information to the server.
  2. RESTful: I define a "neighbourhoods" resource and make a GET request.
    a) GET /neighbourhoods/ would return all neighbourhoods from the database.
    b) GET /neighbourhoods/?office_location=foo&max_cost=bar would filter for the recommended neighbourhoods. I would basically apply a similar server-side logic as in the RPC example based on the query string params I get.
    One big problem with this system is that I would be pretty apprehensive about sending this data in the query string, even if obfuscated to something like "max_cost=". What if I need to use more sensitive information in the future?
  3. Client: the other solution that I can think of is that I implement two RESTful resources, one which returns all neighbourhoods from the database, and the other which makes API calls and returns commute times. For example:
    a) GET /neighbourhoods/ returns neighbourhoods from the database.
    b) GET /directions/<origin>/<destination> calls the external API to get commute times
    Then, I apply the complex logic on the client side, checking which neighbourhoods returned from the API are within budget and, of those, which are within a 30-minute commute.

The final method seems to be best since it's the most decoupled, I'm not making any direct third-party API calls from the client (so I don't expose my API key, for example), and I'm not sending any sensitive user information over the network. However, a lot of the logic is on the client side. Do you see any other downsides to this method?

Thank you!

  • 1
    It is unclear to me why you think option 1 tightly couples the client to the server, or why option three is the most decoupled of the three. – Robert Harvey May 3 '20 at 16:19
  • 2
    With respect to sensitive data, wouldn't TLS take care of that? You specifically state that you must be cautious about using POST, but POST would be the most secure of the three if the communication is encrypted. – Robert Harvey May 3 '20 at 16:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.