docs: update endpoints to use file-routing approach (#5397)
- Move the original guides for creating endpoints and middlewares to sub-sections in the Endpoints category. - Replace existing guides for endpoints and middlewares with the new approach. - Update all endpoints-related snippets across docs to use this new approach.
This commit is contained in:
Shahed Nasser authored and 
GitHub committed
1 parent
b38f73726d
commit
c28935b4e8
170 files changed
+3658
-3344
No files matched your search
@@ -10,7 +10,7 @@ In this document, you’ll learn how to install the Discount Generator plugin on
|
||||
|
||||
In Medusa, merchants can create dynamic discounts that act as a template for other discounts. With dynamic discounts, merchants don't have to repeat certain conditions every time they want to create a new discount.
|
||||
|
||||
The discount generator plugin allows merchants and developers to generate new discounts from a dynamic discount. This can be done either by envoking the `/discount-code` endpoint or using the `DiscountGeneratorService`.
|
||||
The discount generator plugin allows merchants and developers to generate new discounts from a dynamic discount. This can be done either by envoking the `/discount-code` API Route or using the `DiscountGeneratorService`.
|
||||
|
||||
---
|
||||
|
||||
@@ -43,11 +43,11 @@ const plugins = [
|
||||
|
||||
## Test the Plugin
|
||||
|
||||
### Using the Endpoint
|
||||
### Using the API Route
|
||||
|
||||
The plugin registers a `POST` endpoint `/discount-code`. The endpoint accepts in the request body the parameter `discount_code` which is a string indicating the code of the dynamic discount to generate a new discount from. The endpoint then creates the new discount from the dynamic discount and returns it in the response.
|
||||
The plugin registers a `POST` API Route `/discount-code`. The API Route accepts in the request body the parameter `discount_code` which is a string indicating the code of the dynamic discount to generate a new discount from. The API Route then creates the new discount from the dynamic discount and returns it in the response.
|
||||
|
||||
So, to test out the endpoint, run the following command in the root of your project to start the Medusa backend:
|
||||
So, to test out the API Route, run the following command in the root of your project to start the Medusa backend:
|
||||
|
||||
```bash
|
||||
npx medusa develop
|
||||
@@ -55,41 +55,37 @@ npx medusa develop
|
||||
|
||||
Then, create a dynamic discount. You can do that either using the [Medusa admin](../../user-guide/discounts/create.mdx) which is available (if installed) at `http://localhost:7001` after starting the backend, or using the [Admin REST APIs](../../modules/discounts/admin/manage-discounts.mdx).
|
||||
|
||||
After that, send a `POST` request to the `/discount-code` endpoint, passing the `discount_code` parameter in the request body with the value being the code of the dynamic discount you just created. A new discount will be created with the same attributes as the dynamic discount code and returned in the response.
|
||||
After that, send a `POST` request to the `/discount-code` API Route, passing the `discount_code` parameter in the request body with the value being the code of the dynamic discount you just created. A new discount will be created with the same attributes as the dynamic discount code and returned in the response.
|
||||
|
||||
### Using the DiscountGeneratorService
|
||||
|
||||
After installing the plugin, the `DiscountGeneratorService` is registered in the [dependency container](../../development/fundamentals/dependency-injection.md). So, you can resolve and use it in custom services, endpoints, or other resources.
|
||||
After installing the plugin, the `DiscountGeneratorService` is registered in the [dependency container](../../development/fundamentals/dependency-injection.md). So, you can resolve and use it in custom services, API Routes, or other resources.
|
||||
|
||||
The `DiscountGeneratorService` has one method `generateDiscount`. This method requires passing the code of a dynamic discount as a parameter. It then creates a new discount having the same attributes as the dynamic discount, but with a different, random code.
|
||||
|
||||
Here's an example of using the service in an endpoint:
|
||||
Here's an example of using the service in an API Route:
|
||||
|
||||
```ts title=src/api/index.ts
|
||||
import { Request, Response, Router } from "express"
|
||||
import bodyParser from "body-parser"
|
||||
```ts title=src/api/store/generate-discount-code/route.ts
|
||||
import type {
|
||||
MedusaRequest,
|
||||
MedusaResponse,
|
||||
} from "@medusajs/medusa"
|
||||
|
||||
export default (rootDirectory: string): Router | Router[] => {
|
||||
const router = Router()
|
||||
export const POST = async (
|
||||
req: MedusaRequest,
|
||||
res: MedusaResponse
|
||||
) => {
|
||||
// skipping validation for simplicity
|
||||
const { dynamicCode } = req.body
|
||||
const discountGenerator = req.scope.resolve(
|
||||
"discountGeneratorService"
|
||||
)
|
||||
const code = await discountGenerator.generateDiscount(
|
||||
dynamicCode
|
||||
)
|
||||
|
||||
router.use(
|
||||
"/generate-discount-code",
|
||||
bodyParser.json(),
|
||||
async (req: Request, res: Response) => {
|
||||
// skipping validation for simplicity
|
||||
const { dynamicCode } = req.body
|
||||
const discountGenerator = req.scope.resolve(
|
||||
"discountGeneratorService"
|
||||
)
|
||||
const code = await discountGenerator.generateDiscount(
|
||||
dynamicCode
|
||||
)
|
||||
|
||||
res.json({
|
||||
code,
|
||||
})
|
||||
res.json({
|
||||
code,
|
||||
})
|
||||
|
||||
return router
|
||||
}
|
||||
```
|
||||
```
|
||||
@@ -70,74 +70,72 @@ Due to how Express resolves the current IP when accessing your website from `loc
|
||||
|
||||
### IpLookupService
|
||||
|
||||
The `IpLookupService` can be used in other services, endpoints, or resources to get the user’s location by their IP address. It has only one method `lookupIp` that accepts the IP address as a parameter, sends a request to ipstack’s API, and returns the retrieved result.
|
||||
The `IpLookupService` can be used in other services, API Routes, or resources to get the user’s location by their IP address. It has only one method `lookupIp` that accepts the IP address as a parameter, sends a request to ipstack’s API, and returns the retrieved result.
|
||||
|
||||
For example, you can use the `IpLookupService` in a custom endpoint and return the user’s region:
|
||||
For example, you can use the `IpLookupService` in a custom API Route and return the user’s region:
|
||||
|
||||
:::tip
|
||||
|
||||
You can learn more about creating an endpoint [here](../../development/endpoints/create.mdx).
|
||||
You can learn more about creating an API Route [here](../../development/api-routes/create.mdx).
|
||||
|
||||
:::
|
||||
|
||||
```ts title=src/api/index.ts
|
||||
import { Request, Response, Router } from "express"
|
||||
```ts title=src/api/store/customer-region/route.ts
|
||||
import type {
|
||||
MedusaRequest,
|
||||
MedusaResponse,
|
||||
RegionService,
|
||||
} from "@medusajs/medusa"
|
||||
|
||||
export default (rootDirectory: string): Router | Router[] => {
|
||||
const router = Router()
|
||||
// ...
|
||||
router.get(
|
||||
"/store/customer-region",
|
||||
async (req: Request, res: Response) => {
|
||||
const ipLookupService = req.scope.resolve(
|
||||
"ipLookupService"
|
||||
)
|
||||
const regionService = req.scope.resolve<RegionService>(
|
||||
"regionService"
|
||||
)
|
||||
|
||||
const ip = req.headers["x-forwarded-for"] ||
|
||||
req.socket.remoteAddress
|
||||
|
||||
const { data } = await ipLookupService.lookupIp(ip)
|
||||
|
||||
if (!data.country_code) {
|
||||
throw new Error ("Couldn't detect country code.")
|
||||
}
|
||||
|
||||
const region = await regionService
|
||||
.retrieveByCountryCode(data.country_code)
|
||||
|
||||
res.json({
|
||||
region,
|
||||
})
|
||||
}
|
||||
export const GET = async (
|
||||
req: MedusaRequest,
|
||||
res: MedusaResponse
|
||||
) => {
|
||||
const ipLookupService = req.scope.resolve(
|
||||
"ipLookupService"
|
||||
)
|
||||
const regionService = req.scope.resolve<RegionService>(
|
||||
"regionService"
|
||||
)
|
||||
|
||||
const ip = req.headers["x-forwarded-for"] ||
|
||||
req.socket.remoteAddress
|
||||
|
||||
const { data } = await ipLookupService.lookupIp(ip)
|
||||
|
||||
if (!data.country_code) {
|
||||
throw new Error ("Couldn't detect country code.")
|
||||
}
|
||||
|
||||
const region = await regionService
|
||||
.retrieveByCountryCode(data.country_code)
|
||||
|
||||
res.json({
|
||||
region,
|
||||
})
|
||||
}
|
||||
```
|
||||
|
||||
### preCartCreation
|
||||
|
||||
The `preCartCreation` middleware can be added as a middleware to any route to attach the region ID to that route based on the user’s location. For example, you can use it on the Create Cart endpoint to ensure that the user’s correct region is attached to the cart.
|
||||
The `preCartCreation` middleware can be added as a middleware to any route to attach the region ID to that route based on the user’s location. For example, you can use it on the Create Cart API Route to ensure that the user’s correct region is attached to the cart.
|
||||
|
||||
For example, you can attach it to all `/store` routes to ensure the customer’s region is always detected:
|
||||
|
||||
<!-- eslint-disable @typescript-eslint/no-var-requires -->
|
||||
|
||||
```ts title=src/api/index.ts
|
||||
import { Router } from "express"
|
||||
|
||||
```ts title=src/api/middlewares.ts
|
||||
import type { MiddlewaresConfig } from "@medusajs/medusa"
|
||||
const { preCartCreation } = require(
|
||||
"medusa-plugin-ip-lookup/api/medusa-middleware"
|
||||
).default
|
||||
|
||||
export default (
|
||||
rootDirectory: string
|
||||
): Router | Router[] => {
|
||||
const router = Router()
|
||||
// ...
|
||||
router.use("/store", preCartCreation)
|
||||
|
||||
return router
|
||||
export const config: MiddlewaresConfig = {
|
||||
routes: [
|
||||
{
|
||||
matcher: "/store/*",
|
||||
middlewares: [preCartCreation],
|
||||
},
|
||||
],
|
||||
}
|
||||
```
|
||||
@@ -16,7 +16,7 @@ This plugin doesn't actually implement the sending of the notification, only the
|
||||
|
||||
Customers browsing your products may find something that they need, but it's unfortunately out of stock. In this scenario, you can keep them interested in your product and, subsequently, in your store by notifying them when the product is back in stock.
|
||||
|
||||
The Restock Notifications plugin provides new endpoints that allow the customer to subscribe to restock notifications of a specific product variant. It also triggers the `restock-notification.restocked` event whenever a product variant's stock quantity is above a specified threshold. The event's payload includes the ID of the product variant and the customer emails subscribed to it. You can pair this with a subscriber that listens to that event and sends a notification to the customer using a [Notification plugin](../notifications/).
|
||||
The Restock Notifications plugin provides new API Routes that allow the customer to subscribe to restock notifications of a specific product variant. It also triggers the `restock-notification.restocked` event whenever a product variant's stock quantity is above a specified threshold. The event's payload includes the ID of the product variant and the customer emails subscribed to it. You can pair this with a subscriber that listens to that event and sends a notification to the customer using a [Notification plugin](../notifications/).
|
||||
|
||||
---
|
||||
|
||||
@@ -83,7 +83,7 @@ npm run start
|
||||
|
||||
### 2. Subscribe to Variant Restock Notifications
|
||||
|
||||
Then, send a `POST` request to the endpoint `<BACKEND_URL>/restock-notifications/variants/<VARIANT_ID>` to subscribe to restock notifications of a product variant ID. Note that `<BACKEND_URL>` refers to the URL fo your Medusa backend, which is `http://localhost:9000` during development, and `<VARIANT_ID>` refers to the ID of the product variant you're subscribing to.
|
||||
Then, send a `POST` request to the API Route `<BACKEND_URL>/restock-notifications/variants/<VARIANT_ID>` to subscribe to restock notifications of a product variant ID. Note that `<BACKEND_URL>` refers to the URL fo your Medusa backend, which is `http://localhost:9000` during development, and `<VARIANT_ID>` refers to the ID of the product variant you're subscribing to.
|
||||
|
||||
:::note
|
||||
|
||||
@@ -91,7 +91,7 @@ You can only subscribe to product variants that are out-of-stock. Otherwise, you
|
||||
|
||||
:::
|
||||
|
||||
The endpoint accepts the following request body parameters:
|
||||
The API Route accepts the following request body parameters:
|
||||
|
||||
1. `email`: a string indicating the email that is subscribing to the product variant's restock notification.
|
||||
2. `sales_channel_id`: an optional string indicating the ID of the sales channel to check the stock quantity in when subscribing. This is useful if you're using multi-warehouse modules, as the product variant's quantity is checked correctly when checking if it's out of stock. Alternatively, you can pass the [publishable API key in the header of the request](../../development/publishable-api-keys/storefront/use-in-requests.md) and the sales channel will be derived from it.
|
||||
@@ -100,7 +100,7 @@ The endpoint accepts the following request body parameters:
|
||||
|
||||
After subscribing to the out-of-stock variant, change its stock quantity to the minimum inventory required to test out the event trigger. The new stock quantity should be any value above `0` if you didn't set the `inventory_required` option.
|
||||
|
||||
You can use the [Medusa admin](../../user-guide/products/manage.mdx#manage-product-variants) or the [Admin REST API endpoints](https://docs.medusajs.com/api/admin#products_postproductsproductvariantsvariant) to update the quantity.
|
||||
You can use the [Medusa admin](../../user-guide/products/manage.mdx#manage-product-variants) or the [Admin REST API Routes](https://docs.medusajs.com/api/admin#products_postproductsproductvariantsvariant) to update the quantity.
|
||||
|
||||
After you update the quantity, you can see the `restock-notification.restocked` triggered and logged in the Medusa backend logs. If you've implemented the notification sending, this is where it'll be triggered and a notification will be sent.
|
||||
|
||||
|
||||
@@ -56,11 +56,11 @@ Before testing the plugin, run the following command in the directory of the Med
|
||||
npx medusa develop
|
||||
```
|
||||
|
||||
The plugin exposes four endpoints.
|
||||
The plugin exposes four API Routes.
|
||||
|
||||
### Add Item to Wishlist Endpoint
|
||||
### Add Item to Wishlist API Route
|
||||
|
||||
The `POST` endpoint at `/store/customer/<CUSTOMER_ID>/wishlist` allows customers to add items to their existing or new wishlist, where `<CUSTOMER_ID>` is the ID of the customer. It accepts the following body parameters:
|
||||
The `POST` API Route at `/store/customer/<CUSTOMER_ID>/wishlist` allows customers to add items to their existing or new wishlist, where `<CUSTOMER_ID>` is the ID of the customer. It accepts the following body parameters:
|
||||
|
||||
- `variant_id`: a string indicating the ID of the product variant to add to the wishlist.
|
||||
- `quantity`: (optional) a number indicating the quantity of the product variant.
|
||||
@@ -68,27 +68,27 @@ The `POST` endpoint at `/store/customer/<CUSTOMER_ID>/wishlist` allows customers
|
||||
|
||||
The request returns the full customer object. The wishlist is available at `customer.metadata.wishlist`, where its value is an array of items.
|
||||
|
||||
### Delete Item from Wishlist Endpoint
|
||||
### Delete Item from Wishlist API Route
|
||||
|
||||
The `DELETE` endpoint at `/store/customer/<CUSTOMER_ID>/wishlist` allows customers to delete items from their wishlist, where `<CUSTOMER_ID>` is the ID of the customer.
|
||||
The `DELETE` API Route at `/store/customer/<CUSTOMER_ID>/wishlist` allows customers to delete items from their wishlist, where `<CUSTOMER_ID>` is the ID of the customer.
|
||||
|
||||
The endpoint accepts one request body parameter `index`, which indicates the index of the item in the `customer.metadata.wishlist` array.
|
||||
The API Route accepts one request body parameter `index`, which indicates the index of the item in the `customer.metadata.wishlist` array.
|
||||
|
||||
The request returns the full customer object. The wishlist is available at `customer.metadata.wishlist`, where its value is an array of items.
|
||||
|
||||
#### Generate Share Token Endpoint
|
||||
#### Generate Share Token API Route
|
||||
|
||||
The `POST` endpoint at `/store/customer/<CUSTOMER_ID>/wishlist/share-token` allows customers to retrieve a token that can be used to access the wishlist, where `<CUSTOMER_ID>` is the ID of the customer.
|
||||
The `POST` API Route at `/store/customer/<CUSTOMER_ID>/wishlist/share-token` allows customers to retrieve a token that can be used to access the wishlist, where `<CUSTOMER_ID>` is the ID of the customer.
|
||||
|
||||
The endpoint doesn't accept any request body parameters.
|
||||
The API Route doesn't accept any request body parameters.
|
||||
|
||||
The request returns an object in the response having the property `share_token`, being the token that can be used to access the wishlist.
|
||||
|
||||
#### Access Wishlist with Token Endpoint
|
||||
#### Access Wishlist with Token API Route
|
||||
|
||||
The `GET` endpoint at `/wishlists/<TOKEN>` allows anyone to access the wishlist using its token, where `<TOKEN>` is the token retrieved from the [Generate Share Token Endpoint](#generate-share-token-endpoint).
|
||||
The `GET` API Route at `/wishlists/<TOKEN>` allows anyone to access the wishlist using its token, where `<TOKEN>` is the token retrieved from the [Generate Share Token API Route](#generate-share-token-api-token).
|
||||
|
||||
The endpoint doesn't accept any request body parameters.
|
||||
The API Route doesn't accept any request body parameters.
|
||||
|
||||
The request returns an object in the response having the following properties:
|
||||
|
||||
|
||||
Reference in new issue
Block a user