Rakesh Narang
Rakesh Narang

Reputation: 79

Should an API do more than one thing?

I am Spring Boot dev. I develop RESTful web services. One of my colleagues developed an API and it does two things on the basis of operation type. If opType = Set, the api sets/unsets a flag at the backend and if opType = Get, the api gets the status of the flag. Does this not break the architecture of REST APIs? We have Post/Put to change some data at backend, either create or update. And we have Get, to get the status of some thing from backend. Now, I want to opinion of better developers! Should this be allowed, like having multiples operations with one API call, or should we create multiple apis for each of the tasks. Also, the front end devs in my team, don’t like integrating multiple apis somehow, suggesting that more the api calls, poorer user experience, customer will have. Is this the normal practice among app developers? Comments requested.

Upvotes: 1

Views: 1393

Answers (1)

Mark Bramnik
Mark Bramnik

Reputation: 42441

GET requests in REST are not supposed to change the state of the server, these are read operations, whereas PUT/POST do modifications to the state of the server in the most general sense.

So usually you should have two endpoints GET to read the state of the flag and put/post for creating and modifying the state.

Having said that there is nothing that can technically restrict you from implementing everything in one API, such an API won't adhere to REST conventions, that's true, but from the client-server communication standpoint (HTTP based usually), it's still perfectly doable.

Sure thing, the separation to two endpoints makes the API more clear, easier to debug and maintain the code. But besides being "restful" this can be treated as an opinionated claim.

I didn't really get the argument of integrating multiple APIs - in my understanding, the effort is the same, and even more clear to front-enders, but they might have their own arguments.

Upvotes: 3

Related Questions