আপনি Apigee Edge-এর ডকুমেন্টেশন দেখছেন।
Apigee X ডকুমেন্টেশন .info- তে যান।
এই ডকুমেন্টের উদ্দেশ্য হলো Apigee Edge ব্যবহার করে ডেভেলপ করার জন্য কিছু স্ট্যান্ডার্ড এবং সেরা অনুশীলন প্রদান করা। এখানে ডিজাইন, কোডিং, পলিসি ব্যবহার, মনিটরিং এবং ডিবাগিং-এর মতো বিষয়গুলো অন্তর্ভুক্ত রয়েছে। সফল এপিআই প্রোগ্রাম বাস্তবায়নের জন্য Apigee ব্যবহার করে কাজ করা ডেভেলপারদের অভিজ্ঞতা থেকে এই তথ্যগুলো সংগ্রহ করা হয়েছে। এটি একটি চলমান ডকুমেন্ট এবং সময়ে সময়ে এটি আপডেট করা হবে।
এখানে দেওয়া নির্দেশিকাগুলোর পাশাপাশি, Apigee Edge Antipatterns Community পোস্টটিও আপনার জন্য সহায়ক হতে পারে।
উন্নয়ন মানদণ্ড
মন্তব্য এবং নথিপত্র
- ProxyEndpoint এবং TargetEndpoint কনফিগারেশনে ইনলাইন কমেন্ট দিন। কমেন্ট একটি ফ্লো-এর পাঠযোগ্যতা বাড়ায়, বিশেষ করে যেখানে পলিসি ফাইলের নামগুলো ফ্লো-এর অন্তর্নিহিত কার্যকারিতা বোঝানোর জন্য যথেষ্ট বর্ণনামূলক হয় না।
- মন্তব্যকে কার্যকরী করুন। গতানুগতিক মন্তব্য পরিহার করুন।
- সামঞ্জস্যপূর্ণ ইন্ডেন্টেশন, স্পেসিং, উল্লম্ব সারিবদ্ধতা ইত্যাদি ব্যবহার করুন।
ফ্রেমওয়ার্ক-শৈলীর কোডিং
ফ্রেমওয়ার্ক-স্টাইল কোডিং-এ, স্থানীয় ডেভেলপমেন্ট এনভায়রনমেন্টগুলোতে পুনঃব্যবহারের জন্য এপিআই প্রক্সি রিসোর্সগুলোকে আপনার নিজস্ব ভার্সন কন্ট্রোল সিস্টেমে সংরক্ষণ করা হয়। উদাহরণস্বরূপ, কোনো পলিসি পুনঃব্যবহার করতে হলে, সেটিকে সোর্স কন্ট্রোলে সংরক্ষণ করুন, যাতে ডেভেলপাররা সেটির সাথে সিঙ্ক করে তাদের নিজস্ব প্রক্সি ডেভেলপমেন্ট এনভায়রনমেন্টে ব্যবহার করতে পারে।
- DRY ("ডোন্ট রিপিট ইয়োরসেলফ") নীতি কার্যকর করতে, যেখানে সম্ভব, পলিসি কনফিগারেশন এবং স্ক্রিপ্টগুলোতে বিশেষায়িত ও পুনঃব্যবহারযোগ্য ফাংশন প্রয়োগ করা উচিত। উদাহরণস্বরূপ, রিকোয়েস্ট মেসেজ থেকে কোয়েরি প্যারামিটার এক্সট্র্যাক্ট করার জন্য একটি ডেডিকেটেড পলিসির নাম হতে পারে
ExtractVariables.ExtractRequestParameters। CORS হেডার ইনজেক্ট করার জন্য একটি ডেডিকেটেড পলিসির নাম হতে পারেAssignMessage.SetCORSHeaders। এরপর এই পলিসিগুলো আপনার সোর্স কন্ট্রোল সিস্টেমে সংরক্ষণ করা যেতে পারে এবং প্যারামিটার এক্সট্র্যাক্ট বা CORS হেডার সেট করার প্রয়োজন আছে এমন প্রতিটি API প্রক্সিতে যোগ করা যেতে পারে, যার জন্য আপনাকে অপ্রয়োজনীয় (এবং ফলস্বরূপ কম পরিচালনাযোগ্য) কনফিগারেশন তৈরি করার প্রয়োজন হবে না। - এপিআই প্রক্সি থেকে অব্যবহৃত পলিসি এবং রিসোর্স (জাভাস্ক্রিপ্ট, জাভা, এক্সএসএলটি, ইত্যাদি) মুছে ফেলুন, বিশেষ করে বড় রিসোর্সগুলো যেগুলো ইম্পোর্ট এবং ডিপ্লয় প্রক্রিয়াকে ধীর করে দিতে পারে।
নামকরণের নিয়মাবলী
- পলিসি
nameঅ্যাট্রিবিউট এবং এক্সএমএল পলিসি ফাইলের নাম অবশ্যই অভিন্ন হতে হবে। - Script এবং ServiceCallout পলিসির
nameঅ্যাট্রিবিউট এবং রিসোর্স ফাইলের নাম অভিন্ন হওয়া উচিত। - এমন কারো কাছে পলিসিটির কার্যকারিতা সঠিকভাবে বর্ণনা করার জন্য
DisplayNameএমন হওয়া উচিত, যিনি আগে কখনো সেই এপিআই প্রক্সিটি নিয়ে কাজ করেননি। - পলিসিগুলোর কার্যকারিতা অনুযায়ী নামকরণ করুন। Apigee আপনার পলিসিগুলোর জন্য একটি সামঞ্জস্যপূর্ণ নামকরণ পদ্ধতি প্রতিষ্ঠা করার পরামর্শ দেয়। উদাহরণস্বরূপ, সংক্ষিপ্ত প্রিফিক্স ব্যবহার করুন এবং তারপরে ড্যাশ দ্বারা পৃথক করা বর্ণনামূলক শব্দের একটি ক্রম ব্যবহার করুন। যেমন, AssignMessage পলিসির জন্য
AM-xxx। apigeelint টুলটিও দেখুন। - রিসোর্স ফাইলের জন্য সঠিক এক্সটেনশন ব্যবহার করুন, যেমন জাভাস্ক্রিপ্টের জন্য
.js, পাইথনের জন্য.py, এবং জাভা JAR ফাইলের জন্য.jar। - ভেরিয়েবলের নাম সামঞ্জস্যপূর্ণ হওয়া উচিত। আপনি যদি ক্যামেলকেস (camelCase) বা আন্ডারস্কোর (under_score)-এর মতো কোনো স্টাইল বেছে নেন, তবে পুরো এপিআই প্রক্সি জুড়ে সেটিই ব্যবহার করুন।
- সম্ভব হলে, ভেরিয়েবলের উদ্দেশ্য অনুযায়ী সেগুলোকে সাজাতে ভেরিয়েবল প্রিফিক্স ব্যবহার করুন, যেমন—
Consumer.usernameএবংConsumer.password।
এপিআই প্রক্সি উন্নয়ন
প্রাথমিক নকশা বিবেচনা
- RESTful API ডিজাইন সংক্রান্ত নির্দেশনার জন্য “Web API Design: The Missing Link” ই-বুকটি ডাউনলোড করুন।
- এপিআই প্রক্সি তৈরি করতে যেখানে সম্ভব Apigee Edge-এর পলিসি এবং কার্যকারিতা ব্যবহার করুন। জাভাস্ক্রিপ্ট, জাভা বা পাইথন রিসোর্সে সমস্ত প্রক্সি লজিক কোড করা থেকে বিরত থাকুন।
- ফ্লো-গুলো সুসংগঠিতভাবে তৈরি করুন। একই প্রি-ফ্লো এবং পোস্ট-ফ্লো-তে একাধিক শর্তসাপেক্ষ সংযুক্তি যুক্ত করার চেয়ে, প্রতিটি ফ্লো-তে একটিমাত্র শর্ত থাকা শ্রেয়।
- একটি 'ফেলসেফ' ব্যবস্থা হিসেবে,
/এর ProxyEndpoint BasePath সহ একটি ডিফল্ট এপিআই প্রক্সি তৈরি করুন। এটি বেস এপিআই অনুরোধগুলিকে একটি ডেভেলপার সাইটে পুনঃনির্দেশিত করতে, একটি কাস্টম প্রতিক্রিয়া ফেরত দিতে, অথবা ডিফল্টmessaging.adaptors.http.flow.ApplicationNotFoundফেরত দেওয়ার চেয়ে আরও কার্যকর অন্য কোনো কাজ সম্পাদন করতে ব্যবহার করা যেতে পারে।
- TargetServer রিসোর্স ব্যবহার করে TargetEndpoint কনফিগারেশনগুলোকে সুনির্দিষ্ট URL থেকে বিচ্ছিন্ন করুন, যা বিভিন্ন এনভায়রনমেন্টে প্রোমোশন সমর্থন করে।
ব্যাকএন্ড সার্ভারগুলোতে লোড ব্যালান্সিং দেখুন। - আপনার যদি একাধিক RouteRule থাকে, তাহলে একটিকে 'ডিফল্ট' হিসেবে তৈরি করুন, অর্থাৎ এমন একটি RouteRule যা কোনো শর্তযুক্ত নয়। নিশ্চিত করুন যে ডিফল্ট RouteRule-টি শর্তাধীন রাউটগুলোর তালিকায় শেষে সংজ্ঞায়িত করা হয়েছে। ProxyEndpoint-এ RouteRule-গুলো উপর থেকে নিচে মূল্যায়ন করা হয়।
এপিআই প্রক্সি কনফিগারেশন রেফারেন্স দেখুন। - এপিআই প্রক্সি বান্ডেলের আকার: এপিআই প্রক্সি বান্ডেল ১৫ মেগাবাইটের বেশি হতে পারবে না। Apigee Edge for Private Cloud-এ, আপনি নিম্নলিখিত স্থানগুলিতে
thrift_framed_transport_size_in_mbপ্রপার্টিটি পরিবর্তন করে এই আকারের সীমাবদ্ধতা বদলাতে পারেন: cassandra.yaml (ক্যাসান্ড্রাতে) এবং conf/apigee/management-server/repository.properties। - এপিআই ভার্সনিং: এপিআই ভার্সনিং বিষয়ে Apigee-এর মতামত ও সুপারিশের জন্য, "Web API Design: The Missing Link" ই-বুকটির ভার্সনিং বিভাগটি দেখুন।
CORS সক্ষম করা
আপনার API পাবলিশ করার আগে, ক্লায়েন্ট-সাইড ক্রস-অরিজিন রিকোয়েস্ট সাপোর্ট করার জন্য আপনার API প্রক্সিগুলিতে CORS এনাবল করতে হবে।
CORS (ক্রস-অরিজিন রিসোর্স শেয়ারিং) হলো একটি স্ট্যান্ডার্ড ব্যবস্থা যা একটি ওয়েব পেজে এক্সিকিউট হওয়া জাভাস্ক্রিপ্ট XMLHttpRequest (XHR) কলগুলোকে নন-অরিজিন ডোমেইনের রিসোর্সের সাথে ইন্টারঅ্যাক্ট করার সুযোগ দেয়। সমস্ত ব্রাউজার দ্বারা বলবৎকৃত সেম-অরিজিন পলিসির একটি বহুল ব্যবহৃত সমাধান হলো CORS। উদাহরণস্বরূপ, আপনি যদি আপনার ব্রাউজারে এক্সিকিউট হওয়া জাভাস্ক্রিপ্ট কোড থেকে টুইটার এপিআই-তে একটি XHR কল করেন, তবে কলটি ব্যর্থ হবে। এর কারণ হলো, যে ডোমেইনটি আপনার ব্রাউজারে পেজটি সার্ভ করছে, সেটি টুইটার এপিআই সার্ভকারী ডোমেইনের মতো নয়। CORS এই সমস্যার একটি সমাধান প্রদান করে, যা সার্ভারগুলোকে ক্রস-অরিজিন রিসোর্স শেয়ারিং প্রদান করতে চাইলে "অপট-ইন" করার সুযোগ দেয়।
এপিআইগুলো প্রকাশ করার আগে আপনার এপিআই প্রক্সিগুলোতে CORS সক্রিয় করার বিষয়ে তথ্যের জন্য, “Adding CORS support to an API proxy” দেখুন।
বার্তার পেলোড আকার
Edge-এ মেমরি সংক্রান্ত সমস্যা এড়ানোর জন্য, মেসেজ পেলোড সাইজ ১০ মেগাবাইটে সীমাবদ্ধ রাখা হয়েছে। এই সাইজ অতিক্রম করলে protocol.http.TooBigBody এরর দেখা দেয়।
এই বিষয়টি Apigee কমিউনিটির এই পোস্টেও আলোচনা করা হয়েছে।
Edge-এ বড় আকারের মেসেজ পরিচালনার জন্য নিম্নলিখিত কৌশলগুলি সুপারিশ করা হলো:
- স্ট্রিম অনুরোধ এবং প্রতিক্রিয়া। মনে রাখবেন যে আপনি যখন স্ট্রিম করেন, তখন পলিসিগুলোর আর বার্তার বিষয়বস্তুতে অ্যাক্সেস থাকে না। স্ট্রিমিং অনুরোধ এবং প্রতিক্রিয়া দেখুন।
- Edge for Private Cloud সংস্করণ 4.15.07 এবং তার পূর্ববর্তী সংস্করণগুলিতে,
HTTPResponse.body.buffer.limitপ্যারামিটারে সীমা বাড়ানোর জন্য মেসেজ প্রসেসরেরhttp.propertiesফাইলটি সম্পাদনা করুন। প্রোডাকশনে পরিবর্তনটি প্রয়োগ করার আগে অবশ্যই পরীক্ষা করে নিন। - Edge for Private Cloud সংস্করণ 4.16.01 এবং তার পরবর্তী সংস্করণগুলিতে, পেলোড সহ অনুরোধগুলিতে অবশ্যই Content-Length হেডার অন্তর্ভুক্ত করতে হবে, অথবা স্ট্রিমিংয়ের ক্ষেত্রে "Transfer-Encoding: chunked" হেডারটি ব্যবহার করতে হবে। একটি খালি পেলোড সহ API প্রক্সিতে POST অনুরোধের জন্য, আপনাকে অবশ্যই Content-Length হিসেবে 0 পাস করতে হবে।
- 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 ফ্লো-এর মধ্যে, ফল্ট রেসপন্স তৈরি করতে RaiseFault পলিসির পরিবর্তে AssignMessage পলিসি ব্যবহার করুন। সংঘটিত ফল্টের ধরনের ওপর ভিত্তি করে শর্তসাপেক্ষে AssignMessage পলিসিগুলো কার্যকর করুন।
- সর্বদা একটি ডিফল্ট 'ক্যাচ-অল' ফল্ট হ্যান্ডলার অন্তর্ভুক্ত থাকে, যাতে সিস্টেম-সৃষ্ট ফল্টগুলোকে গ্রাহক-সংজ্ঞায়িত ফল্ট রেসপন্স ফরম্যাটের সাথে ম্যাপ করা যায়।
- সম্ভব হলে, ত্রুটির প্রতিক্রিয়াগুলো সর্বদা আপনার কোম্পানি বা প্রকল্পে উপলব্ধ যেকোনো প্রমিত বিন্যাসের সাথে সামঞ্জস্যপূর্ণ রাখুন।
- অর্থপূর্ণ ও সহজে পাঠযোগ্য ত্রুটি বার্তা ব্যবহার করুন, যেগুলোতে ত্রুটির সমাধানের ইঙ্গিত থাকে।
ত্রুটি পরিচালনা দেখুন।
শিল্পের সর্বোত্তম অনুশীলনের জন্য, RESTful ত্রুটি প্রতিক্রিয়া ডিজাইন দেখুন।
অধ্যবসায়
কী/মান মানচিত্র
- কী/ভ্যালু ম্যাপ শুধুমাত্র সীমিত ডেটা সেটের জন্য ব্যবহার করুন। এগুলো দীর্ঘমেয়াদী ডেটা সংরক্ষণের জন্য তৈরি করা হয়নি।
- কী/ভ্যালু ম্যাপ ব্যবহার করার সময় পারফরম্যান্সের বিষয়টি বিবেচনা করুন, কারণ এই তথ্য ক্যাসান্ড্রা ডেটাবেসে সংরক্ষিত থাকে।
কী ভ্যালু ম্যাপ অপারেশন নীতি দেখুন।
প্রতিক্রিয়া ক্যাশিং
- যদি প্রতিক্রিয়া সফল না হয় বা অনুরোধটি GET না হয়, তাহলে প্রতিক্রিয়া ক্যাশে ডেটা যুক্ত করবেন না। তৈরি, আপডেট এবং মুছে ফেলার মতো অনুরোধ ক্যাশে করা উচিত নয়।
<SkipCachePopulation>response.status.code != 200 or request.verb != "GET"</SkipCachePopulation> - ক্যাশে একটিমাত্র সামঞ্জস্যপূর্ণ কন্টেন্ট টাইপ (যেমন, XML বা JSON) দিয়ে পূরণ করুন। একটি responseCache এন্ট্রি পুনরুদ্ধার করার পর, JSONtoXML বা XMLToJSON ব্যবহার করে সেটিকে প্রয়োজনীয় কন্টেন্ট টাইপে রূপান্তর করুন। এর ফলে দ্বিগুণ, তিনগুণ বা তারও বেশি ডেটা জমা হওয়া প্রতিরোধ করা যাবে।
- নিশ্চিত করুন যে ক্যাশ কী-টি ক্যাশিংয়ের প্রয়োজনীয়তার জন্য যথেষ্ট। অনেক ক্ষেত্রে,
request.querystringকে অনন্য শনাক্তকারী হিসেবে ব্যবহার করা যেতে পারে। - সুস্পষ্টভাবে প্রয়োজন না হলে, এপিআই কী (
client_id) ক্যাশ কী-তে অন্তর্ভুক্ত করবেন না। বেশিরভাগ ক্ষেত্রে, শুধুমাত্র একটি কী দ্বারা সুরক্ষিত এপিআইগুলো একটি নির্দিষ্ট অনুরোধের জন্য সমস্ত ক্লায়েন্টকে একই ডেটা ফেরত দেয়। এপিআই কী-এর উপর ভিত্তি করে একাধিক এন্ট্রির জন্য একই মান সংরক্ষণ করা অদক্ষ একটি পদ্ধতি। - ডার্টি রিড এড়াতে উপযুক্ত ক্যাশ এক্সপায়ারেশন ইন্টারভাল সেট করুন।
- যখনই সম্ভব, ক্যাশে ডেটা পূরণকারী রেসপন্স ক্যাশে পলিসিটি যেন ProxyEndpoint রেসপন্স PostFlow-তে যথাসম্ভব দেরিতে এক্সিকিউট হয়, তার চেষ্টা করুন। অন্য কথায়, এটিকে ট্রান্সলেশন এবং মিডিয়েশন ধাপগুলোর পরে এক্সিকিউট করুন, যার মধ্যে জাভাস্ক্রিপ্ট-ভিত্তিক মিডিয়েশন এবং JSON ও XML-এর মধ্যে রূপান্তরও অন্তর্ভুক্ত। মিডিয়েটেড ডেটা ক্যাশে করার মাধ্যমে, আপনি প্রতিবার ক্যাশে করা ডেটা পুনরুদ্ধার করার সময় মিডিয়েশন ধাপটি এক্সিকিউট করার পারফরম্যান্স খরচ এড়াতে পারবেন।
মনে রাখবেন, যদি মধ্যস্থতার ফলে এক অনুরোধ থেকে অন্য অনুরোধে ভিন্ন প্রতিক্রিয়া আসে, তাহলে আপনি মধ্যস্থতাবিহীন ডেটা ক্যাশ করতে চাইতে পারেন।
- ক্যাশ এন্ট্রি খোঁজার জন্য রেসপন্স ক্যাশ পলিসিটি ProxyEndpoint রিকোয়েস্ট PreFlow-তে থাকা উচিত। ক্যাশ এন্ট্রি ফেরত দেওয়ার আগে, ক্যাশ কী জেনারেশন ছাড়া অতিরিক্ত লজিক প্রয়োগ করা থেকে বিরত থাকুন। অন্যথায়, ক্যাশিংয়ের সুবিধাগুলো হ্রাস পায়।
- সাধারণভাবে, রেসপন্স ক্যাশ লুকআপ সবসময় ক্লায়েন্ট রিকোয়েস্টের যতটা সম্ভব কাছাকাছি রাখা উচিত। একইভাবে, রেসপন্স ক্যাশ পপুলেশনও ক্লায়েন্ট রেসপন্সের যতটা সম্ভব কাছাকাছি রাখা উচিত।
- একটি প্রক্সিতে একাধিক ও ভিন্ন রেসপন্স ক্যাশ পলিসি ব্যবহার করার সময়, প্রতিটির স্বতন্ত্র আচরণ নিশ্চিত করতে এই নির্দেশিকাগুলো অনুসরণ করুন:
- পারস্পরিকভাবে স্বতন্ত্র শর্তের ভিত্তিতে প্রতিটি পলিসি কার্যকর করুন। এটি নিশ্চিত করতে সাহায্য করবে যে একাধিক রেসপন্স ক্যাশ পলিসির মধ্যে কেবল একটিই কার্যকর হয়।
- প্রতিটি রেসপন্স ক্যাশ পলিসির জন্য আলাদা ক্যাশ রিসোর্স নির্ধারণ করুন। আপনি পলিসির <CacheResource> এলিমেন্টে ক্যাশ রিসোর্সটি নির্দিষ্ট করে দেন।
রেসপন্স ক্যাশে নীতি দেখুন।
নীতি এবং কাস্টম কোড
পলিসি নাকি কাস্টম কোড?
- সর্বাগ্রে (যখন সম্ভব) বিল্ট-ইন পলিসি ব্যবহার করুন। Apigee পলিসিগুলো সুরক্ষিত, অপ্টিমাইজ করা এবং সমর্থিত। উদাহরণস্বরূপ, পেলোড তৈরি করতে, পেলোড থেকে তথ্য বের করতে (XPath, JSONPath) ইত্যাদির জন্য (যখন সম্ভব) জাভাস্ক্রিপ্টের পরিবর্তে স্ট্যান্ডার্ড AssignMessage এবং ExtractVariables পলিসি ব্যবহার করুন।
- পাইথন এবং জাভার চেয়ে জাভাস্ক্রিপ্ট বেশি পছন্দনীয়। তবে, যদি পারফরম্যান্সই প্রধান বিবেচ্য বিষয় হয়, তবে জাভাস্ক্রিপ্টের পরিবর্তে জাভা ব্যবহার করা উচিত।
জাভাস্ক্রিপ্ট
- যদি Apigee পলিসির চেয়ে জাভাস্ক্রিপ্ট ব্যবহার করা বেশি সহজবোধ্য হয় (উদাহরণস্বরূপ, অনেকগুলো ভিন্ন URI কম্বিনেশনের জন্য
target.urlসেট করার ক্ষেত্রে), তবে তা ব্যবহার করুন। - জটিল পেলোড পার্সিং, যেমন একটি JSON অবজেক্টের মধ্যে পুনরাবৃত্তি এবং Base64 এনকোডিং/ডিকোডিং।
- জাভাস্ক্রিপ্ট পলিসিতে একটি সময়সীমা থাকায়, অসীম লুপ ব্লক করা হয়।
- সর্বদা জাভাস্ক্রিপ্ট স্টেপস ব্যবহার করুন এবং ফাইলগুলো
jscরিসোর্স ফোল্ডারে রাখুন। জাভাস্ক্রিপ্ট পলিসি টাইপ ডেপ্লয়মেন্টের সময় কোড প্রি-কম্পাইল করে।
জাভাস্ক্রিপ্ট দিয়ে এপিআই প্রক্সি প্রোগ্রামিং দেখুন।
জাভা
- যদি পারফরম্যান্স সর্বোচ্চ অগ্রাধিকার পায়, অথবা যদি লজিকটি জাভাস্ক্রিপ্টে বাস্তবায়ন করা না যায়, তবে জাভা ব্যবহার করুন।
- সোর্স কোড ট্র্যাকিং-এ জাভা সোর্স ফাইলগুলো অন্তর্ভুক্ত করুন।
এপিআই প্রক্সিতে জাভা ব্যবহারের তথ্যের জন্য ‘জাভা কলআউটের মাধ্যমে প্রতিক্রিয়াটিকে আপারকেসে রূপান্তর করুন’ এবং ‘জাভা কলআউট নীতি’ দেখুন।
পাইথন
- অত্যন্ত প্রয়োজন না হলে পাইথন ব্যবহার করবেন না। পাইথন স্ক্রিপ্ট সাধারণ কার্য সম্পাদনের ক্ষেত্রেও পারফরম্যান্সের প্রতিবন্ধকতা সৃষ্টি করতে পারে, কারণ এটি রানটাইমে ইন্টারপ্রেট করা হয়।
স্ক্রিপ্ট কলআউট (জাভা, জাভাস্ক্রিপ্ট, পাইথন)
- গ্লোবাল try/catch বা এর সমতুল্য কিছু ব্যবহার করুন।
- অর্থপূর্ণ এক্সেপশন থ্রো করুন এবং ফল্ট রেসপন্সে ব্যবহারের জন্য সেগুলোকে যথাযথভাবে ক্যাচ করুন।
- শুরুতেই এক্সেপশন থ্রো এবং ক্যাচ করুন। সব এক্সেপশন হ্যান্ডেল করার জন্য গ্লোবাল try/catch ব্যবহার করবেন না।
- প্রয়োজন হলে নাল (null) এবং আনডিফাইন্ড (undefined) যাচাই করুন। ঐচ্ছিক ফ্লো ভেরিয়েবল (optional flow variables) পুনরুদ্ধার করার সময় এটি করার একটি উদাহরণ হলো।
- স্ক্রিপ্ট কলআউটের ভিতরে HTTP/S অনুরোধ করা থেকে বিরত থাকুন। এর পরিবর্তে, Apigee ServiceCallout পলিসি ব্যবহার করুন, কারণ এই পলিসি সংযোগগুলিকে সুষ্ঠুভাবে পরিচালনা করে।
জাভাস্ক্রিপ্ট
- এপিআই প্ল্যাটফর্মে জাভাস্ক্রিপ্ট E4X- এর মাধ্যমে এক্সএমএল সমর্থন করে।
জাভাস্ক্রিপ্ট অবজেক্ট মডেল দেখুন।
জাভা
- মেসেজ পেলোড অ্যাক্সেস করার সময়,
context.getResponseMessageবাcontext.getRequestMessageপরিবর্তেcontext.getMessage()ব্যবহার করার চেষ্টা করুন। এটি নিশ্চিত করে যে কোডটি রিকোয়েস্ট এবং রেসপন্স উভয় ফ্লোতেই পেলোডটি পুনরুদ্ধার করতে পারে। - Apigee Edge অর্গানাইজেশন বা এনভায়রনমেন্টে লাইব্রেরিগুলো ইম্পোর্ট করুন এবং এগুলো JAR ফাইলে অন্তর্ভুক্ত করবেন না। এতে বান্ডেলের আকার কমে যায় এবং অন্যান্য JAR ফাইল একই লাইব্রেরি রিপোজিটরি অ্যাক্সেস করতে পারে।
- এপিআই প্রক্সি রিসোর্স ফোল্ডারের ভিতরে JAR ফাইল অন্তর্ভুক্ত করার পরিবর্তে Apigee রিসোর্স এপিআই ব্যবহার করে সেগুলোকে ইম্পোর্ট করুন। এটি ডেপ্লয়মেন্টের সময় কমিয়ে দেবে এবং একাধিক এপিআই প্রক্সিকে একই JAR ফাইল রেফারেন্স করার সুযোগ দেবে। এর আরেকটি সুবিধা হলো ক্লাস লোডার আইসোলেশন।
- রিসোর্স হ্যান্ডলিংয়ের জন্য (যেমন, থ্রেড পুল তৈরি ও পরিচালনা) জাভা ব্যবহার করবেন না।
জাভা কলআউট ব্যবহার করে প্রতিক্রিয়াটিকে আপারকেসে রূপান্তর করার পদ্ধতি দেখুন।
পাইথন
- অর্থপূর্ণ এক্সেপশন থ্রো করুন এবং Apigee ফল্ট রেসপন্সে ব্যবহারের জন্য সেগুলোকে যথাযথভাবে ক্যাচ করুন।
পাইথন স্ক্রিপ্ট নীতিমালা দেখুন।
সার্ভিস কলআউট
- প্রক্সি চেইনিং ব্যবহারের অনেক বৈধ ক্ষেত্র রয়েছে, যেখানে একটি এপিআই প্রক্সির সার্ভিস কলআউট ব্যবহার করে অন্য একটি এপিআই প্রক্সিকে কল করা হয়। প্রক্সি চেইনিং ব্যবহার করলে, একই এপিআই প্রক্সিতে বারবার রিকার্সিভ কলআউট করে "অসীম লুপ" তৈরি করা থেকে বিরত থাকুন।
আপনি যদি একই সংস্থা এবং পরিবেশে থাকা প্রক্সিগুলির মধ্যে সংযোগ স্থাপন করেন, তাহলে অপ্রয়োজনীয় নেটওয়ার্ক ওভারহেড এড়িয়ে একটি স্থানীয় সংযোগ বাস্তবায়নের বিষয়ে আরও জানতে "চেইনিং এপিআই প্রক্সিস টুগেদার" (Chaining API proxies together) অংশটি অবশ্যই দেখুন।
- AssignMessage পলিসি ব্যবহার করে একটি ServiceCallout রিকোয়েস্ট মেসেজ তৈরি করুন এবং রিকোয়েস্ট অবজেক্টটি একটি মেসেজ ভেরিয়েবলে রাখুন। (এর মধ্যে রিকোয়েস্ট পেলোড, পাথ এবং মেথড সেট করা অন্তর্ভুক্ত।)
- পলিসির মধ্যে কনফিগার করা URL-টিতে প্রোটোকল স্পেসিফিকেশন থাকা আবশ্যক, অর্থাৎ URL-এর প্রোটোকল অংশ, যেমন
https://, কোনো ভেরিয়েবল দ্বারা নির্দিষ্ট করা যাবে না। এছাড়াও, আপনাকে URL-এর ডোমেইন অংশের জন্য এবং URL-এর বাকি অংশের জন্য আলাদা ভেরিয়েবল ব্যবহার করতে হবে। উদাহরণস্বরূপ:https://{domain}/{path} - একটি ServiceCallout-এর রেসপন্স অবজেক্টটি একটি আলাদা মেসেজ ভেরিয়েবলে সংরক্ষণ করুন। এরপর আপনি মেসেজ ভেরিয়েবলটি পার্স করতে পারবেন এবং অন্যান্য পলিসির ব্যবহারের জন্য মূল মেসেজ পেলোডটি অক্ষত রাখতে পারবেন।
সার্ভিস কলআউট নীতিমালা দেখুন।
সত্তাগুলিতে প্রবেশ করা
অ্যাক্সেসএন্টিটি পলিসি
- উন্নত পারফরম্যান্সের জন্য, অ্যাপের নামের পরিবর্তে
uuidদিয়ে অ্যাপগুলো খুঁজুন।
অ্যাক্সেস এনটিটি নীতি দেখুন।
লগিং
- বিভিন্ন বান্ডেলের মধ্যে এবং একই বান্ডেলের ভেতরে একটি সাধারণ সিস্টেম লগ পলিসি ব্যবহার করুন। এর ফলে লগিং ফরম্যাটটি সামঞ্জস্যপূর্ণ থাকবে।
মেসেজ লগিং নীতি দেখুন।
পর্যবেক্ষণ
ক্লাউড গ্রাহকদের Apigee Edge-এর স্বতন্ত্র উপাদানগুলো (যেমন রাউটার, মেসেজ প্রসেসর ইত্যাদি) পরীক্ষা করার প্রয়োজন নেই। গ্রাহকের স্বাস্থ্য পরীক্ষার অনুরোধের ভিত্তিতে, Apigee-এর গ্লোবাল অপারেশনস টিম এপিআই স্বাস্থ্য পরীক্ষার পাশাপাশি সমস্ত উপাদান পুঙ্খানুপুঙ্খভাবে পর্যবেক্ষণ করে থাকে।
অ্যাপিজি অ্যানালিটিক্স
যেহেতু ত্রুটির শতাংশ পরিমাপ করা হয়, তাই অ্যানালিটিক্স অ-গুরুত্বপূর্ণ এপিআই পর্যবেক্ষণ প্রদান করতে পারে।
অ্যানালিটিক্স ড্যাশবোর্ডগুলো দেখুন।
ট্রেস
কোনো এপিআই-এর উন্নয়ন বা প্রোডাকশন অপারেশনের সময়, এপিআই এজ ম্যানেজমেন্ট ইউআই- এর ট্রেস টুলটি রানটাইম এপিআই সমস্যা ডিবাগ করার জন্য উপযোগী।
ট্রেস টুল ব্যবহার দেখুন।
নিরাপত্তা
- আপনার টেস্ট এনভায়রনমেন্টে অ্যাক্সেস সীমিত করতে আইপি অ্যাড্রেস সীমাবদ্ধতা নীতি ব্যবহার করুন। আপনার ডেভেলপমেন্ট মেশিন বা এনভায়রনমেন্টের আইপি অ্যাড্রেসগুলোকে অ্যাক্সেস দিন এবং বাকি সবগুলোকে নিষিদ্ধ করুন। অ্যাক্সেস কন্ট্রোল নীতি ।
- প্রোডাকশনে ডেপ্লয় করা এপিআই প্রক্সিগুলিতে সর্বদা কন্টেন্ট সুরক্ষা নীতি (JSON এবং/অথবা XML) প্রয়োগ করুন। JSONThreatProtection নীতি ।
- নিরাপত্তার আরও সেরা অনুশীলন জানতে নিম্নলিখিত বিষয়গুলো দেখুন: