docs: update caddy docs

Author: zcf0508

docs/caddy/docs/docs/api-tutorial.md renamed to docs/caddy/api-tutorial.md

@@ -24,20 +24,14 @@ This tutorial will show you how to use Caddy's [admin API](https://caddyserver.c
 
 To start the Caddy daemon, use the `run` subcommand:
 
-```
-caddy run
-```
-
+`caddy run`
 This blocks forever, but what is it doing? At the moment... nothing. By default, Caddy's configuration ("config") is blank. We can verify this using the [admin API](https://caddyserver.com/docs/api) in another terminal:
 
-```
-curl localhost:2019/config/
-```
-
+`curl localhost:2019/config/`
 We can make Caddy useful by giving it a config. One way to do this is by making a POST request to the [/load](https://caddyserver.com/docs/api#post-load) endpoint. Just like any HTTP request, there are many ways to do this, but in this tutorial we'll use `curl`.
 
-Your first config[🔗](https://caddyserver.com/docs/api-tutorial#your-first-config "Direct link")
-------------------------------------------------------------------------------------------------
+Your first config
+-----------------
 
 To prepare our request, we need to make a config. Caddy's configuration is simply a [JSON document](https://caddyserver.com/docs/json/) (or [anything that converts to JSON](https://caddyserver.com/docs/config-adapters)).
 
@@ -75,10 +69,7 @@ curl localhost:2019/load \
 
 We can verify that Caddy applied our new config with another GET request:
 
-```
-curl localhost:2019/config/
-```
-
+`curl localhost:2019/config/`
 Test that it works by going to [localhost:2015](http://localhost:2015/) in your browser or using `curl`:
 
 ```
@@ -107,14 +98,11 @@ curl localhost:2019/load \
 
 For good measure, verify that the config was updated:
 
-```
-curl localhost:2019/config/
-```
-
+`curl localhost:2019/config/`
 Test it by refreshing the page in your browser (or running `curl` again), and you will see an inspirational message!
 
-Config traversal[🔗](https://caddyserver.com/docs/api-tutorial#config-traversal "Direct link")
-----------------------------------------------------------------------------------------------
+Config traversal
+----------------
 
 Instead of uploading the entire config file for a small change, let's use a powerful feature of Caddy's API to make the change without ever touching our config file.
 
@@ -129,10 +117,7 @@ curl \
 
 You can verify that it worked with a similar GET request, for example:
 
-```
-curl localhost:2019/config/apps/http/servers/example/routes
-```
-
+`curl localhost:2019/config/apps/http/servers/example/routes`
 You should see:
 
 ```
@@ -145,8 +130,8 @@ You should see:
 *   Don't mix the use of config files with changes via the API; have one source of truth.
 *   [Export Caddy's new configuration](https://caddyserver.com/docs/api#get-configpath) with a subsequent GET request (less recommended than the first two options).
 
-Using `@id` in JSON[🔗](https://caddyserver.com/docs/api-tutorial#using-id-in-json "Direct link")
--------------------------------------------------------------------------------------------------
+Using `@id` in JSON
+-------------------
 
 Config traversal is certainly useful, but the paths are little long, don't you think?
 
@@ -171,10 +156,7 @@ This adds a property to our handler object: `"@id": "msg"`, so it now looks like
 
 We can then access it directly:
 
-```
-curl localhost:2019/id/msg
-```
-
+`curl localhost:2019/id/msg`
 And now we can change the message with a shorter path:
 
 ```
@@ -186,6 +168,4 @@ curl \
 
 And check it again:
 
-```
-curl localhost:2019/id/msg/body
-```
+`curl localhost:2019/id/msg/body`

docs/caddy/docs/docs/api.md renamed to docs/caddy/api.md

@@ -43,8 +43,8 @@ The core of Caddy knows how to work with some of these fields natively:
 
 But other top-level fields (like [`apps`](https://caddyserver.com/docs/json/apps/)) are opaque to the core of Caddy. In fact, all Caddy knows to do with the bytes in `apps` is deserialize them into an interface type that it can call two methods on:
 
-1.  `Start()`
-2.  `Stop()`
+1.   `Start()`
+2.   `Stop()`
 
 ... and that's it. It calls `Start()` on each app when a config is loaded, and `Stop()` on each app when a config is unloaded.
 
@@ -61,10 +61,10 @@ There are two kinds of modules: _host modules_ and _guest modules_.
 
 Modules get loaded, are provisioned and validated, get used, then are cleaned up, in this sequence:
 
-1.  Loaded
-2.  Provisioned and validated
-3.  Used
-4.  Cleaned up
+1.   Loaded
+2.   Provisioned and validated
+3.   Used
+4.   Cleaned up
 
 Caddy kicks off the module lifecycle when a config is loaded first by initializing all the configured app modules. From there, it's turtles all the way down as each app module takes it the rest of the way.