API প্রক্সি ডিজাইন ও ডেভেলপমেন্টের পেশাদার পদ্ধতি

আপনি Apigee Edge ডকুমেন্টেশন দেখছেন।
Apigee X ডকুমেন্টেশন দেখুন। তথ্য

এই ডকুমেন্টের উদ্দেশ্য হল Apigee Edge-এর সাথে ডেভেলপ করার জন্য স্ট্যান্ডার্ড ও পেশাদার পদ্ধতির একটি সেট প্রদান করা। এখানে যেসব বিষয় কভার করা হয়েছে তার মধ্যে রয়েছে ডিজাইন, কোডিং, নীতি ব্যবহার, মনিটরিং ও ডিবাগিং। সফল API প্রোগ্রাম প্রয়োগ করার জন্য Apigee-এর সাথে কাজ করা ডেভেলপারদের অভিজ্ঞতা থেকে এই তথ্য সংগ্রহ করা হয়েছে। এটি একটি জীবন্ত ডকুমেন্ট এবং এটি মাঝে মাঝে আপডেট করা হবে।

এখানে দেওয়া নির্দেশিকা ছাড়াও, আপনি Apigee Edge অ্যান্টিপ্যাটার্ন কমিউনিটি পোস্টও সহায়ক হিসেবে পেতে পারেন।

ডেভেলপমেন্ট স্ট্যান্ডার্ড

কমেন্ট ও ডকুমেন্টেশন

  • ProxyEndpoint এবং TargetEndpoint কনফিগারেশনে ইনলাইন কমেন্ট প্রদান করুন। কমেন্ট ফ্লোর রিডএবিলিটি বাড়ায়, বিশেষত যেখানে নীতি ফাইলের নাম ফ্লোর অন্তর্নিহিত কার্যকারিতা প্রকাশ করার জন্য যথেষ্ট বর্ণনামূলক নয়।
  • কমেন্ট সহায়ক করে তুলুন। অত্যুক্তি করা কমেন্ট এড়িয়ে চলুন।
  • ইনডেন্টেশন, স্পেসিং, ভার্টিক্যাল অ্যালাইনমেন্ট ইত্যাদি একই রকম রাখুন।

ফ্রেমওয়ার্ক-স্টাইল কোডিং

ফ্রেমওয়ার্ক-স্টাইল কোডিংয়ের মধ্যে লোকাল ডেভেলপমেন্ট এনভায়রনমেন্ট জুড়ে আবার ব্যবহার করার জন্য আপনার নিজস্ব ভার্সন কন্ট্রোল সিস্টেমে API প্রক্সি রিসোর্স স্টোর করা অন্তর্ভুক্ত। যেমন, কোনও নীতি আবার ব্যবহার করতে, সেটি সোর্স কন্ট্রোলে স্টোর করুন যাতে ডেভেলপাররা সেটি সিঙ্ক করতে এবং তাদের নিজস্ব প্রক্সি ডেভেলপমেন্ট এনভায়রনমেন্টে ব্যবহার করতে পারেন।

  • যেখানে সম্ভব, DRY ("নিজেকে পুনরাবৃত্তি করবেন না") চালু করতে, নীতি কনফিগারেশন ও স্ক্রিপ্টে বিশেষ, আবার ব্যবহারযোগ্য ফাংশন প্রয়োগ করা উচিত। যেমন, অনুরোধ মেসেজ থেকে কোয়েরি প্যারামিটার এক্সট্র্যাক্ট করার জন্য নির্দিষ্ট নীতিকে ExtractVariables.ExtractRequestParameters বলা যেতে পারে। CORS হেডার ইনজেক্ট করার জন্য নির্দিষ্ট নীতিকে AssignMessage.SetCORSHeaders বলা যেতে পারে। সেইসব নীতিকে আপনার সোর্স কন্ট্রোল সিস্টেমে স্টোর করা যেতে পারে এবং প্যারামিটার এক্সট্র্যাক্ট করা বা CORS হেডার সেট করার প্রয়োজন আছে এমন প্রতিটি API প্রক্সিতে যোগ করা যেতে পারে। এর ফলে আপনাকে অতিরিক্ত (এবং সেইজন্য কম ম্যানেজ করা যায়) কনফিগারেশন তৈরি করতে হবে না।
  • API প্রক্সি থেকে অব্যবহৃত নীতি ও রিসোর্স (জাভাস্ক্রিপ্ট, জাভা, XSLT ইত্যাদি) পরিষ্কার করুন, বিশেষ করে বড় রিসোর্স যা ইমপোর্ট ও ডিপ্লয় প্রক্রিয়াকে ধীর করে দিতে পারে।

নামকরণ সংক্রান্ত কনভেনশন

  • নীতি name অ্যাট্রিবিউট এবং XML নীতি ফাইলের নাম একই হতে হবে।
  • Script ও ServiceCallout নীতি name অ্যাট্রিবিউট এবং রিসোর্স ফাইলের নাম একই হতে হবে।
  • DisplayName আগে কখনও সেই API প্রক্সি নিয়ে কাজ করেননি এমন কাউকে নীতির ফাংশন সঠিকভাবে বর্ণনা করতে হবে।
  • ফাংশন অনুযায়ী নীতির নাম দিন। Apigee সাজেস্ট করে যে আপনার নীতির জন্য একটি সামঞ্জস্যপূর্ণ নামকরণ সংক্রান্ত নিয়মাবলী তৈরি করুন। যেমন, ড্যাশ দিয়ে আলাদা করা বর্ণনামূলক শব্দের ক্রমের আগে ছোট উপসর্গ ব্যবহার করুন। যেমন, AssignMessage নীতির জন্য AM-xxx। এছাড়াও, apigeelint টুল দেখুন।
  • রিসোর্স ফাইলের জন্য সঠিক এক্সটেনশন ব্যবহার করুন, .js জাভাস্ক্রিপ্টের জন্য, .py পাইথনের জন্য এবং .jar Java JAR ফাইলের জন্য।
  • ভেরিয়েবলের নাম যেন একই থাকে। আপনি camelCase বা under_score-এর মতো কোনও স্টাইল বেছে নিলে, API প্রক্সি জুড়ে এটি ব্যবহার করুন।
  • যেখানে সম্ভব, সেখানে ভেরিয়েবল প্রিফিক্স ব্যবহার করুন, যাতে ভেরিয়েবলগুলিকে তাদের উদ্দেশ্য অনুযায়ী সাজানো যায়, যেমন Consumer.username এবং Consumer.password।

API প্রক্সি ডেভেলপমেন্ট

প্রাথমিক ডিজাইন সংক্রান্ত বিবেচনা

  • RESTful API ডিজাইন সংক্রান্ত নির্দেশিকা পেতে, ই-বুক ডাউনলোড করুন ওয়েব API ডিজাইন: দ্য মিসিং লিঙ্ক।
  • API প্রক্সি তৈরি করার জন্য যেখানে সম্ভব সেখানে Apigee Edge নীতি ও কার্যকারিতা ব্যবহার করুন। JavaScript, Java বা Python রিসোর্সে সব প্রক্সি লজিক কোড করা এড়িয়ে চলুন।
  • গুছিয়ে ফ্লো তৈরি করুন। একই PreFlow ও Postflow-তে একাধিক শর্তাধীন অ্যাটাচমেন্টের পরিবর্তে প্রতিটিতে একটি করে শর্ত সহ একাধিক Flow ব্যবহার করা ভাল।
  • 'ফেলসেফ' হিসেবে, ProxyEndpoint BasePath সহ একটি ডিফল্ট API প্রক্সি তৈরি করুন /। এটি কোনও ডেভেলপার সাইটে বেস API অনুরোধ রিডাইরেক্ট করতে, কাস্টম উত্তর ফেরাতে অথবা ডিফল্ট উত্তর ফেরানোর চেয়ে বেশি উপযোগী messaging.adaptors.http.flow.ApplicationNotFoundঅন্য কোনও অ্যাকশন পারফর্ম করতে ব্যবহার করা যেতে পারে।
  • বিভিন্ন এনভায়র্নমেন্টে প্রোমোশন সমর্থন করে, কনক্রিট URL থেকে TargetEndpoint কনফিগারেশনকে আলাদা করতে TargetServer রিসোর্স ব্যবহার করুন।
    ব্যাকএন্ড সার্ভার জুড়ে লোড ব্যালেন্সিং দেখুন।
  • আপনার একাধিক RouteRule থাকলে, একটিকে 'default' হিসেবে তৈরি করুন, অর্থাৎ, এমন একটি RouteRule তৈরি করুন যাতে কোনও শর্ত নেই। কন্ডিশনাল রাউটের তালিকায় ডিফল্ট RouteRule যেন সবার শেষে থাকে তা নিশ্চিত করুন। ProxyEndpoint-এ RouteRules উপর থেকে নিচে মূল্যায়ন করা হয়।
    API প্রক্সি কনফিগারেশন রেফারেন্স দেখুন।
  • API প্রক্সি বান্ডেলের সাইজ: API প্রক্সি বান্ডেলের সাইজ ১৫ এমবির বেশি হলে চলবে না। প্রাইভেট ক্লাউডের জন্য Apigee Edge-এ, আপনি নিম্নলিখিত লোকেশনে thrift_framed_transport_size_in_mb প্রপার্টি পরিবর্তন করে সাইজ সংক্রান্ত সীমাবদ্ধতা পরিবর্তন করতে পারবেন: cassandra.yaml (Cassandra-তে) এবং conf/apigee/management-server/repository.properties.
  • API ভার্সনিং: API ভার্সনিং সম্পর্কে Apigee-এর মতামত ও সাজেশন জানতে, ওয়েব API ডিজাইন: যে বিষয়গুলি উল্লেখ করা হয়নি ই-বুকের ভার্সনিং বিভাগ দেখুন।

CORS চালু করা

আপনার API প্রকাশ করার আগে, ক্লায়েন্ট-সাইড ক্রস-অরিজিন অনুরোধ কাজ করে এমনভাবে আপনার API প্রক্সিতে CORS চালু করতে হবে।

CORS (ক্রস-অরিজিন রিসোর্স শেয়ারিং) হল একটি স্ট্যান্ডার্ড মেকানিজম যা জাভাস্ক্রিপ্ট XMLHttpRequest (XHR) কলকে ওয়েবপেজে এক্সিকিউট করে, যাতে নন-অরিজিন ডোমেনের রিসোর্সের সাথে ইন্টার‍্যাক্ট করা যায়। CORS হল একই উৎস সম্পর্কিত নীতির একটি সাধারণ সমাধান যা সব ব্রাউজার প্রয়োগ করে। যেমন, আপনার ব্রাউজারে এক্সিকিউট করা JavaScript কোড থেকে Twitter API-তে XHR কল করলে, কলটি ব্যর্থ হবে। এর কারণ হল, আপনার ব্রাউজারে যে ডোমেন পৃষ্ঠা পরিবেশন করছে সেটি Twitter API পরিবেশনকারী ডোমেনের মতো নয়। CORS এই সমস্যার একটি সমাধান প্রদান করে যেখানে সার্ভাররা ক্রস-অরিজিন রিসোর্স শেয়ার করতে চাইলে "অপট-ইন" করতে পারে।

API প্রকাশ করার আগে আপনার API প্রক্সিতে CORS চালু করা সম্পর্কে তথ্য পেতে, দেখুন API প্রক্সিতে CORS সাপোর্ট যোগ করা।

মেসেজ পেলোডের সাইজ

Edge-এ মেমরি সংক্রান্ত সমস্যা এড়াতে, মেসেজ পেলোডের সাইজ ১০ এমবিতে সীমাবদ্ধ রাখা হয়েছে। সেইসব সাইজ ছাড়িয়ে গেলে protocol.http.TooBigBody সমস্যা হয়।

এই Apigee কমিউনিটি পোস্টে এই সমস্যা সম্পর্কে আলোচনা করা হয়েছে।

Edge-এ বড় মেসেজ সাইজ ম্যানেজ করার জন্য নিম্নলিখিত কৌশলগুলি সাজেস্ট করা হয়:

  • অনুরোধ ও উত্তর স্ট্রিম করা। মনে রাখবেন, আপনি স্ট্রিম করলে, নীতি আর মেসেজ কন্টেন্ট অ্যাক্সেস করতে পারে না। স্ট্রিমিং অনুরোধ ও উত্তর দেখুন।
  • Edge for Private Cloud ভার্সন 4.15.07 এবং এর আগের ভার্সনে, মেসেজ প্রসেসর http.properties ফাইল এডিট করে HTTPResponse.body.buffer.limit প্যারামিটারে সীমা বাড়ান। প্রোডাকশনে পরিবর্তন ডেপ্লয় করার আগে পরীক্ষা করে নিতে ভুলবেন না।
  • Edge for Private Cloud ভার্সন 4.16.01 এবং এর পরের যেকোনও ভার্সনে, পে-লোড সহ অনুরোধে অবশ্যই Content-Length হেডার থাকতে হবে অথবা স্ট্রিমিংয়ের ক্ষেত্রে "Transfer-Encoding: chunked" হেডার থাকতে হবে। খালি পেলোড সহ API প্রক্সিতে POST করার জন্য, আপনাকে অবশ্যই ০-এর কন্টেন্ট-দৈর্ঘ্য পাস করতে হবে।
  • Edge for Private Cloud ভার্সন 4.16.01 এবং এর পরের যেকোনও ভার্সনে, সীমা পরিবর্তন করতে /opt/apigee/router.properties বা message-processor.properties-এ নিম্নলিখিত প্রপার্টি সেট করুন। আরও জানতে রাউটার বা মেসেজ প্রসেসরে মেসেজের সাইজের সীমা সেট করুন।

    দুটি প্রপার্টির ডিফল্ট ভ্যালু "10m" যা 10MB-এর সমান:
    • conf_http_HTTPRequest.body.buffer.limit
    • conf_http_HTTPResponse.body.buffer.limit

সমস্যা ম্যানেজ করা

  • সব সমস্যা হ্যান্ডেল করার জন্য FaultRules ব্যবহার করুন। (RaiseFault নীতি মেসেজ ফ্লো বন্ধ করতে এবং প্রসেসিংকে FaultRules ফ্লোতে পাঠাতে ব্যবহার করা হয়।)
  • FaultRules ফ্লোয়ের মধ্যে, ফল্ট রেসপন্স তৈরি করতে AssignMessage নীতি ব্যবহার করুন, RaiseFault নীতি নয়। যে ধরনের সমস্যা হয়েছে তার ভিত্তিতে AssignMessage নীতি শর্তসাপেক্ষে প্রয়োগ করা হয়।
  • সবসময় একটি ডিফল্ট 'ক্যাচ-অল' ফল্ট হ্যান্ডলার অন্তর্ভুক্ত করে যাতে সিস্টেম-জেনারেটেড ফল্টকে গ্রাহকের সংজ্ঞায়িত ফল্ট রেসপন্স ফর্ম্যাটের সাথে ম্যাপ করা যায়।
  • সম্ভব হলে, আপনার কোম্পানি বা প্রোজেক্টে উপলভ্য যেকোনও স্ট্যান্ডার্ড ফর্ম্যাটের সাথে সবসময় ভুল উত্তর ম্যাচ করান।
  • অর্থপূর্ণ, মানুষের-পঠনযোগ্য সমস্যার মেসেজ ব্যবহার করুন যা সমস্যার অবস্থার সমাধান সাজেস্ট করে।

সমস্যা সমাধান করা দেখুন।

ইন্ডাস্ট্রির পেশাদার পদ্ধতি সম্পর্কে জানতে, RESTful সমস্যার উত্তর ডিজাইন দেখুন।

পারসিস্টেন্স

কী/ভ্যালু ম্যাপ

  • সীমিত ডেটা সেটের জন্য শুধুমাত্র কী/ভ্যালু ম্যাপ ব্যবহার করুন। এগুলি দীর্ঘমেয়াদী ডেটা স্টোর হিসেবে ডিজাইন করা হয়নি।
  • কী/ভ্যালু ম্যাপ ব্যবহার করার সময় পারফর্ম্যান্সের কথা বিবেচনা করুন, কারণ এই তথ্য Cassandra ডেটাবেসে সেভ করা হয়।

কী ভ্যালু ম্যাপ অপারেশন নীতি দেখুন।

উত্তর ক্যাশে করা

  • উত্তর সফল না হলে বা অনুরোধটি GET না হলে, উত্তর ক্যাশে পপুলেট করবেন না। তৈরি করা, আপডেট করা ও মুছে দেওয়া ডেটা ক্যাশে করা উচিত নয়। <SkipCachePopulation>response.status.code != 200 or request.verb != "GET"</SkipCachePopulation>
  • একটি সামঞ্জস্যপূর্ণ কন্টেন্টের ধরন (যেমন, XML বা JSON) দিয়ে ক্যাশে পূরণ করুন। responseCache এন্ট্রি রিট্রিভ করার পরে, JSONtoXML বা XMLToJSON-এর মাধ্যমে প্রয়োজনীয় কন্টেন্টের ধরনে কনভার্ট করুন। এর ফলে ডবল, ট্রিপল বা আরও বেশি ডেটা স্টোর করা আটকানো যাবে।
  • ক্যাশিংয়ের প্রয়োজনীয়তা পূরণের জন্য ক্যাশে কী যথেষ্ট কিনা তা নিশ্চিত করুন। অনেক ক্ষেত্রে, অনন্য শনাক্তকারী হিসেবে request.querystring ব্যবহার করা যেতে পারে।
  • ক্যাশে কী-তে API key (client_id) যোগ করবেন না, যদি না স্পষ্টভাবে প্রয়োজন হয়। বেশিরভাগ ক্ষেত্রে, শুধুমাত্র কী দিয়ে সুরক্ষিত API কোনও অনুরোধের জন্য সব ক্লায়েন্টকে একই ডেটা রিটার্ন করবে। API কী-এর উপর ভিত্তি করে একাধিক এন্ট্রির জন্য একই ভ্যালু স্টোর করা অদক্ষতা।
  • পুরনো ডেটা এড়াতে উপযুক্ত ক্যাশে মেয়াদ শেষ হওয়ার ইন্টারভ্যাল সেট করুন।
  • সম্ভব হলে, এমন রেসপন্স ক্যাশে নীতি রাখার চেষ্টা করুন যা ProxyEndpoint রেসপন্স PostFlow-তে যত দেরিতে সম্ভব ক্যাশে এক্সিকিউট করে। অন্যভাবে বলতে গেলে, এটি যেন অনুবাদ ও মধ্যস্থতা ধাপের পরে, JavaScript-ভিত্তিক মধ্যস্থতা ও JSON এবং XML-এর মধ্যে কনভার্সন সহ এক্সিকিউট করে। মধ্যস্থতা করা ডেটা ক্যাশে করে, আপনি প্রতিবার ক্যাশে করা ডেটা পুনরুদ্ধার করার সময় মধ্যস্থতা ধাপটি এক্সিকিউট করার পারফর্ম্যান্স সংক্রান্ত খরচ এড়াতে পারেন।

    মনে রাখবেন, মধ্যস্থতার ফলে যদি প্রতিটি অনুরোধের জন্য আলাদা আলাদা উত্তর পাওয়া যায়, তাহলে আপনি মধ্যস্থতা না করা ডেটা ক্যাশে করতে চাইতে পারেন।

  • ক্যাশে এন্ট্রি লুক-আপ করার জন্য রেসপন্স ক্যাশে নীতি ProxyEndpoint অনুরোধ প্রিফ্লোতে থাকতে হবে। ক্যাশে এন্ট্রি রিটার্ন করার আগে ক্যাশে কী জেনারেশন ছাড়া অতিরিক্ত লজিক প্রয়োগ করা এড়িয়ে চলুন। অন্যথায়, ক্যাশিংয়ের সুবিধা কমে যায়।
  • সাধারণত, আপনাকে সবসময় ক্লায়েন্টের অনুরোধের যত কাছাকাছি সম্ভব রেসপন্স ক্যাশে লুক-আপ রাখতে হবে। অন্যদিকে, ক্লায়েন্টের উত্তরের সাথে যতটা সম্ভব মিল রেখে আপনাকে রেসপন্স ক্যাশে পপুলেট করতে হবে।
  • প্রক্সিতে একাধিক, আলাদা আলাদা রেসপন্স ক্যাশে নীতি ব্যবহার করার সময়, প্রতিটি ক্ষেত্রে আলাদা আলাদা আচরণ নিশ্চিত করতে এইসব নির্দেশিকা মেনে চলুন:
    • পারস্পরিকভাবে এক্সক্লুসিভ শর্তের ভিত্তিতে প্রতিটি নীতি প্রয়োগ করুন। এর ফলে একাধিক রেসপন্স ক্যাশে নীতির মধ্যে শুধুমাত্র একটিই যে কার্যকর হবে তা নিশ্চিত করা যাবে।
    • প্রতিটি রেসপন্স ক্যাশে নীতির জন্য আলাদা আলাদা ক্যাশে রিসোর্স নির্ধারণ করুন। আপনি নীতির <CacheResource> এলিমেন্টে ক্যাশে রিসোর্স উল্লেখ করেন।

উত্তর ক্যাশে নীতি দেখুন।

নীতি ও কাস্টম কোড

নীতি বা কাস্টম কোড?

  • প্রথম ও প্রধানত বিল্ট-ইন নীতি ব্যবহার করুন (যখন সম্ভব)। Apigee নীতিগুলি আরও কঠোর, অপ্টিমাইজ করা এবং কাজ করে। যেমন, পে-লোড তৈরি করতে, পে-লোড থেকে তথ্য (XPath, JSONPath) বের করতে ইত্যাদি, JavaScript-এর পরিবর্তে (যখন সম্ভব) স্ট্যান্ডার্ড AssignMessage এবং ExtractVariables নীতি ব্যবহার করুন।
  • Python ও Java-এর তুলনায় JavaScript-কে বেশি পছন্দ করা হয়। তবে, পারফর্ম্যান্স যদি প্রাথমিক প্রয়োজন হয়, তাহলে জাভাস্ক্রিপ্টের পরিবর্তে Java ব্যবহার করা উচিত।

জাভাস্ক্রিপ্ট

  • Apigee নীতির চেয়ে JavaScript বেশি সহজবোধ্য হলে এটি ব্যবহার করুন (যেমন, অনেক আলাদা আলাদা URI কম্বিনেশনের জন্য target.url সেট করার সময়)।
  • JSON অবজেক্টের মাধ্যমে পুনরাবৃত্তি করা এবং Base64 এনকোডিং/ডিকোডিংয়ের মতো জটিল পেলোড পার্সিং।
  • JavaScript নীতির সময়সীমা আছে, তাই অসীম লুপ ব্লক করা হয়।
  • সবসময় জাভাস্ক্রিপ্ট স্টেপ ব্যবহার করুন এবং ফাইল jsc রিসোর্স ফোল্ডারে রাখুন। JavaScript নীতি, ডিপ্লয়মেন্টের সময় কোড প্রি-কম্পাইল করে।

জাভাস্ক্রিপ্ট সহ প্রোগ্রামিং API প্রক্সিদেখুন।

Java

  • পারফর্ম্যান্স সবচেয়ে বেশি গুরুত্বপূর্ণ হলে অথবা লজিক জাভাস্ক্রিপ্টে ইমপ্লিমেন্ট করা না গেলে Java ব্যবহার করুন।
  • সোর্স কোড ট্র্যাকিংয়ে Java সোর্স ফাইল যোগ করুন।

API প্রক্সিতে Java ব্যবহারের তথ্য পেতে Java কলআউটের মাধ্যমে উত্তরকে বড় হাতের অক্ষরে পরিবর্তন করুন এবং Java কলআউট নীতি দেখুন।

Python

  • অত্যন্ত প্রয়োজন না হলে Python ব্যবহার করবেন না। Python স্ক্রিপ্ট, সাধারণ এক্সিকিউশনের জন্য পারফর্ম্যান্স সংক্রান্ত বাধা সৃষ্টি করতে পারে, কারণ এটি রানটাইমে ইন্টারপ্রেট করা হয়।

স্ক্রিপ্ট কলআউট (Java, JavaScript, Python)

  • গ্লোবাল try/catch বা এর সমতুল্য কিছু ব্যবহার করুন।
  • অর্থপূর্ণ ব্যতিক্রমগুলি থ্রো করুন এবং ফল্ট রেসপন্সে ব্যবহারের জন্য এগুলিকে সঠিকভাবে ক্যাচ করুন।
  • সমস্যা হলে তা আগেভাগেই চিহ্নিত করে সরিয়ে দিন। সমস্ত ব্যতিক্রম ম্যানেজ করার জন্য গ্লোবাল try/catch ব্যবহার করবেন না।
  • প্রয়োজন হলে, নাল ও আনডিফাইনড চেক পারফর্ম করুন। কখন এটি করতে হবে তার একটি উদাহরণ হল যখন ঐচ্ছিক ফ্লো ভেরিয়েবল রিট্রিভ করা হয়।
  • স্ক্রিপ্ট কলআউটের মধ্যে HTTP/S অনুরোধ করা এড়িয়ে চলুন। পরিবর্তে, Apigee ServiceCallout নীতি ব্যবহার করুন, কারণ এই নীতি কানেকশনকে সাবলীলভাবে ম্যানেজ করে।

জাভাস্ক্রিপ্ট

  • API প্ল্যাটফর্মে JavaScript E4X-এর মাধ্যমে XML-এ কাজ করে।

জাভাস্ক্রিপ্ট অবজেক্ট মডেল দেখুন।

Java

  • মেসেজ পেলোড অ্যাক্সেস করার সময়, context.getMessage() বনাম context.getResponseMessage বা context.getRequestMessage ব্যবহার করে দেখুন। এর ফলে, অনুরোধ ও উত্তর, উভয় ফ্লোতেই কোডটি যাতে পেলোড রিট্রিভ করতে পারে তা নিশ্চিত করা যায়।
  • Apigee Edge সংস্থা বা এনভায়রনমেন্টে লাইব্রেরি ইমপোর্ট করুন এবং JAR ফাইলে এগুলি অন্তর্ভুক্ত করবেন না। এর ফলে বান্ডেলের সাইজ কমে যায় এবং অন্যান্য JAR ফাইল একই লাইব্রেরি রেপোজিটরি অ্যাক্সেস করতে পারে।
  • API প্রক্সি রিসোর্স ফোল্ডারের মধ্যে সেগুলি অন্তর্ভুক্ত করার পরিবর্তে Apigee রিসোর্স API ব্যবহার করে JAR ফাইল ইমপোর্ট করুন। এর ফলে ডিপ্লয়মেন্টের সময় কমে যাবে এবং একাধিক API প্রক্সি একই JAR ফাইলকে রেফার করতে পারবে। আরেকটি সুবিধা হল ক্লাস লোডার আইসোলেশন।
  • রিসোর্স ম্যানেজ করার জন্য Java ব্যবহার করবেন না (যেমন, থ্রেড পুল তৈরি ও ম্যানেজ করা )।

Java কলআউটের মাধ্যমে উত্তরকে বড় হাতের অক্ষরে পরিবর্তন করুন।

Python

  • অর্থপূর্ণ ব্যতিক্রম তৈরি করুন এবং Apigee-এর ত্রুটি সংক্রান্ত উত্তরে ব্যবহারের জন্য এগুলি সঠিকভাবে ক্যাচ করুন

Python স্ক্রিপ্ট নীতি দেখুন।

ServiceCallouts

  • প্রক্সি চেইনিং ব্যবহারের অনেক বৈধ ব্যবহারিক তথ্য আছে, যেখানে আপনি একটি API প্রক্সিতে পরিষেবা কলআউট ব্যবহার করে অন্য API প্রক্সিকে কল করেন। আপনি প্রক্সি চেইনিং ব্যবহার করলে, একই API প্রক্সিতে "অসীম লুপ" রিকার্সিভ কলআউট এড়িয়ে চলতে ভুলবেন না।

    আপনি যদি একই সংস্থা ও এনভায়রনমেন্টে থাকা প্রক্সিগুলির মধ্যে কানেক্ট করেন, তাহলে অপ্রয়োজনীয় নেটওয়ার্ক ওভারহেড এড়িয়ে লোকাল কানেকশন প্রয়োগ করার ব্যাপারে আরও জানতে চেনিং API প্রক্সি একসাথে দেখুন।

  • AssignMessage নীতি ব্যবহার করে ServiceCallout অনুরোধ মেসেজ তৈরি করুন এবং মেসেজ ভেরিয়েবলে অনুরোধ অবজেক্ট পপুলেট করুন। (এর মধ্যে অনুরোধের পেলোড, পাথ ও মেথড সেট করা অন্তর্ভুক্ত।)
  • নীতিতে কনফিগার করা URL-এ প্রোটোকল স্পেসিফিকেশন থাকতে হবে, অর্থাৎ URL-এর প্রোটোকল অংশ, https:// যেমন, কোনও ভেরিয়েবল দিয়ে নির্দিষ্ট করা যাবে না। এছাড়াও, আপনাকে URL-এর ডোমেন অংশের জন্য এবং URL-এর বাকি অংশের জন্য আলাদা আলাদা ভেরিয়েবল ব্যবহার করতে হবে। যেমন: https://{domain}/{path}
  • আলাদা মেসেজ ভেরিয়েবলে ServiceCallout-এর জন্য রেসপন্স অবজেক্ট স্টোর করুন। তারপরে, আপনি মেসেজ ভেরিয়েবল পার্স করতে পারবেন এবং অন্যান্য নীতির ব্যবহারের জন্য মূল মেসেজ পেলোড অক্ষত রাখতে পারবেন।

পরিষেবা কলআউট নীতি দেখুন।

এন্টিটি অ্যাক্সেস করা

AccessEntity নীতি

  • আরও ভালো পারফর্ম্যান্সের জন্য, অ্যাপের নামের পরিবর্তে uuid অনুযায়ী অ্যাপ খুঁজুন।

অ্যাক্সেস এন্টিটি নীতি দেখুন।

লগিং

  • বান্ডেল জুড়ে এবং একই বান্ডেলের মধ্যে একটি সাধারণ syslog নীতি ব্যবহার করুন। এর ফলে লগিংয়ের একটি সামঞ্জস্যপূর্ণ ফর্ম্যাট বজায় থাকবে।

MessageLogging নীতি দেখুন।

পর্যবেক্ষণে রাখা

Cloud গ্রাহকদের Apigee Edge-এর আলাদা আলাদা কম্পোনেন্ট (রাউটার, মেসেজ প্রসেসর ইত্যাদি) চেক করার প্রয়োজন নেই। Apigee-এর গ্লোবাল অপারেশন টিম API হেলথ চেক সহ সব কম্পোনেন্ট পুঙ্খানুপুঙ্খভাবে মনিটর করছে। গ্রাহকের দেওয়া হেলথ চেক অনুরোধও মনিটর করা হচ্ছে।

Apigee Analytics

Analytics, API মনিটরিং সংক্রান্ত অ-গুরুতর তথ্য প্রদান করতে পারে কারণ এতে ত্রুটির শতাংশ পরিমাপ করা হয়।

Analytics ড্যাশবোর্ড দেখুন।

ট্রেস

API Edge ম্যানেজমেন্ট UI-এর ট্রেস টুলটি API-এর ডেভেলপমেন্ট বা প্রোডাকশন অপারেশন চলাকালীন রানটাইম API সংক্রান্ত সমস্যা ডিবাগ করার জন্য উপযোগী।

ট্রেস টুল ব্যবহার করা দেখুন।

নিরাপত্তা

  • আপনার টেস্ট এনভায়রনমেন্টে অ্যাক্সেস সীমিত করতে IP অ্যাড্রেস সংক্রান্ত বিধিনিষেধ নীতি ব্যবহার করুন। আপনার ডেভেলপমেন্ট মেশিন বা এনভায়রনমেন্টের IP অ্যাড্রেসের জন্য অ্যাক্সেস দিন এবং বাকি সবকটির জন্য অ্যাক্সেস বন্ধ করুন। AccessControl নীতি।
  • প্রোডাকশনে ডেপ্লয় করা API প্রক্সিগুলিতে সবসময় কন্টেন্ট সুরক্ষা নীতি (JSON এবং বা XML) প্রয়োগ করুন। JSONThreatProtection নীতি।
  • নিরাপত্তা সংক্রান্ত আরও পেশাদার পদ্ধতি জানতে নিম্নলিখিত বিষয়গুলি দেখুন: