JSON endpoint support

[jbr]

What would you want from json support? Something like this sketch?

use trillium_json::JsonConnExt;
async fn handler(mut conn: Conn) -> Conn {
    let mut user: User = conn_try!(conn, conn.json_request_body().await);
    user.id = Some(10);
    dbg!(&user);//save to db or whatever

    conn.json(json!({ "status": "created", "id": user.id })
}

which would be something like this example, which should work without any extensions today:

async fn handler(mut conn: Conn) -> Conn {
    let bytes = conn_try!(conn, conn.request_body().await.read_bytes().await);
    let mut user: User = conn_try!(conn, serde_json::from_slice(&bytes));
    user.id = Some(10);
    dbg!(&user);

   let response_body = trillium::conn_try!(conn, serde_json::to_string(&json!({ "status": "created", "id": user.id }))
   conn.with_header(("content-type", "application/json")).body(body)
}

[imbolc]

Hi :) Two questions:

1. Is there a potential way for auto-generating an OpenAPI spec?
2. How would validation work? E.g. in Rocket you have #[derive(FromForm)] to validate input specific to an endpoint and request guards for something general like the current user. This gives concise and descriptive feeling to the actual endpoint code. Would you give an example of how do you (potentially) see validation in Trillium?

[jbr]

1 is easier to answer: I don't see any reason it wouldn't be possible but I also am not likely to prioritize building it soon. That would probably involve implementing a different router handler that tracks input and output types. However, since this isn't general purpose, my intent is to make it so other people can build that if they want it and have it interoperate as best as possible with the rest of the ecosystem

2: edit: I reread your question and think I understand. Handlers can be run in sequences, so an earlier handler might set the user type and a later handler retrieves it. Similarly, an early handler might halt the sequence and return an error. Hopefully this helps explain: tuple handlers. Handlers are like middleware in other frameworks. They can modify the request or the response, they can accumulate state, and they can halt the progression of the pipeline

[prabirshrestha]

Few things I can think of as part of general api support. You can take ideas from Echo golang web framework

• streaming json serializer/deserializer
• auto add etag/if none match headers
• compression
• sending prettified json
• sending json blob (send pre-encoded JSON blob directly from external source, for example, database.)
• jsonp with custom callback

(I would still prefer some sort of proper error handling first though a tough one)

[jbr]

There are a bunch of cross-cutting concerns here, and some of them are going to be done sooner than later.

errors

Error handling is probably going to be mostly about educating and documenting for a while. My intent is that until rust adds support for for<'a> Fn(&'a mut conn) -> impl Future<Output=Result<(), E>> + 'a bounds (also referred to as "AsyncFn"), error handling will look like minor improvements to trillium::conn_try! and trillium::conn_unwrap! or, even better, people matching on Result and Option and handling those as appropriate for their application. Application authors should be encouraged by the framework to remember that they're always returning a Conn and need to set appropriate http responses.

Going through the rest of that list:

unrelated to json:

• caching headers: high priority, will absolutely be done before most other "new feature" type things, unrelated to json api type stuff
• compression: high priority, unrelated to json api type stuff

json-specific stuff:

• prettifying json: sure, that makes sense
• jsonp: easy enough. not sure if that's the same crate as json output, since they're each only around a hundred lines and the actual json part is handled by serde_json.
• json streaming: i'm probably not going to implement this unless most users would see a performance benefit, which I don't think they would. serde_json is fast enough that it's likely to be a rounding error on the network transfer time for most json payloads, so the additional complexity isn't worth it for the core suite of utilities.