HttpUtilities deprecation but Command methods not public?

Development & Design
1

Looking at Command.java , why do we have only respondJSON() available?
For extension authors, (and migration of extensions) how best to migrate away from HttpUtilities where something like this in the database extension, for example:

        if (databaseQueryInfo == null) {
            Command.respondStatus(response, "error", "Invalid or missing Query Info");
           // HttpUtilities.respond(response, "error", "Invalid or missing Query Info");
        }

It seems that respondStatus should be public? Or should extensions migrate to only using respondJSON and status codes SC_* ?

The previous HttpUtilities had public methods and now Command only has 1 visible method respondJSON(), so I'm curious what's the end goal eventually look like?

2

The move to expose only respondJSON() seems to align with a design philosophy aimed at maintaining consistency by standardizing all responses to use JSON as the format and also to ensure simplification by avoiding duplication of functionality like status and message handling. I think, by promoting respondJSON(), the intention is likely to ensure that responses are both predictable and extensible.

The concern of respondStatus() to be made public? depends on the long-term goals. If the intent is to strictly enforce JSON responses, then exposing respondStatus() might conflict with the above design philosophy. However, making it public could ease the migration process for extensions that rely on legacy HttpUtilities methods.

As a middle ground, it might be helpful to temporarily introduce respondStatus() as a wrapper around respondJSON() to assist in migration, for example:

public static void respondStatus(HttpServletResponse response, String status, String message) {
    response.setStatus(HttpServletResponse.SC_BAD_REQUEST); // Example status
    respondJSON(response, Map.of("status", status, "message", message));
}

To migrate away from HttpUtilities, adapting code to use respondJSON() in combination with appropriate HTTP status codes (SC_*) might be useful. For example:

if (databaseQueryInfo == null) {
    response.setStatus(HttpServletResponse.SC_BAD_REQUEST); // appropriate status
    Command.respondJSON(response, Map.of("status", "error", "message", "Invalid or missing Query Info"));
}

Also, we can use the approach of Custom Wrapper Utility . Instead of calling setStatus() and respondJSON() separately, we can encapsulate both into a single reusable method:

public static void respondError(HttpServletResponse response, int statusCode, String errorMessage) {
    response.setStatus(statusCode);
    Command.respondJSON(response, Map.of("status", "error", "message", errorMessage));
}

Usage:

if (databaseQueryInfo == null) {
    respondError(response, HttpServletResponse.SC_BAD_REQUEST, "Invalid or missing Query Info");
}

Thanks!
-Jay