How to create a good PATCH endpoint when some properties can change and some can't based on the status of the resource?

Consider I have the following Resource:

public class Foo
{
    public string Text {get; set;}

    public int ReminderInDays {get; set;}

    // Determined by resource itself
    public FooStatus Status {get;set;}
}

Now, let's say we want to be able to update these. Normally, you could create a PATCH endpoint:

PATCH api/foos/1 with a body that contains both Text and ReminderInDays. (I do not use stuff like Jsonpatch where you can submit only the changed properties).

This would work fine. But how about the following scenario:

• Text can change when Status is New and Submitted
• ReminderInDays can change when Status is New

If I were to use my PATCH example, I could use a body like the following when status is New, and everything would be OK:

{
  "Text": "Hello World!",
  "ReminderInDays": 3
}

But if I were to use this when the status of the resource is Submitted and I would change ReminderInDays to 5, the Resource would throw an error because I am not allowed to change that property anymore. Based on this information, the only way I can think of having 1 endpoint to change both, is to ignore the ReminderInDays property when the Resource tells me the property can't be changed.

This seems like an ugly solution to me. You need to submit useless data to the API which is a waste.

Another solution is to have 2 endpoints:

• PATCH api/foos/1/text
• PATCH api/foos/1/reminderInDays

This isn't really RESTFUL, but would solve my issues.

Does anyone have any other ideas? What is the right thing to do :)?