What is a good design for making multiple POST requests for the same URL?

I have a page that serves as a file explorer, in this page there are many actions, to name a few:
copy, paste, delete, open folder, etc…

I was wondering what is my best option to communicate with the server?
Use json? use urlQuerys?

My bet is to go for json, my idea is to handle requests with this format:

	"action": "getListOfFiles",
	"targetFile": "",
	"destinationFile": "",
	"destinationFolder": "",
	[...and more...]

Other options for action:
"getListOfFiles", "getSpaceDisk", "delFile", "moveFile", "copyFile".

On the server I would make a switch action case and call the appropriate function.

All functions would use the same struct for the json and depending on which action the user performs there are fields that can be filled or empty.

Is this a good approach? or can you give me some other advice?, should I create a router for each action?

It would be most typical (and RESTful) to implement an endpoint for each of your actions:
GET /files
GET /diskspace
DELETE /file/:filename
moveFile see suggested options at How to move a REST resource? - Stack Overflow
copyFile see suggested options at rest - What is the restful way to represent a resource clone operation in the URL? - Stack Overflow

For MOVE and COPY you could use either:

  • explicit URLs
  • a generic URL with the “action” in the body
  • pure RESTFUL


POST /file/<id>/move → params are in the request body
POST /file/<id>/copy → params are in the request body

POST /file/<id>/action → params are in the request body (with action field mandatory)

PATCH /file/<id> → only updates values in the body
PUT /file/<id> → all values values in the body

honestly I’d prefer the first solution to make explicit in the URL which operation you’re performing, but this depends also on your setup

1 Like

mje Massimo.Costa

I like your proposals, but can you please tell me what are the disadvantages of using json versus REST?

With json I would only create 1 endpoint, with REST there would be several.

What I want to know is what problems I will face in the future if I use json.

1 Like

There are no real disadvantages that I know of other than: it’s a non-standard way to build a RESTful API. But for an internal project you would be fine going with a single endpoint (and you don’t have to worry about routing which makes your project even more simple).

1 Like

I think I will go more for the REST option because then each endpoint is independent and the maintenance is simpler for each action, in my method if I get the json fields mixed up wrong I might require more maintenance for each function that is affected.

From my perspective my method requires little work at the beginning but later in production it can complicate the maintenance, on the other hand with REST the development will be a little harder but the maintenance will be simpler.

I mean - you could build it in a way where maintenance was nearly identical. By having the “action” in your json object all you’re doing is kind of rolling your own router. Something like this:

type FileRequest struct {
   Action string

func HandleRequests(w http.ResponseWriter, r *http.Request) {
   var params FileRequest 
   // Ignoring errors for brevity. Don't actually ignore errors.
   switch (params.Action) {
      case "list":
         List(w, params)
      case "read":
         Read(w, params)
         // Bad request probably

func List(w http.ResponseWriter, req FileRequest) {
   // Do something and write to w

func Read(w http.ResponseWriter, req FileRequest) {
   // Do something and write to w

Anyway, I’m not trying to encourage you to ignore RESTful API conventions. Just noting that you could still build it in a pretty maintainable way if you wanted to.


@Willy, one bonus point of using different URLs is that there’re many tools that can help to automate tests starting from a clean URL design (maybe starting from OpenAPI file)

1 Like

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.