What's the standard for validating json bodies for an api?

Phoenix Forum Questions / Help
,
1

I’m still new to phoenix, prolly somewhere around 2 weeks old. I’m trying to build a json api and I’m having difficulty finding the best practice for validation. For example if my json api expects a body like

{ 
  name: "hello",
  email: "test@gmail.com"
}

And my client only sends

{
  name: "test"
}

My appliation immediately throws a 500. What’s the current best practice for resolving this?

2 Likes
2

Can you please provide an example action where this happens?

I assume, you are haveing a line like {:ok, data} = JSON.decode(body_data) where it isn’t able to match due to the incomplete data. Thats where you need to use a case expression where you branch depending on the result of the call to JSON.decode/1 (which in reality can have any other name and arity, depends on the tools you use, which you didn’t even told us which that were).

1 Like
3

Ecto changesets are pretty much the standard. If you’re not saving the JSON to a DB, you can use “schemaless” changesets:

https://hexdocs.pm/ecto/Ecto.Changeset.html#module-schemaless-changesets

Your example for instance would work with validate_required.

1 Like
4

You can try a Elixir JSON Schema validator. I used such in Ruby, Go and Java, but not in Elixir so far and I cannot guarantee its quality.

Or, if you only need to guarantee a top-level set of keys, you can just get Map.keys from the info that is sent to your API and compare it to your pre-determined set of mandatory map keys.

1 Like
5

I’ve actually been able to resolve my issues. It was an error on my end. But thanks for the insights!

6

can you explain how we can use changeset to validate a payload conditionally?

like in Node, with JOI you can do something like

const schema = {
    a: Joi.any()
        .valid('x')
        .when('b', { is: Joi.exist(), then: Joi.valid('y'), otherwise: Joi.valid('z') })
        .when('c', { is: Joi.number().min(10), then: Joi.forbidden() }),
    b: Joi.any(),
    c: Joi.number()
};

Also I’m concerned of validating nested JSONs. And sometimes values in Payloads arent directly used by DB layer

{
   "password": "ABC",
   "passwordConfirmation": "123"
}

In node, I had this layer that validates the payload before reaching to the controller.
In elixir I’m kinda lost as it seems everything is now messed up

7

As above, you can use Ecto + schemaless changesets to validate anything, so I would reach for that.

There are a few ways, you can pipe and pattern match or whatever. Just pass the changeset around to whatever function.

  # warning: written in brief, may not compile but should give 
  # idea of method.
  def my_changeset(attrs) do
    changeset =
      echo_schemaless_stuff()
      |> base_changeset(attrs)
      # inspect the changeset in the function
      |> maybe_validate_price()
      # or send the value as param
      |> maybe_validate_color(Map.get(attrs, :color, :maybe_some_default))
    #or you can just if attrs.value do ... etc
  end

  def maybe_validate_price(changeset) do
    case Ecto.Changeset.get_field(changeset, :price) do
      # dont validate
      nil ->
        changeset

      value when is_integer(value) ->
        changeset
        |> validate_number(value, greater_than: 0)
        # ...

      value when is_binary(value) ->
        changeset
        |> validate_format(...)
    end
  end

  def maybe_validate_color(changeset, :maybe_some_default) do
    # no validation
    changeset
  end

  def maybe_validate_color(changeset, color) when color in ~w(red green blue) do
   # correct colors
    changeset
  end

  def maybe_validate_color(changeset, color) do
    #  fail
    changeset
    |> add_error(:color, :some_error)
  end

Its also common(?) (maybe becoming common?) to have schemaless models backing your forms/api vs your actual CRUD operations (which also still have their own changesets).

This can give you some separation between “API validation” and “Data validation” if that makes sense. You then don’t need your form to match your schema exactly. You could, as a very trite example, accept “length” + “unit” in your form, validate that as you like, then always convert it to “length in mm” before sending to your actual db schema type which can just validate that the number between 0 and 100000 or whatever. This becomes more applicable as your model complexity increases, for basic stuff you can often stick with 1:1 or a simple “pass through”.

E: in terms of nested JSON, you can make schemaless types for each “nested section” to validate independently too. I do this for a pretty complex migration aide where you can have many different types of data cross associated and it works well and is pretty “brainable”.

2 Likes