Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow reply with JsonDocument or JsonObject or JsonArray? #171

Open
hitecSmartHome opened this issue Aug 17, 2024 · 5 comments
Open

Allow reply with JsonDocument or JsonObject or JsonArray? #171

hitecSmartHome opened this issue Aug 17, 2024 · 5 comments

Comments

@hitecSmartHome
Copy link

I wonder if it would be doable to reply directly with a JsonDocument in a cb.
Here is one of my endpoint controller method.

esp_err_t DBController::getDirTree(PsychicRequest *req){
    if( !req->hasParam("path") ){
        return req->reply(400, "text/html", "Missing path");
    }

    JsonDocument tree;
    std::string jsonString;

    String path = req->getParam("path")->value();
    bool result = db.getDirTree(path.c_str(), tree);
    size_t serializedSize = serializeJson(tree, jsonString);

    if( !result || serializedSize <= 0 ){
        return req->reply(404, "text/html", "Failed to get directory tree");
    }

    return req->reply(200, "application/json", jsonString.c_str());
}

Would be good to do it like this

esp_err_t DBController::getDirTree(PsychicRequest *req){
    if( !req->hasParam("path") ){
        return req->reply(400, "text/html", "Missing path");
    }
    JsonDocument tree;
    String path = req->getParam("path")->value();
    if( !db.getDirTree(path.c_str(), tree) ){
        return req->reply(404, "text/html", "Failed to get directory tree");
    }

    return req->reply(200, "application/json", tree); // reply with JsonDocument directly
}
@mathieucarbou
Copy link
Collaborator

mathieucarbou commented Aug 17, 2024

That is definitely doable. was think about the same. With the new refactoring in V2, it would help avoid dealing with a decorator class. The content type could be made optional, and if provided, could help switch between message pack and normal json.

this approach could be the same also for several other types, Stream included.

@hitecSmartHome
Copy link
Author

I'm thinking about something like this

esp_err_t PsychicRequest::reply(int code, JsonDocument &doc)
{
  PsychicResponse response(this);

  response.setCode(code);
  response.setContentType("application/json");
  response.setContent(doc);

  return response.send();
}
void PsychicResponse::setContent(JsonDocument &doc)
{
  serializeJson(doc, _body);
  setContentLength(strlen(_body));
}

@hitecSmartHome
Copy link
Author

We need to call only this return req->reply(200, tree);. Since it's a JsonDocument the content type is self-explanatory

@mathieucarbou
Copy link
Collaborator

We need to call only this return req->reply(200, tree);. Since it's a JsonDocument the content type is self-explanatory

Ct has to be optional since the same JsonVariant object can be serialised as message pack also ;-)

@hitecSmartHome
Copy link
Author

Yeah, I see

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants