For an update (POST) request, a field that is omitted should not be changed. To clear a field from it's value, it should be mentioned in the request with the value null or a normal value to change the value completely.
In your example, Classroom will keep the value 1A.

For a replace document (PUT) request, all the fields will be cleared and replaced with what is inside the request. So when a field is omitted, it will be cleared.
In you example, when you send a PUT request, Classroom will be null.

When using POST as a create request, the omitted fields will not be set, so Classroom stays null.

This is at least the way that is specified in the jsonapi.org specification (a specification for JSON responses on REST services):

If a request does not include all of the attributes for a resource, the server MUST interpret the missing attributes as if they were included with their current values. The server MUST NOT interpret missing attributes as null values.

Other specifications, like OData, describe the same behaviour. But as long as you document the implemented behaviour, it is your choice.

RESTful Casuistry has a pretty good discussion of restart; if you aren't already familiar with it, you should have a look at it.

Usually for long running jobs, I would do something similar to what is described here, and return 202 accepted with the URL of the resource so you can track the operation.

Is it a good idea to do this in conjunction with partial update?

Yes.

But it feels awkward that the API will only sometimes respond like this.

Well, there's nothing necessarily wrong with always reporting that the request has been accepted.

I've come to find that the easiest way to work through this is to think about the messages first, and then worry about the meta data afterwards.

In HTTP, the response to an unsafe operation is generally a message describing the result of the action. If you imagine a website submitting a form, you might get a page back saying "the operation succeeded, follow this link to see the result", or you might get a page back saying "the operation was accepted, follow this link to get the latest status".

The same idea expressed another way: you are navigating an integration protocol; sometimes the application transitions to the finished state, other times it transitions to an intermediate pending state.

The intermediate state really isn't inherently different from a failed state, where you get a response back describing the fact that the request you submitted was rejected, and here's what you can do about it.

The HTTP status code, and the response headers, are not the response; they are meta data lifted from the response. What we're really doing there is taking semantics from the response (which targets the consumer), and lifting some of them into the metadata so that the generic components participating in the protocol have a coarse understanding of what's going on, and can act appropriately.

But it feels awkward that the API will only sometimes respond like this.

Think about the web sites we have today. Sometimes you click on link, and it takes you to the data you expect; but sometimes instead you are directed to a log in screen because your previous license has expired.

In other words, we do this sort of thing all the time; there are multiple states that the application might transition to, the server picks one, and the client has to figure out how to make progress.

The REST answer to the latter is hypermedia, which is to say the client needs to understand the semantics of the links that could be returned by the server, and the server chooses to respond with the appropriate links, including the semantic annotations that distinguish them.

In your example, most of your use cases have data ready immediately, so the "result of the operation" response will include only the link that informs the client of how to view the result

<a ref="http://example.org/viewResult" href="...">

For the restart case, which is going to take some time, the "result of the operation response will include only the link that informs the client of how to check for progress

<a rel="http://example.org/checkProgress" href="...">

Another way of thinking about this: the presence of the link tells the client that a resource is available, the link relation tells the client what the resource is, the protocol tells the client what actions they can take with that kind of resource (which http methods are supported, what media-types are available, and so on).

Atom Publishing is a really good example of a protocol defined this way.