I have an API that return list of Employee. This API will have an offset and limit for pagination purpose.

On the frontend, I use Single-Page Framework (Vue/Angular/React..). This SPA have a Employee List Page that can create new Employee using AJAX.

And now the question, :

  1. Should I return only OK message when server successfully created Employee object and then GET the updated list from server?
  2. Or should I return OK message and the new updated List so I didn't have to make a GET request to the server?

Which one (from the 2 options) commonly used when designing API?

  • Not sure why this is being down voted and why every answer is being down voted. Seems like it has attracted hit and run down voting. If you are down voting please leave a comment to explain why. To me it seems like a reasonable question to ask. Oct 24 '19 at 16:38

Should I return only OK message when server successfully created Employee object and then GET the updated list from server?


When you create the new Employee you should return 201 CREATED and possibly a representation of that newly created user in JSON or XML or what ever.

This creation request is completely independent to viewing the list of Employees.

Just because you do it from a page with a list of Employees doesn't mean that action is connected. You could just as easily create a new Employee from a completely different page that has nothing to do with listing Employees.

Imagine if you did this creation request from some other page where you aren't viewing the Employees and suddenly you get back a long list of Employees. That would make no sense.

The request and response should concern themselves just with the action being performed, and not worry about where in the app they are being called from.

Whether you need to now GET the list of employees again depends on how your framework does pagination. If pagination is server side the easiest thing is to simply GET the list of employees again and let the server figure out where in the list of employees the new employee should be found.

If you really want to avoid a second GET you could use the representation of the newly created Employee (returned in the body of the 201 CREATED) to try and figure out, on the client, if this Employee should be inserted into the current list of Employees or if this Employee even occurs on this page (if it doesn't then you don't need to reload the list)

But this means implementing pagination logic on both the server and the client. That is going to more complicated and error prone. So I would just do a second GET request and let the server worry about it.

  • 1
    Accepted this answer because of its detailed explanation. For someone reading this threads and need a TLDR answer, read the one written by Hans-Martin Mosner
    – flemadap
    Oct 25 '19 at 7:47

Go for the first option.

GET and POST are independent operations. In particular, whatever filtering and pagination parameters were given to the GET request for the list are not available in the POST request, so combining them does not make sense.

What makes sense, though, is returning the created object in the POST response as it might contain server-initialized fields such as an ID or default values that were not given in the POST request.


The answer is a bit more complicated.

The problem isnt so much updating the clients list with the new Employee. Afterall the client knows about this employee and can add it themselves.

The problem is keeoing your server side pagination in sync with previously sent data when new items are added.

So for example I get the first 10 employees by last name, but them another client adds "Mr A Anderson" to the server.

now when I request the next ten, I dont want to recieve a duplicate employee #9 because Mr Anderson has taken up an early slot and pushed the rest down.

For this reason, most pagination systems pass an id if some kind, so that the server knows what list you requested and not to rearrange it.

Mr anderson, would appear at the end of the list or not at all.

Your Answer

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

Not the answer you're looking for? Browse other questions tagged or ask your own question.