Incorrect format of error response from rest apis

[saurabh-git-dev]

I believe the rest api should return an error as JSON by default instead of a string when we pass an invalid parameter in the request.
See the attached image.

I am also looking solution for customizing the errors.. like validating the body. and returning with specific error messages, and missing fields errors.

[kaplanelad]

Check request validation here: https://loco.rs/docs/the-app/controller/

[saurabh-git-dev]

Thank you for your time. Returning validation errors looks simple.. and working, but still one piece is missing, I think.. I can not get the missing field error. it's because it's handled by a JSON parser. so I can not get a detailed error message.

for the path parameter, I am not sure how to handle it as well.

pub async fn update(
    Path(id): Path<i32>,
    State(ctx): State<AppContext>,
    Json(params): Json<Params>,
) -> Result<Response> {
    let item = load_item(&ctx, id).await?;
    let mut item = item.into_active_model();
    params.update(&mut item);
    let item = item.update(&ctx.db).await?;
    format::json(item)
}

Is there any solution currently to deal with path params? I think the same will happen with query params.(I have not tested yet)

[kaplanelad]

Hey @saurabh-git-dev,

Regarding the missing field validation, you can handle it by using the #[validate(required)] attribute on your struct fields. Here's an example:

#[derive(Debug, Deserialize, Validate)]
pub struct DataParams {
    #[validate(length(min = 5, message = "custom message"))]
    pub first_name: String,
    #[validate(required)]
    pub last_name: Option<String>,
    #[validate(email)]
    pub email: String,
}

#[debug_handler]
pub async fn index(
    State(_ctx): State<AppContext>,
    JsonValidateWithMessage(params): JsonValidateWithMessage<DataParams>,
) -> Result<Response> {
    format::text("ok")
}

CURL request:

❯ curl -X POST http://localhost:5150/api/tests \
        -H "Content-Type: application/json" \
        -d '{"first_name": "test", "email": "john@example.com"}' | jq .

Response:

{
  "errors": {
    "first_name": [
      {
        "code": "length",
        "message": "custom message",
        "params": {
          "min": 5,
          "value": "test"
        }
      }
    ],
    "last_name": [
      {
        "code": "required",
        "message": null,
        "params": {
          "value": null
        }
      }
    ]
  }
}

Note: #[validate(required)] variable must be used on an Option field. See the validator crate documentation for details.

As for query param validation, we added support for that in version 0.16.2 (thanks to @Davidzhu001!). You can now use QueryValidateWithMessage to validate query parameters. See the implementation here.

[saurabh-git-dev]

Thanks for sharing detailed information. The QueryValidateWithMessage is exactly what I was looking for, really helpful.
I saw that this feature was merged recently. @Davidzhu001! had also implemented the PathValidateWithMessage. However, he removed the path validation in the next commit. Not sure why?
Related PR:
https://github.com/loco-rs/loco/pull/1521/commits

Commit: https://github.com/Davidzhu001/loco/blob/792efde7b5ed4b45dfbb700320367a9ae73dae41/src/controller/extractor/validate.rs#L221

Is there any issue with path params validation?

[kaplanelad]

not sure what you mean but #1521 merge into master and released in 0.16.2 version

Why should there be an issue with the path params validation?

[saurabh-git-dev]

QueryValidateWithMessage validates only Query Parameters, not Path Parameters.

@Davidzhu001! had implemented PathValidateWithMessage while working on QueryValidation, but he removed it later.. So in that PR, only the QueryValidateWithMessage exists and can validate query params only.

[kaplanelad]

I can't control the commits. Eventually, this feature exists in 0.16.2

[saurabh-git-dev]

You mean the PathValidateWithMessage exists in 0.16.2?

[kaplanelad]

no. only query parameters.
don't see a reason to validate the path. path is part of the controller URL

[Davidzhu001]

In my project nested routes requires both:

/records/{id}/comements?page=1&size=100

[Davidzhu001]

I conducted a test and discovered some cases where this validator is not particularly useful. For example:

1. When validating parameters, you must explicitly include the key for each parameter. For instance:

#[derive(Debug, Validate, Deserialize)]
pub struct TestPathParams {
    #[validate(range(min = 1, max = 10))]
    id: i32,
}

#[derive(Debug, Validate, Deserialize)]
pub struct TestQueryParams {
    #[validate(range(min = 1, max = 10))]
    page: i32,
    #[validate(range(min = 1, max = 100))]
    size: i32,
}

pub async fn path_validate(
    PathValidateWithMessage(params): PathValidateWithMessage<TestPathParams>,
    QueryValidateWithMessage(payload): QueryValidateWithMessage<TestQueryParams>,
) -> Result<Response> {
    println!("Path ID: {}", params.id);
    println!("Query Data: {:?}", payload);
    format::json(params.id.to_string())
}

/// routes
.add("/records/{id}", get(path_validate))

You are required to make requests like /records/12?page=1&size=100. There is no straightforward way to set default values, and my solution is to catch them in a Result, such as:

payload: Result<QueryValidate<PagyParams>>,

to handle defaults. I found that there are numerous configurations required for this use case.

I then tested other errors and discovered that you can still add them back to use the validator.

Currently, I am investigating ways to implement a better request validator, so I have not addressed this issue extensively.

[Davidzhu001]

I am lazy developer, I believe that if there is no elegant way to accomplish a task, a better approach is necessary. Therefore, I am planning to develop an improved request validator.

[saurabh-git-dev]

@Davidzhu001
Thanks. I can understand that. I am doing path params validation in another framework just to return a proper error message to clients. I have 2 path params. So I was looking for a similar option here. Your implementation is quite similar to what I have used in other languages.
I will follow your approach; it looks sufficient for my current use case.