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).
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.
json.NewDecoder(r.Body).Decode(params)
switch (params.Action) {
case "list":
List(w, params)
case "read":
Read(w, params)
default:
// 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)