Edgar.A
Edgar.A

Reputation: 1383

Simple CRUD endpoints Vs. more complex endpoints

Had a discussion with a co-worker (frontend) about whose responsibility should it be to handle complexity and we didn't really come up to a conclusion.

Main idea: whose responsibility should it be to handle complexity - should backend have additional more complex endpoints that combine multiple simple existing endpoints, or should client (frontend) make multiple calls to simple endpoints?

Couple examples:

API keys regeneration

From my perspective - it's very simple - there's an endpoint to delete a key and to create a key and client should just call these 2, especially since there's an idea to expand to support multiple keys per end-user.

From colleague's perspective - there should be an endpoint that combines these 2 actions into one, because it'd easier to revert changes is second action (Add a key) fails.

Other example - when users register, we create some nested objects for him, something like

Parent ⮑Child ⮑GrandChild

My idea is once again - simple endpoints for CRUD operations and chain them (3 calls) and my colleague has same point about handling failure if one of them fails.

Upvotes: 1

Views: 743

Answers (2)

Deva Gerald
Deva Gerald

Reputation: 334

Handling complexity in client or server depends upon the actual use cases which you are trying to develop.

Answering to the KEY regeneration from the sample which you have stated, Regeneration implies that the older key should be deleted and a new valid key should be returned. Incase of failure of 2nd one, the first modification should be reverted in your backend. i.e. Both the steps should be treated as a single transaction. If this is not the case, having separate APIs is good enough.

Another sample is if there are 'n' number of resources to be deleted, Client might call the /resources/$resource_id - HTTP DELETE in a loop, which in-turn might hit your DB 'n' times. So considering the backend resource optimisation, the best way is to support delete multiple resources in a single API. Ex : /resources?ids=1,2,3,4 - HTTP DELETE

Upvotes: 1

VoiceOfUnreason
VoiceOfUnreason

Reputation: 57279

whose responsibility should it be to handle complexity - should backend have additional more complex endpoints that combine multiple simple existing endpoints, or should client (frontend) make multiple calls to simple endpoints?

When in doubt - look to the web. Do you think that Google search is simple? how about Amazon one click ordering?

REST, in the large, is about disguising your implementation details behind the facade of a web site/document store. It's pretty much agnostic on whether you make that disguise simple or complicated.

Take a look at Jim Webber's talk on REST with domain models.

Upvotes: 1

Related Questions