The REST API is for manipulating record data on Salesforce, as opposed to the metadata that defines what that specific instance of Salesforce looks like and how it behaves. Visualforce pages and Static Resources are examples of metadata.
Unfortunately, the models you're imagining for how you work with metadata don't really match the Salesforce development experience. If you're coming from another software stack, be aware that there are unique features and complexities to how you build software on Salesforce that almost certainly do not resemble what you're used to.
You typically will interact with metadata via an IDE or other application that connects to the Salesforce Metadata API or Tooling API. The current generation of IDE from Salesforce is Visual Studio Code with the Salesforce Extension Pack. If you choose to use that IDE, you'd be working with the Org Development Model, which requires you to create and maintain a package.xml
manifest file to define which metadata items you want to work with.
Your package.xml
would probably look something like this:
<?xml version="1.0" encoding="UTF-8"?>
<Package xmlns="http://soap.sforce.com/2006/04/metadata">
<types>
<members>*</members>
<name>ApexPage</name>
</types>
<types>
<members>*</members>
<name>StaticResource</name>
</types>
<version>45.0</version>
</Package>
You might start with the Quick Start: Visual Studio Code for Salesforce Development Trailhead project, and the Org Development Model module. Note that the Quick Start is depicting the Salesforce DX development model, which is not org-based; using persistent sandboxes is part of the org-based model.
An alternative to Visual Studio Code, albeit not a very good one, is the legacy Eclipse-based Force.com IDE.
If you want a more full-featured traditional IDE than Salesforce's current Visual Studio Code offering, you'd do best to look at one of the current commercial offerings. You may find (disclaimer: I don't use them myself) that the additional features on offer smooth out some of the rough edges of knowledge you'd otherwise need to build yourself about how the tools work.
At the other end of the spectrum, you can certainly use the sfdx
CLI, the Force.com CLI, or Workbench to perform Metadata API pulls and deploys based on a package.xml
and source directory.
There's a lot more to go into about the Salesforce development lifecycle and tool chain. I'd strongly recommend working through Trailhead modules for basic development tasks to begin getting familiarity with the environment.