Magento 2 REST API : دليل أفضل الممارسات (2026)
تعتبر REST API لماجنتو 2 العمود الفقري للتكاملات الخارجية — مزامنة ERP، اتصالات CRM، تطبيقات الهاتف المحمول، وواجهات المتاجر headless. تواصل Adobe الاستثمار في REST إلى جانب GraphQL، ولا يزال البروتوكول الموصى به للتكاملات على مستوى الإدارة والعمليات المجمعة. يغطي دليل أفضل الممارسات هذا تصميم نقاط النهاية، المصادقة، معالجة الأخطاء، التخزين المؤقت، وأنماط الإنتاج لبناء REST API ماجنتو 2 موثوقة في 2026.
باختصار: تعرض REST API الموارد تحت
/rest/V1/باستخدام أفعال CRUD القياسية. استخدم المصادقة المستندة إلى token للتكاملات، و OAuth 1.0 للتطبيقات الخارجية، وقم دائمًا بتضمين استجابات الأخطاء المناسبة، والترقيم، ورؤوس التخزين المؤقت. للتفاعلات المتعلقة بواجهة المتجر، راجع دليل GraphQL المخصص .
جدول المحتويات
- REST مقابل GraphQL: أيهما تستخدم
- طرق المصادقة
- هيكل نقاط النهاية واصطلاحات التسمية
- تنسيقات الطلب والاستجابة
- معالجة الأخطاء ورموز الاستجابة
- الترقيم والتصفية
- العمليات المجمعة وواجهات API غير المتزامنة
- التخزين المؤقت ورؤوس ETag
- إنشاء نقاط نهاية REST مخصصة
- أنماط التكامل لـ ERP/CRM
- الاختبار والتوثيق
- الأسئلة الشائعة
REST مقابل GraphQL: أيهما تستخدم
يدعم ماجنتو 2 كلاً من REST و GraphQL APIs. لكل منهما نقاط قوة مختلفة:
| السيناريو | التوصية |
|---|---|
| تكاملات الإدارة (ERP, CRM, OMS) | REST — تغطية أوسع لعمليات الإدارة |
| واجهة المتجر/تطبيق الهاتف المحمول | GraphQL — عدد أقل من الطلبات، مخطط typed |
| مزامنة البيانات المجمعة | REST — نقاط نهاية مجمعة وغير متزامنة |
| الدفع في الوقت الفعلي | GraphQL — طفرة واحدة لإكمال عملية الدفع |
| الوصول من تطبيقات خارجية | REST — دعم OAuth 1.0 |
لتغطية مفصلة لـ GraphQL، راجع توثيق GraphQL . يركز هذا الدليل على تطوير REST والتكامل.
طرق المصادقة
Tokens التكامل (موصى به للاتصالات بين الخوادم)
أنشئ تكاملاً في Stores → Configuration → Integrations في لوحة الإدارة. يُنشئ ذلك token وصول مع صلاحيات محددة للموارد:
# طلب token
curl -X POST https://store.com/rest/V1/integration/admin/token \
-H "Content-Type: application/json" \
-d '{"username": "integration_name", "password": "integration_password"}'
# الاستجابة: "q7x3p2m9..."
# استخدام token في الطلبات اللاحقة
curl https://store.com/rest/V1/products/24-MB01 \
-H "Authorization: Bearer q7x3p2m9..."
Tokens التكامل طويلة الأمد ومقتصرة على موارد API الخاصة بالتكامل. قم بتدويرها دوريًا عبر لوحة الإدارة.
Token المسؤول (استخدم بحذر)
curl -X POST https://store.com/rest/V1/integration/admin/token \
-H "Content-Type: application/json" \
-d '{"username": "admin_user", "password": "admin_password"}'
Tokens المسؤول مرتبطة بحساب مستخدم المسؤول. عندما يغير المسؤول كلمة المرور الخاصة به، يتم إبطال جميع tokens الموجودة. فضّل tokens التكامل للتكاملات الآلية.
Tokens العميل
curl -X POST https://store.com/rest/V1/integration/customer/token \
-H "Content-Type: application/json" \
-d '{"username": "[email protected]", "password": "customer_password"}'
Tokens العميل تُستخدم للتكاملات الموجهة لواجهة المتجر (تطبيقات الهاتف المحمول، الواجهات الأمامية المخصصة). لديها صلاحيات على مستوى العميل فقط.
OAuth 1.0
للتطبيقات الخارجية التي تحتاج وصولاً مفوضًا، يدعم ماجنتو OAuth 1.0 مع oauth_token و oauth_token_secret. هذا أكثر تعقيدًا ولكنه يسمح بتحديد نطاق الصلاحيات بدقة دون مشاركة بيانات اعتماد المسؤول.
هيكل نقاط النهاية واصطلاحات التسمية
تتبع REST API لماجنتو 2 نمط URL ثابت:
/rest/V1/{resource}/[id]/[subresource]/[subresource_id]
الموارد المضمنة
| نقطة النهاية | الغرض |
|---|---|
GET /rest/V1/products/:sku | الحصول على منتج بواسطة SKU |
POST /rest/V1/products | إنشاء منتج |
PUT /rest/V1/products/:sku | تحديث منتج |
DELETE /rest/V1/products/:sku | حذف منتج |
GET /rest/V1/customers/:id | الحصول على عميل |
GET /rest/V1/orders/:id | الحصول على طلب |
POST /rest/V1/cart/mine/order | تقديم طلب (سلة العميل) |
GET /rest/V1/categories/:id | الحصول على فئة |
نقاط نهاية البحث
معظم الموارد تدعم البحث عبر GET /rest/V1/{resource}/search:
GET /rest/V1/products/search?
searchCriteria[filterGroups][0][filters][0][field]=sku&
searchCriteria[filterGroups][0][filters][0][value]=24-MB&
searchCriteria[filterGroups][0][filters][0][conditionType]=like&
searchCriteria[pageSize]=20&
searchCriteria[currentPage]=1
يتضمن الرد العدد الإجمالي والعناصر. قم دائمًا بتطبيق الترقيم — لا تطلب أبدًا جميع السجلات مرة واحدة.
تنسيقات الطلب والاستجابة
جميع الطلبات والاستجابات تستخدم application/json. اتبع الهياكل القياسية لماجنتو:
الطلب:
{
"product": {
"sku": "CUSTOM-SKU-001",
"name": "Custom Product",
"price": 29.99,
"status": 1,
"visibility": 4,
"type_id": "simple",
"attribute_set_id": 4,
"extension_attributes": {
"stock_item": {
"qty": 100,
"is_in_stock": true
}
},
"custom_attributes": [
{
"attribute_code": "description",
"value": "Product description here"
}
]
}
}
الاستجابة الناجحة (200/201):
{
"id": 42,
"sku": "CUSTOM-SKU-001",
"name": "Custom Product",
...
}
معالجة الأخطاء ورموز الاستجابة
API جيدة التصميم تُرجع رموز حالة HTTP مناسبة وأجسام خطأ منظمة.
رموز حالة HTTP القياسية
| الرمز | المعنى | متى تستخدم |
|---|---|---|
200 | OK | GET, PUT, DELETE ناجحة |
201 | Created | POST ناجح (تم إنشاء المورد) |
400 | Bad Request | JSON غير صحيح أو أخطاء تحقق |
401 | Unauthorized | مصادقة مفقودة أو غير صالحة |
403 | Forbidden | تمت المصادقة ولكن غير مصرح |
404 | Not Found | المورد غير موجود |
422 | Unprocessable Entity | فشل تحقق منطق الأعمال |
429 | Too Many Requests | تحديد المعدل |
500 | Internal Server Error | خطأ خادم غير متوقع |
هيكل استجابة الخطأ
تنسيق الخطأ القياسي لماجنتو:
{
"message": "Product with SKU \"CUSTOM-SKU-001\" already exists.",
"trace": "...",
"parameters": {
"sku": "CUSTOM-SKU-001"
}
}
لنقاط النهاية المخصصة، أعد أخطاء منظمة بشكل ثابت:
use Magento\Framework\Exception\LocalizedException;
use Magento\Framework\Webapi\Exception as WebapiException;
// خطأ تحقق
throw new WebapiException(
__('Product SKU is required'),
0,
WebapiException::HTTP_BAD_REQUEST
);
// المورد غير موجود
throw new LocalizedException(
__('Product with SKU "%1" not found.', $sku)
);
الترقيم والتصفية
قم دائمًا بترقيم نقاط نهاية المجموعات. استخدم أنماط searchCriteria الخاصة بماجنتو بشكل ثابت:
GET /rest/V1/products/search?
searchCriteria[filterGroups][0][filters][0][field]=price&
searchCriteria[filterGroups][0][filters][0][value]=50&
searchCriteria[filterGroups][0][filters][0][conditionType]=gteq&
searchCriteria[sortOrders][0][field]=created_at&
searchCriteria[sortOrders][0][direction]=DESC&
searchCriteria[pageSize]=50&
searchCriteria[currentPage]=2
يتضمن الرد العدد الإجمالي لواجهة الترقيم من جانب العميل:
{
"total_count": 342,
"items": [ ... ]
}
العمليات المجمعة وواجهات API غير المتزامنة
لمزامنات البيانات الكبيرة، استخدم نقاط نهاية API المجمعة لماجنتو:
# إنشاء منتجات مجمعة غير متزامن
POST /rest/V1/async/bulk/V1/products
Content-Type: application/json
Authorization: Bearer {token}
[
{ "product": { "sku": "BULK-001", "name": "Bulk 1", "price": 10 } },
{ "product": { "sku": "BULK-002", "name": "Bulk 2", "price": 20 } },
...
]
تُرجع نقطة النهاية غير المتزامنة UUID مجمعًا فورًا وتعالج العمليات في الخلفية عبر قوائم انتظار الرسائل. استعلم عن الحالة عبر:
GET /rest/V1/bulk/{bulkUuid}/status
العمليات المجمعة ضرورية لتكاملات ERP/CRM التي تزامن آلاف المنتجات أو العملاء أو الطلبات. تمنع انتهاء مهلة API وتقلل حمل الخادم.
التخزين المؤقت ورؤوس ETag
تحترم REST API التخزين المؤقت HTTP القياسي. لنقاط نهاية القراءة التي تُرجع بيانات نادرًا ما تتغير (الفئات، كتل CMS، إعدادات المتجر)، قم بتضمين رؤوس التخزين المؤقت:
// في نقطة النهاية المخصصة الخاصة بك
$this->resultFactory->create(ResultFactory::TYPE_JSON)
->setData($data)
->setHeader('Cache-Control', 'public, max-age=3600')
->setHeader('ETag', md5(serialize($data)));
يمكن للعملاء بعد ذلك إرسال رؤوس If-None-Match لتلقي استجابات 304 Not Modified عندما لا تتغير البيانات — مما يوفر عرض النطاق الترددي ووقت المعالجة.
إنشاء نقاط نهاية REST مخصصة
1. تعريف المسارات في webapi.xml
<!-- app/code/Vendor/Module/etc/webapi.xml -->
<routes xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="urn:magento:module:Magento_Webapi:etc/webapi.xsd">
<route url="/V1/vendor/price-check/:sku" method="GET">
<service class="Vendor\Module\Api\PriceManagementInterface" method="getPrice"/>
<resources>
<resource ref="anonymous"/>
</resources>
</route>
</routes>
يحدد قسم resources الصلاحيات. استخدم anonymous لنقاط النهاية العامة، أو راجع موارد ACL محددة لنقاط النهاية الخاصة بالإدارة فقط.
2. إنشاء واجهة الخدمة
<?php
declare(strict_types=1);
namespace Vendor\Module\Api;
interface PriceManagementInterface
{
/**
* Get current price and special price for a product
*
* @param string $sku
* @return \Vendor\Module\Api\Data\PriceDataInterface
* @throws \Magento\Framework\Exception\NoSuchEntityException
*/
public function getPrice(string $sku): \Vendor\Module\Api\Data\PriceDataInterface;
}
3. إنشاء واجهة البيانات
<?php
declare(strict_types=1);
namespace Vendor\Module\Api\Data;
interface PriceDataInterface
{
/**
* @return float
*/
public function getPrice(): float;
/**
* @param float $price
* @return $this
*/
public function setPrice(float $price): self;
/**
* @return float|null
*/
public function getSpecialPrice(): ?float;
/**
* @param float|null $specialPrice
* @return $this
*/
public function setSpecialPrice(?float $specialPrice): self;
}
4. تنفيذ الخدمة
<?php
declare(strict_types=1);
namespace Vendor\Module\Model;
use Vendor\Module\Api\PriceManagementInterface;
use Vendor\Module\Api\Data\PriceDataInterfaceFactory;
use Magento\Catalog\Api\ProductRepositoryInterface;
class PriceManagement implements PriceManagementInterface
{
public function __construct(
private readonly ProductRepositoryInterface $productRepository,
private readonly PriceDataInterfaceFactory $priceDataFactory
) {}
public function getPrice(string $sku): PriceDataInterface
{
$product = $this->productRepository->get($sku);
$priceData = $this->priceDataFactory->create();
$priceData->setPrice((float)$product->getPrice());
$priceData->setSpecialPrice($product->getSpecialPrice() !== null
? (float)$product->getSpecialPrice()
: null);
return $priceData;
}
}
5. إضافة extension_attributes لقابلية التوسع
<!-- app/code/Vendor/Module/etc/extension_attributes.xml -->
<config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="urn:magento:framework:Api/etc/extension_attributes.xsd">
<extension_attributes for="Magento\Catalog\Api\Data\ProductInterface">
<attribute code="custom_badge" type="string"/>
</extension_attributes>
</config>
أنماط التكامل لـ ERP/CRM
مزامنة الطلبات (Magento → ERP)
استخدم observer
sales_order_save_after لماجنتو لوضع بيانات الطلب في قائمة انتظار للتصدير. قم بالمعالجة عبر cron job أو قائمة انتظار الرسائل:
تقديم الطلب → تفعيل Observer → وضع بيانات الطلب في قائمة الانتظار
↓
cron job يلتقط قائمة الانتظار
↓
POST إلى نقطة نهاية ERP
↓
وضع علامة على الطلب كمصدر
مزامنة المخزون (ERP → Magento)
استخدم REST API المجمعة لتحديثات المخزون:
POST /rest/V1/async/bulk/V1/products/bySkus/stockItems
[
{ "sku": "PROD-001", "qty": 50, "is_in_stock": true },
{ "sku": "PROD-002", "qty": 0, "is_in_stock": false }
]
قم بتشغيل هذا كمهمة مجدولة من جانب ERP كل 5–15 دقيقة حسب تقلب المخزون.
دفع العملاء (CRM → Magento)
POST /rest/V1/async/bulk/V1/customers
[
{
"customer": {
"email": "[email protected]",
"firstname": "John",
"lastname": "Doe",
"website_id": 1,
"store_id": 1,
"group_id": 1
},
"password": "temporary_password"
}
]
أرسل رسائل الترحيب من Magento (وليس من النظام الخارجي) للحفاظ على اتساق العلامة التجارية وإمكانية التسليم.
الاختبار والتوثيق
الاختبار باستخدام Postman Collection
صدّر نقاط نهاية API ماجنتو 2 الخاصة بك كمجموعة Postman. قم بتضمين:
- متغيرات البيئة لعنوان URL الأساسي، token
- نصوص ما قبل الطلب لتوليد token
- أمثلة على الأجسام لكل نقطة نهاية
- نصوص اختبار للتحقق من هيكل الاستجابة
اختبارات API الآلية
# استخدم إطار اختبار التكامل لماجنتو
vendor/bin/phpunit -c dev/tests/integration/phpunit.xml \
--filter testPriceEndpoint
توثيق OpenAPI/Swagger
يُولد ماجنتو 2 توثيق Swagger على /rest/V1/swagger في وضع المطور. لنقاط النهاية المخصصة، قم بتعليق الواجهات بعلامات OpenAPI:
/**
* Get product price
*
* @api
* @param string $sku
* @return PriceDataInterface
* @throws NoSuchEntityException
*/
public function getPrice(string $sku): PriceDataInterface;
الأسئلة الشائعة
س: ما الفرق بين REST و GraphQL في ماجنتو 2؟
REST تتبع أنماط URL القائمة على الموارد وهي أفضل للتكاملات الإدارية. GraphQL قائم على الاستعلامات وأفضل لواجهات المتاجر/تطبيقات الهاتف المحمول. راجع دليل مقارنة GraphQL
للتفاصيل.
س: كيف أتعامل مع تحديد المعدل لـ REST API؟
لا يحتوي ماجنتو 2 على تحديد معدل مدمج. قم بتطبيقه على مستوى خادم الويب (Nginx limit_req_zone) أو استخدم CDN يدعم تحديد المعدل.
س: هل يمكنني استخدام REST API لعملية الدفع؟
نعم، لكن GraphQL مفضل لعملية الدفع في واجهة المتجر لأنه يقلل عدد الطلبات. يتطلب الدفع عبر REST استدعاءات متعددة (إضافة إلى السلة، تعيين الشحن، تعيين الدفع، تقديم الطلب).
س: كيف أؤمن نقاط نهاية API للوصول العام؟
استخدم resource ref="anonymous" في webapi.xml لنقاط النهاية العامة. لنقاط النهاية التي تحتاج بعض التحقق دون مصادقة كاملة، قم بتطبيق فحص HMAC مخصص أو تحقق من رأس مفتاح API في plugin.
س: ما هو الحد الأقصى لحجم الحمولة لطلبات API المجمعة؟
يعتمد هذا على تكوين PHP الخاص بك (upload_max_filesize، post_max_size) وحدود خادم الويب. للحمولات الكبيرة جدًا (10,000+ عنصر)، قسّمها إلى دفعات من 100–500 واستخدم API المجمعة غير المتزامنة.
س: كيف أختبر نقاط النهاية المخصصة محليًا؟
استخدم CURL أو Postman أو Insomnia. عيّن app/etc/env.php MAGE_MODE إلى developer لرؤية رسائل الخطأ التفصيلية. يوفر ماجنتو أيضًا مجموعات اختبار التكامل لاختبار API.
هل تحتاج إلى تكامل API مخصص لمتجر ماجنتو 2 الخاص بك؟ تحقق من خدمة API والتكاملات و خدمة الوحدات المخصصة الخاصة بي. راجع أيضًا دليل GraphQL للواجهة لأنماط API لواجهة المتجر.