मैं @ryanF के शानदार उत्तर के अलावा थोड़ा और विस्तार देना चाहूंगा।
मैं कस्टम संस्थाओं के लिए एक रिपॉजिटरी जोड़ने के कारणों को जोड़ना चाहता हूं, उदाहरण दें कि ऐसा कैसे करें, और यह भी बताएं कि वेब एपीआई के हिस्से के रूप में उन रिपॉजिटरी विधियों को कैसे उजागर किया जाए।
अस्वीकरण: मैं केवल एक व्यावहारिक दृष्टिकोण का वर्णन कर रहा हूं कि यह तीसरे पक्ष के मॉड्यूल के लिए कैसे किया जाए - कोर टीमों के अपने मानक हैं जो वे अनुसरण करते हैं (या नहीं)।
सामान्य तौर पर, भंडार से संबंधित उद्देश्य भंडारण से संबंधित तर्क को छिपाना है।
एक रिपॉजिटरी के एक ग्राहक को यह ध्यान नहीं रखना चाहिए कि किसी सरणी में मेमोरी में रिटर्न की गई इकाई को किसी MySQL डेटाबेस से प्राप्त किया गया है, जिसे दूरस्थ एपीआई या फ़ाइल से लिया गया है।
मुझे लगता है कि मैगेंटो कोर टीम ने ऐसा किया ताकि वे भविष्य में ओआरएम को बदल सकें या बदल सकें। Magento में ORM में वर्तमान में मॉडल, संसाधन मॉडल और संग्रह शामिल हैं।
यदि कोई तृतीय पक्ष मॉड्यूल केवल रिपॉजिटरी का उपयोग करता है, तो Magento डेटा को कैसे और कहाँ संग्रहीत किया जाता है, और इन गहरे परिवर्तनों के बावजूद मॉड्यूल काम करना जारी रखेगा।
डेटा संग्रह स्थान आम तौर पर की तरह तरीकों findById(), findByName(), put()या remove()।
मैगनेटो में आमतौर पर इन्हें बुलाया जाता है getbyId(), save()और delete()यह दिखावा भी नहीं किया जाता है कि वे कुछ और कर रहे हैं बल्कि CRUD DB ऑपरेशन भी कर रहे हैं।
Magento 2 रिपॉजिटरी विधियों को आसानी से एपीआई संसाधनों के रूप में उजागर किया जा सकता है, जिससे उन्हें थर्ड पार्टी सिस्टम या हेडलेस Magento उदाहरणों के साथ एकीकरण के लिए मूल्यवान बनाया जा सकता है।
"क्या मुझे अपनी कस्टम इकाई के लिए एक भंडार जोड़ना चाहिए?"।
हमेशा की तरह, जवाब है
"निर्भर करता है"।
एक लंबी कहानी को छोटा करने के लिए, यदि आपकी संस्थाओं का उपयोग अन्य मॉड्यूल द्वारा किया जाएगा, तो हां, आप शायद एक भंडार जोड़ना चाहते हैं।
एक और कारक है जो यहां गिनती में आता है: मैगेंटो 2 में, रिपॉजिटरी को आसानी से वेब एपीआई के रूप में उजागर किया जा सकता है - यह रीस्ट और सोप - संसाधन है।
यदि थर्ड पार्टी सिस्टम इंटीग्रेशन या हेडलेस मैगनेटो सेटअप के कारण यह आपके लिए दिलचस्प है, तो फिर, हाँ, आप शायद अपनी इकाई के लिए एक रिपॉजिटरी जोड़ना चाहते हैं।
मैं अपनी कस्टम इकाई के लिए एक भंडार कैसे जोड़ूँ?
यह मान लें कि आप अपनी संस्था को REST API के भाग के रूप में उजागर करना चाहते हैं। यदि यह सच नहीं है, तो आप इंटरफेस बनाने पर आगामी भाग को छोड़ सकते हैं और सीधे "रिपॉजिटरी और डेटा मॉडल कार्यान्वयन" को नीचे जा सकते हैं।
रिपॉजिटरी और डेटा मॉडल इंटरफेस बनाएँ
Api/Data/अपने मॉड्यूल में फ़ोल्डर्स बनाएं । यह केवल कन्वेंशन है, आप एक अलग स्थान का उपयोग कर सकते हैं, लेकिन आपको नहीं करना चाहिए।
रिपॉजिटरी Api/फ़ोल्डर में चला जाता है । Data/उपनिर्देशिका बाद के लिए है।
में Api/, उन तरीकों से एक PHP इंटरफ़ेस बनाएं, जिसे आप उजागर करना चाहते हैं। Magento 2 सम्मेलनों के अनुसार सभी इंटरफ़ेस नाम प्रत्यय में समाप्त होते हैं Interface।
उदाहरण के लिए, एक Hamburgerइकाई के लिए, मैं इंटरफ़ेस बनाऊंगा Api/HamburgerRepositoryInterface।
रिपॉजिटरी इंटरफ़ेस बनाएँ
Magento 2 रिपॉजिटरी एक मॉड्यूल के डोमेन लॉजिक का हिस्सा हैं। इसका मतलब यह है कि, रिपॉजिटरी को लागू करने के तरीकों का कोई निश्चित सेट नहीं है।
यह पूरी तरह से मॉड्यूल के उद्देश्य पर निर्भर करता है।
हालांकि, व्यवहार में सभी रिपॉजिटरी काफी समान हैं। वे CRUD कार्यक्षमता के लिए रैपर हैं।
अधिकांश तरीकों getById, save, deleteऔर getList।
उदाहरण के लिए, CustomerRepositoryएक विधि हो सकती है get, जो एक ग्राहक को ईमेल द्वारा लाती है, जिसके getByIdद्वारा इकाई आईडी द्वारा एक ग्राहक को पुनः प्राप्त करने के लिए उपयोग किया जाता है।
यहाँ एक हैमबर्गर इकाई के लिए एक उदाहरण भंडार इंटरफ़ेस है:
<?php
namespace VinaiKopp\Kitchen\Api;
use Magento\Framework\Api\SearchCriteriaInterface;
use VinaiKopp\Kitchen\Api\Data\HamburgerInterface;
interface HamburgerRepositoryInterface
{
/**
* @param int $id
* @return \VinaiKopp\Kitchen\Api\Data\HamburgerInterface
* @throws \Magento\Framework\Exception\NoSuchEntityException
*/
public function getById($id);
/**
* @param \VinaiKopp\Kitchen\Api\Data\HamburgerInterface $hamburger
* @return \VinaiKopp\Kitchen\Api\Data\HamburgerInterface
*/
public function save(HamburgerInterface $hamburger);
/**
* @param \VinaiKopp\Kitchen\Api\Data\HamburgerInterface $hamburger
* @return void
*/
public function delete(HamburgerInterface $hamburger);
/**
* @param \Magento\Framework\Api\SearchCriteriaInterface $searchCriteria
* @return \VinaiKopp\Kitchen\Api\Data\HamburgerSearchResultInterface
*/
public function getList(SearchCriteriaInterface $searchCriteria);
}
जरूरी! यहाँ timesinks हो!
यहाँ कुछ गच हैं जो आपको गलत होने पर डिबग करने के लिए कठिन हैं:
- यदि आप इसे REST API में हुक करना चाहते हैं, तो PHP7 स्केलर तर्क प्रकारों या रिटर्न प्रकारों का उपयोग न करें !
- सभी तर्कों और सभी प्रकार के रिटर्न प्रकार के लिए PHPDoc एनोटेशन जोड़ें!
- PHPDoc ब्लॉक में पूरी तरह से योग्य वर्ग नामों का उपयोग करें !
JSON या XML से डेटा को परिवर्तित करने के तरीके का निर्धारण करने के लिए एनोटेशन को Magento फ्रेमवर्क द्वारा पार्स किया जाता है। वर्ग आयात (अर्थात, useकथन) लागू नहीं होते हैं!
हर विधि में किसी भी तर्क प्रकार और वापसी प्रकार के साथ एक एनोटेशन होना चाहिए। यहां तक कि अगर कोई विधि कोई तर्क नहीं देती है और कुछ भी नहीं लौटाती है, तो इसके लिए एनोटेशन होना चाहिए:
/**
* @return void
*/
अदिश प्रकार ( string, int, floatऔर bool) भी निर्दिष्ट करने की बहस के लिए और एक वापसी मान के रूप में दोनों की है।
ध्यान दें कि ऊपर दिए गए उदाहरण में, ऑब्जेक्ट्स को वापस करने वाले तरीकों के एनोटेशन को इंटरफेस के रूप में भी निर्दिष्ट किया गया है।
वापसी प्रकार के इंटरफेस सभी Api\Dataनामस्थान / निर्देशिका में हैं।
यह इंगित करना है कि उनके पास कोई व्यावसायिक तर्क नहीं है। वे केवल डेटा के बैग हैं।
हमें आगे ये इंटरफेस बनाना होगा।
DTO इंटरफ़ेस बनाएँ
मुझे लगता है कि मैगेंटो इन इंटरफेस को "डेटा मॉडल" कहता है, एक ऐसा नाम जो मुझे बिल्कुल पसंद नहीं है।
इस प्रकार के वर्ग को आमतौर पर डेटा ट्रांसफर ऑब्जेक्ट या डीटीओ के रूप में जाना जाता है ।
इन डीटीओ वर्गों के पास केवल अपने सभी गुणों के लिए गेटर्स और सेटर हैं।
डेटा मॉडल पर DTO का उपयोग करने का कारण यह है कि ORM डेटा मॉडल, संसाधन मॉडल या दृश्य मॉडल के साथ भ्रमित करना कम आसान है ... बहुत सी चीजें पहले से ही Magento में मॉडल हैं।
PHP7 टाइपिंग के संबंध में समान प्रतिबंध जो कि रिपॉजिटरी पर लागू होते हैं, डीटीओ पर भी लागू होते हैं।
साथ ही, प्रत्येक विधि के पास सभी तर्क प्रकारों और रिटर्न प्रकार के साथ एनोटेशन होना चाहिए।
<?php
namespace VinaiKopp\Kitchen\Api\Data;
use Magento\Framework\Api\ExtensibleDataInterface;
interface HamburgerInterface extends ExtensibleDataInterface
{
/**
* @return int
*/
public function getId();
/**
* @param int $id
* @return void
*/
public function setId($id);
/**
* @return string
*/
public function getName();
/**
* @param string $name
* @return void
*/
public function setName($name);
/**
* @return \VinaiKopp\Kitchen\Api\Data\IngredientInterface[]
*/
public function getIngredients();
/**
* @param \VinaiKopp\Kitchen\Api\Data\IngredientInterface[] $ingredients
* @return void
*/
public function setIngredients(array $ingredients);
/**
* @return string[]
*/
public function getImageUrls();
/**
* @param string[] $urls
* @return void
*/
public function setImageUrls(array $urls);
/**
* @return \VinaiKopp\Kitchen\Api\Data\HamburgerExtensionInterface|null
*/
public function getExtensionAttributes();
/**
* @param \VinaiKopp\Kitchen\Api\Data\HamburgerExtensionInterface $extensionAttributes
* @return void
*/
public function setExtensionAttributes(HamburgerExtensionInterface $extensionAttributes);
}
यदि कोई विधि किसी सरणी को प्राप्त या वापस लाती है, तो सरणी में आइटम के प्रकार को PHPDoc एनोटेशन में निर्दिष्ट किया जाना है, इसके बाद एक वर्ग को खोलने और बंद करने के लिए ब्रैकेट है []।
यह अदिश मानों (जैसे int[]) के साथ-साथ वस्तुओं (उदाहरण IngredientInterface[]) दोनों के लिए सही है ।
ध्यान दें कि मैं Api\Data\IngredientInterfaceएक उदाहरण के रूप में वस्तुओं के एक सरणी को वापस करने के लिए उपयोग कर रहा हूं , मैं इस पोस्ट के अवयवों के कोड को कठिन नहीं जोड़ूंगा।
ExtensibleDataInterface?
ऊपर दिए गए उदाहरण HamburgerInterfaceमें ExtensibleDataInterface।
तकनीकी रूप से यह केवल तभी आवश्यक है जब आप चाहते हैं कि अन्य मॉड्यूल आपकी इकाई में विशेषताओं को जोड़ने में सक्षम हों।
यदि हां, तो आपको एक और गेट्टर / सेटर जोड़ी भी मिलाने की जरूरत है, जिसे कन्वेंशन कहा जाता है getExtensionAttributes()और setExtensionAttributes()।
इस विधि के रिटर्न प्रकार का नामकरण बहुत महत्वपूर्ण है!
Magento 2 फ्रेमवर्क इंटरफ़ेस, कार्यान्वयन और कार्यान्वयन के लिए कारखाना उत्पन्न करेगा यदि आप उन्हें सही नाम देते हैं। इन यांत्रिकी के विवरण इस पद के दायरे से बाहर हैं, हालांकि।
बस पता है, यदि आप जिस वस्तु को एक्स्टेंसिबल बनाना चाहते हैं \VinaiKopp\Kitchen\Api\Data\HamburgerInterface, उसके इंटरफेस को कहा जाता है , तो एक्सटेंशन विशेषताओं का प्रकार होना चाहिए \VinaiKopp\Kitchen\Api\Data\HamburgerExtensionInterface। इसलिए शब्द Extensionको Interfaceप्रत्यय से ठीक पहले इकाई नाम के बाद डाला जाना चाहिए ।
यदि आप नहीं चाहते हैं कि आपकी इकाई एक्स्टेंसिबल हो, तो DTO इंटरफ़ेस को किसी अन्य इंटरफ़ेस को विस्तारित करने की आवश्यकता नहीं है, getExtensionAttributes()और setExtensionAttributes()विधियों को छोड़ा जा सकता है।
अभी के डीटीओ इंटरफ़ेस के बारे में पर्याप्त है, रिपॉजिटरी इंटरफ़ेस पर लौटने का समय।
GetList () वापसी प्रकार SearchResults
रिपॉजिटरी विधि getListअभी तक एक और प्रकार, SearchResultsInterfaceअर्थात् एक उदाहरण देता है।
विधि getListनिश्चित रूप से निर्दिष्ट वस्तुओं से मेल खाने वाली वस्तुओं की एक सरणी लौटा सकती है SearchCriteria, लेकिन एक SearchResultsउदाहरण को वापस करने से रिटर्न मानों में कुछ उपयोगी मेटा डेटा जोड़ने की अनुमति मिलती है।
आप देख सकते हैं कि रिपॉजिटरी getList()मेथड इम्प्लीमेंटेशन में कैसे काम करता है ।
यहाँ उदाहरण हैमबर्गर खोज परिणाम इंटरफ़ेस है:
<?php
namespace VinaiKopp\Kitchen\Api\Data;
use Magento\Framework\Api\SearchResultsInterface;
interface HamburgerSearchResultInterface extends SearchResultsInterface
{
/**
* @return \VinaiKopp\Kitchen\Api\Data\HamburgerInterface[]
*/
public function getItems();
/**
* @param \VinaiKopp\Kitchen\Api\Data\HamburgerInterface[] $items
* @return void
*/
public function setItems(array $items);
}
यह सब इंटरफ़ेस है यह दो तरीकों getItems()और setItems()मूल इंटरफ़ेस के प्रकारों को ओवरराइड करता है ।
इंटरफेस का सारांश
अब हमारे पास निम्नलिखित इंटरफेस हैं:
\VinaiKopp\Kitchen\Api\HamburgerRepositoryInterface\VinaiKopp\Kitchen\Api\Data\HamburgerInterface\VinaiKopp\Kitchen\Api\Data\HamburgerSearchResultInterface
भंडार कुछ भी नहीं फैली हुई है, फैली हुई है ,
और फैली हुई है ।
HamburgerInterface\Magento\Framework\Api\ExtensibleDataInterface
HamburgerSearchResultInterface\Magento\Framework\Api\SearchResultsInterface
रिपॉजिटरी और डेटा मॉडल कार्यान्वयन बनाएं
अगला कदम तीन इंटरफेस के कार्यान्वयन को बनाना है।
रिपोजिटरी
संक्षेप में, रिपॉजिटरी यह काम करने के लिए ORM का उपयोग करती है।
getById(), save() और delete()तरीकों काफी सीधे आगे हैं। , एक निर्माता तर्क के रूप में भंडार में इंजेक्ट किया जिसका नीचे एक सा देखा जा सकता है।
HamburgerFactory
public function getById($id)
{
$hamburger = $this->hamburgerFactory->create();
$hamburger->getResource()->load($hamburger, $id);
if (! $hamburger->getId()) {
throw new NoSuchEntityException(__('Unable to find hamburger with ID "%1"', $id));
}
return $hamburger;
}
public function save(HamburgerInterface $hamburger)
{
$hamburger->getResource()->save($hamburger);
return $hamburger;
}
public function delete(HamburgerInterface $hamburger)
{
$hamburger->getResource()->delete($hamburger);
}
अब एक भंडार का सबसे दिलचस्प हिस्सा है, getList()विधि। विधि का अनुवाद करने में है संग्रह पर विधि कॉल में स्थिति।
getList()SerachCriteria
इस बात का मुश्किल हिस्सा हो रही है ANDऔर ORफिल्टर सही के लिए शर्तों, खासकर जब से संग्रह पर स्थिति की स्थापना के लिए वाक्य रचना कि क्या यह एक EAV या एक फ्लैट तालिका इकाई है के आधार पर अलग है।
ज्यादातर मामलों में, getList()नीचे दिए गए उदाहरण में सचित्र के रूप में लागू किया जा सकता है।
<?php
namespace VinaiKopp\Kitchen\Model;
use Magento\Framework\Api\SearchCriteriaInterface;
use Magento\Framework\Api\SortOrder;
use Magento\Framework\Exception\NoSuchEntityException;
use VinaiKopp\Kitchen\Api\Data\HamburgerInterface;
use VinaiKopp\Kitchen\Api\Data\HamburgerSearchResultInterface;
use VinaiKopp\Kitchen\Api\Data\HamburgerSearchResultInterfaceFactory;
use VinaiKopp\Kitchen\Api\HamburgerRepositoryInterface;
use VinaiKopp\Kitchen\Model\ResourceModel\Hamburger\CollectionFactory as HamburgerCollectionFactory;
use VinaiKopp\Kitchen\Model\ResourceModel\Hamburger\Collection;
class HamburgerRepository implements HamburgerRepositoryInterface
{
/**
* @var HamburgerFactory
*/
private $hamburgerFactory;
/**
* @var HamburgerCollectionFactory
*/
private $hamburgerCollectionFactory;
/**
* @var HamburgerSearchResultInterfaceFactory
*/
private $searchResultFactory;
public function __construct(
HamburgerFactory $hamburgerFactory,
HamburgerCollectionFactory $hamburgerCollectionFactory,
HamburgerSearchResultInterfaceFactory $hamburgerSearchResultInterfaceFactory
) {
$this->hamburgerFactory = $hamburgerFactory;
$this->hamburgerCollectionFactory = $hamburgerCollectionFactory;
$this->searchResultFactory = $hamburgerSearchResultInterfaceFactory;
}
// ... getById, save and delete methods listed above ...
public function getList(SearchCriteriaInterface $searchCriteria)
{
$collection = $this->collectionFactory->create();
$this->addFiltersToCollection($searchCriteria, $collection);
$this->addSortOrdersToCollection($searchCriteria, $collection);
$this->addPagingToCollection($searchCriteria, $collection);
$collection->load();
return $this->buildSearchResult($searchCriteria, $collection);
}
private function addFiltersToCollection(SearchCriteriaInterface $searchCriteria, Collection $collection)
{
foreach ($searchCriteria->getFilterGroups() as $filterGroup) {
$fields = $conditions = [];
foreach ($filterGroup->getFilters() as $filter) {
$fields[] = $filter->getField();
$conditions[] = [$filter->getConditionType() => $filter->getValue()];
}
$collection->addFieldToFilter($fields, $conditions);
}
}
private function addSortOrdersToCollection(SearchCriteriaInterface $searchCriteria, Collection $collection)
{
foreach ((array) $searchCriteria->getSortOrders() as $sortOrder) {
$direction = $sortOrder->getDirection() == SortOrder::SORT_ASC ? 'asc' : 'desc';
$collection->addOrder($sortOrder->getField(), $direction);
}
}
private function addPagingToCollection(SearchCriteriaInterface $searchCriteria, Collection $collection)
{
$collection->setPageSize($searchCriteria->getPageSize());
$collection->setCurPage($searchCriteria->getCurrentPage());
}
private function buildSearchResult(SearchCriteriaInterface $searchCriteria, Collection $collection)
{
$searchResults = $this->searchResultFactory->create();
$searchResults->setSearchCriteria($searchCriteria);
$searchResults->setItems($collection->getItems());
$searchResults->setTotalCount($collection->getSize());
return $searchResults;
}
}
एक के भीतर फिल्टर FilterGroupएक का उपयोग कर जोड़ा जा चाहिए या ऑपरेटर।
अलग-अलग फ़िल्टर समूह तार्किक और ऑपरेटर का उपयोग करके संयुक्त होते हैं ।
काजू
यह सबसे बड़ा काम था। अन्य इंटरफ़ेस कार्यान्वयन सरल हैं।
डीटीओ
Magento ने मूल रूप से डेवलपर्स को अलग-अलग वर्गों के रूप में डीटीओ को लागू करने का इरादा किया था, जो इकाई मॉडल से अलग है।
कोर टीम ने केवल ग्राहक मॉड्यूल के लिए ऐसा किया (हालांकि , \Magento\Customer\Api\Data\CustomerInterfaceइसे लागू \Magento\Customer\Model\Data\Customerनहीं किया गया है \Magento\Customer\Model\Customer)।
अन्य सभी मामलों में इकाई मॉडल डीटीओ इंटरफ़ेस को लागू करता है (उदाहरण के लिए \Magento\Catalog\Api\Data\ProductInterfaceद्वारा कार्यान्वित किया जाता है \Magento\Catalog\Model\Product)।
मैंने कोर टीम के सदस्यों से सम्मेलनों में इसके बारे में पूछा है, लेकिन मुझे अच्छी प्रतिक्रिया नहीं मिली कि क्या अच्छा अभ्यास माना जाना है।
मेरी धारणा है कि इस सिफारिश को छोड़ दिया गया है। हालांकि इस पर आधिकारिक बयान प्राप्त करना अच्छा होगा।
अभी के लिए मैंने DTO इंटरफ़ेस कार्यान्वयन के रूप में मॉडल का उपयोग करने के लिए व्यावहारिक निर्णय लिया है। यदि आपको लगता है कि एक अलग डेटा मॉडल का उपयोग करना क्लीनर है, तो ऐसा करने के लिए स्वतंत्र महसूस करें। दोनों दृष्टिकोण अभ्यास में ठीक काम करते हैं।
यदि डीटीओ पूर्णांक विस्तार करता है Magento\Framework\Api\ExtensibleDataInterface, तो मॉडल को विस्तारित करना होगा Magento\Framework\Model\AbstractExtensibleModel।
यदि आप एक्स्टेंसिबिलिटी की परवाह नहीं करते हैं, तो मॉडल ओआरएम मॉडल बेस क्लास का विस्तार करना जारी रख सकता है Magento\Framework\Model\AbstractModel।
चूंकि उदाहरण HamburgerInterfaceफैली ExtensibleDataInterfaceहैमबर्गर मॉडल का विस्तार AbstractExtensibleModel, के रूप में यहां देखा जा सकता:
<?php
namespace VinaiKopp\Kitchen\Model;
use Magento\Framework\Model\AbstractExtensibleModel;
use VinaiKopp\Kitchen\Api\Data\HamburgerExtensionInterface;
use VinaiKopp\Kitchen\Api\Data\HamburgerInterface;
class Hamburger extends AbstractExtensibleModel implements HamburgerInterface
{
const NAME = 'name';
const INGREDIENTS = 'ingredients';
const IMAGE_URLS = 'image_urls';
protected function _construct()
{
$this->_init(ResourceModel\Hamburger::class);
}
public function getName()
{
return $this->_getData(self::NAME);
}
public function setName($name)
{
$this->setData(self::NAME, $name);
}
public function getIngredients()
{
return $this->_getData(self::INGREDIENTS);
}
public function setIngredients(array $ingredients)
{
$this->setData(self::INGREDIENTS, $ingredients);
}
public function getImageUrls()
{
$this->_getData(self::IMAGE_URLS);
}
public function setImageUrls(array $urls)
{
$this->setData(self::IMAGE_URLS, $urls);
}
public function getExtensionAttributes()
{
return $this->_getExtensionAttributes();
}
public function setExtensionAttributes(HamburgerExtensionInterface $extensionAttributes)
{
$this->_setExtensionAttributes($extensionAttributes);
}
}
संपत्ति के नाम को स्थिरांक में निकालने से उन्हें एक स्थान पर रखने की अनुमति मिलती है। उन्हें गेट्टर / सेटर जोड़ी द्वारा और डेटाबेस स्क्रिप्ट बनाने वाली सेटअप स्क्रिप्ट द्वारा भी उपयोग किया जा सकता है। अन्यथा उन्हें स्थिरांक में निकालने का कोई लाभ नहीं है।
खोज
यह SearchResultsInterfaceलागू करने के लिए तीन इंटरफेस में से सबसे सरल है, क्योंकि यह एक फ्रेमवर्क क्लास से इसकी सभी कार्यक्षमता को विरासत में दे सकता है।
<?php
namespace VinaiKopp\Kitchen\Model;
use Magento\Framework\Api\SearchResults;
use VinaiKopp\Kitchen\Api\Data\HamburgerSearchResultInterface;
class HamburgerSearchResult extends SearchResults implements HamburgerSearchResultInterface
{
}
ObjectManager वरीयताओं को कॉन्फ़िगर करें
हालांकि कार्यान्वयन पूर्ण हैं, फिर भी हम अन्य वर्गों की निर्भरता के रूप में इंटरफेस का उपयोग नहीं कर सकते हैं, क्योंकि मैगेंटो फ्रेमवर्क ऑब्जेक्ट मैनेजर को यह नहीं पता है कि कार्यान्वयन का क्या उपयोग करना है। हमें etc/di.xmlवरीयताओं के साथ एक कॉन्फ़िगरेशन जोड़ने की आवश्यकता है ।
<?xml version="1.0"?>
<config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="urn:magento:framework:ObjectManager/etc/config.xsd">
<preference for="VinaiKopp\Kitchen\Api\HamburgerRepositoryInterface" type="VinaiKopp\Kitchen\Model\HamburgerRepository"/>
<preference for="VinaiKopp\Kitchen\Api\Data\HamburgerInterface" type="VinaiKopp\Kitchen\Model\Hamburger"/>
<preference for="VinaiKopp\Kitchen\Api\Data\HamburgerSearchResultInterface" type="VinaiKopp\Kitchen\Model\HamburgerSearchResult"/>
</config>
एपीआई संसाधन के रूप में रिपॉजिटरी को कैसे उजागर किया जा सकता है?
यह हिस्सा वास्तव में सरल है, यह इंटरफेस बनाने, कार्यान्वयन और उन्हें एक साथ वायरिंग करने वाले सभी काम से गुजरने का इनाम है।
बस हमें एक etc/webapi.xmlफाइल बनाने की जरूरत है ।
<?xml version="1.0"?>
<routes xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="urn:magento:module:Magento_Webapi:etc/webapi.xsd">
<route method="GET" url="/V1/vinaikopp_hamburgers/:id">
<service class="VinaiKopp\Kitchen\Api\HamburgerRepositoryInterface" method="getById"/>
<resources>
<resource ref="anonymous"/>
</resources>
</route>
<route method="GET" url="/V1/vinaikopp_hamburgers">
<service class="VinaiKopp\Kitchen\Api\HamburgerRepositoryInterface" method="getList"/>
<resources>
<resource ref="anonymouns"/>
</resources>
</route>
<route method="POST" url="/V1/vinaikopp_hamburgers">
<service class="VinaiKopp\Kitchen\Api\HamburgerRepositoryInterface" method="save"/>
<resources>
<resource ref="anonymous"/>
</resources>
</route>
<route method="PUT" url="/V1/vinaikopp_hamburgers">
<service class="VinaiKopp\Kitchen\Api\HamburgerRepositoryInterface" method="save"/>
<resources>
<resource ref="anonymous"/>
</resources>
</route>
<route method="DELETE" url="/V1/vinaikopp_hamburgers">
<service class="VinaiKopp\Kitchen\Api\HamburgerRepositoryInterface" method="delete"/>
<resources>
<resource ref="anonymous"/>
</resources>
</route>
</routes>
ध्यान दें कि यह कॉन्फ़िगरेशन न केवल रिपॉजिटरी का उपयोग आरईएस एंडपॉइंट्स के रूप में सक्षम करता है, बल्कि एसओजीए एपीआई के भाग के रूप में तरीकों को भी उजागर करता है।
पहला उदाहरण मार्ग में, <route method="GET" url="/V1/vinaikopp_hamburgers/:id">प्लेसहोल्डर :id, मैप की विधि के लिए तर्क के नाम से मेल खाना चाहिए public function getById($id)।
दो नामों का मिलान करना है, उदाहरण के लिए /V1/vinaikopp_hamburgers/:hamburgerIdकाम नहीं करेगा, क्योंकि विधि तर्क चर नाम है $id।
इस उदाहरण के लिए मैंने पहुँच-योग्यता सेट की है <resource ref="anonymous"/>। इसका मतलब यह है कि संसाधन बिना किसी प्रतिबंध के सार्वजनिक रूप से उजागर होता है!
केवल ग्राहक को लॉग में उपलब्ध संसाधन उपलब्ध कराने के लिए, उपयोग करें <resource ref="self"/>। इस स्थिति meमें संसाधन समापन बिंदु URL में विशेष शब्द का उपयोग $idवर्तमान में ग्राहक में लॉग इन की आईडी के साथ एक तर्क चर को पॉप्युलेट करने के लिए किया जाएगा ।
Magento ग्राहक पर एक नज़र है etc/webapi.xmlऔर CustomerRepositoryInterfaceअगर आप की जरूरत है कि।
अंत में, <resources>किसी व्यवस्थापक उपयोगकर्ता खाते में संसाधन तक पहुंच को प्रतिबंधित करने के लिए भी उपयोग किया जा सकता है। ऐसा करने के लिए <resource>रेफरी को किसी etc/acl.xmlफ़ाइल में परिभाषित पहचानकर्ता के पास सेट करें ।
उदाहरण के लिए, <resource ref="Magento_Customer::manage"/>ग्राहकों को प्रबंधित करने के लिए विशेषाधिकार प्राप्त किसी भी व्यवस्थापक खाते तक पहुंच को प्रतिबंधित करेगा।
कर्ल का उपयोग कर एक उदाहरण एपीआई क्वेरी इस तरह दिख सकती है:
$ curl -X GET http://example.com/rest/V1/vinaikopp_hamburgers/123
नोट: इस के जवाब के रूप में शुरू किया लिखित https://github.com/astorm/pestle/issues/195
की जाँच करें मूसल , खरीदने के Commercebug और एक बन patreon @alanstorm की