POST and required fields

1

Hi,
Would love to hear thoughts or clarification on something possibly quite simple.

For creating a resource (POST) the spec (9.1) says:

The request MUST include a single resource object as primary data. The resource object MUST contain at least a type member.

Then in 7.2:

In addition, a resource object MAY contain any of these top-level members:

So my question is quite simply should we handle scenarios where a POST request does not include attributes (or meta) in the resource object? Essentially this would be a POST to create a resource where no resource attribute fields was given (only ‘type’) and the created resources would use whatever defaults are defined. This might not make sense for specific resources.

Or, can we interpret the MAY statement to be that we may require attributes to be provided?

2

The server can enforce additional constraints on the resources typically discussed as validation. E.g. it can enforce some attributes to exist in requests to create a resource.

3

Thanks jelhan,
I’m actually looking at the whole ‘attributes’ member in the ‘data’ object.
I realise that fields inside the ‘attributes’ object are up to us to define but the specification says that a resource object MAY contain an attributes member.

This seems to imply that one should support the creation of resources (via a POST) where the ‘attributes’ member is not supplied at all, like:

...
data: {
  type: 'mytype'
  # no attributes: {...}
}

I was wondering about the definition of “MAY” in this case, meaning can we actually require the attributes member to be present?

4

Yes. You can enforce the attributes member to be present implicitly by requiring a specific attribute to be present. I think in practice that’s the most common use case by far. Allowing a resource to be created without enforcing any attribute to be set is an edge case.

Having the attributes member as optional allows clients and servers to avoid unnecessary characters. Instead of having an empty object as value of the attributes member, they can skip the attributes member entirely.

5

Thanks, that’s how I saw things. It was just the use of the word “MAY” in that context seemed to imply that we should support a POST request without “content”.
Makes sense, of course, that this is an implementation specific requirement.