REST-API design: different granularity for receiving and updating resources

I'm in the process of creating a REST-API. Among others, there is a resource-type called company which has quite a lot of attributes/fields.

The two common use cases when dealing with company resources are:

• Load a whole company and all its attributes with one single request
• Update a (relatively small) set of attributes of a company, but never all attributes at the same time

I came up with two different approaches regarding the design of the API and need to pick one of them (maybe there are even better approaches, so feel free to comment):

---

1. Using subresources for fine-grained updates

Since the attributes of a company can be grouped into categories (e.g. street, city and state represent an address... phone, mail and fax represent contact information and so on...), one approach could be to use the following routes:

/company/id: can be used to fetch a whole company using GET

/company/id/address: can be used to update address information (street, city...) using PUT

/company/id/contact: can be used to update contact information (phone, mail...) using PUT

And so on.

But: Using GET on subresources like /company/id/address would never happen. Likewise, updating /company/id itself would also never happen (see use cases above). I'm not sure if this approach follows the idea of REST since I'm loading and manipulating the same data using different URLs.

2. Using HTTP PATCH for fine-grained updates

In this approach, there are no extra routes for partial updates. Instead, there is only one endpoint:

/company/id: can be used to fetch a whole company using GET and, at the same time, to update a subset of the resource (address, contact info etc.) using PATCH.

---

From a technical point of view, I'm quite sure that both approaches would work fine. However, I don't want to use REST in a way that it isn't supposed to be used. Which approach do you prefer?