refactor: tip -> info

src/docs/api-reference/rest/cache.md

@@ -265,7 +265,7 @@ Query the `Cache` Service for all key-value pairs, whose `key` matches the provi
 
 For example `movie-*`, `*-1984`, or `movie*1984`
 
-:::tip
+:::info
 Remember, you `Cache` Service `key`s do not need to be strictly `_id` from a hyper `Data` Service. They can be anything! You can store more information in your `key`s, such that a pattern can fetch multiple cached documents in a single request.
 :::
 

src/docs/api-reference/rest/data.md

@@ -119,11 +119,11 @@ Store a Document in the `Data` Service.
 
 A hyper `Data` Service document is a JSON document with one to many fields. An `_id` field is allowed. If an `_id` is not provided, it will be generated by the hyper `Server`. The `_id` field MUST be unique.
 
-:::tip
+:::info
 We recommend providing your own `_id`, when creating a document, that is appropriate for your use-case.
 :::
 
-:::tip
+:::info
 Because a hyper `Data` Service is schemaless, it's common practice to add a `type` field onto each document, to distinguish it from other documents in your `Data` Service. This is similar to patterns used in [Single Table Design](https://blog.hyper.io/document-database-design/)
 :::
 
@@ -252,7 +252,7 @@ curl -X DELETE https://$HOST/data/$DOMAIN/$ID
 
 Perform a bulk operation on the `Data` Service. This can be used to create, update and remove multiple documents, all within a single operation!
 
-:::tip
+:::info
 Each document must have an `_id` field
 :::
 
@@ -397,7 +397,7 @@ If no documents matched your criteria, then `docs` will be an empty array.
 
 Retrieve a list of documents from a hyper `Data` Service.
 
-:::tip
+:::info
 A `list` operation is really handy for fetching multiple documents by `_id`, but it can also be used to perform DynamoDB/Cassandra-esque `range queries` against document `_id`s. If you're clever in what sort of information you store in the document `_id`, this can give you a lot of mileage! You could even go so far as to denormalize your data into multiple documents, based on the access patterns, and then use `range queries` to fetch a hierarchy of documents without joins -- the Cassandra/DynamoDB way.
 :::
 

src/docs/api-reference/rest/index.md

@@ -16,6 +16,6 @@ This hyper `App` exposes each of the core hyper Services as a set of REST resour
 - [`Queue`](queue): hyper `Queue` Services available on the hyper `Server`
 - [`Search`](search): hyper `Search` Services available on the hyper `Server`
 
-:::tip
+:::info
 Be sure to include any appropriate authN/Z on the request. See [Securing your hyper `Server`](/docs/build/securing-hyper)
 :::

src/docs/build/custom-adapter.md

@@ -208,7 +208,7 @@ Links that do not call anything on `next` are referred to as "Terminating Links"
 
 We will dive more into what can be done with this later. For now, just understand that this composition is the reason for the interesting signature of `link`.
 
-:::tip
+:::info
 Plugin Linking is an advanced concept; you probably don't need it.
 
 As a general rule of thumb, your `Adapter` probably will not need to use `next` if it fully implements the `Port` and does not call `next`

src/docs/build/custom-middleware.md

@@ -4,7 +4,7 @@ hyper `Middleware` allows you to add additional functionality to a hyper `App`.
 
 In the [hyper Config file](/docs/host/hyper-config), you may specify an array of `middleware`. This `middleware` is then passed to the hyper `App` under `services.middleware`.
 
-:::tip
+:::info
 It is up to the hyper `App` implementation to properly apply the `Middleware` to itself.
 
 In other words, the `Middleware` is specific to an `App` implementation