পরিবর্তনের জন্য দূরদর্শিতা সহ বাহ্যিক অ্যাপ্লিকেশনগুলির জন্য একটি এপিআই ডিজাইন করার চেষ্টা করা সহজ নয়, তবে সামান্য চিন্তাভাবনা পরে জীবনকে আরও সহজ করে তুলতে পারে। আমি এমন একটি স্কিম স্থাপনের চেষ্টা করছি যা পূর্ববর্তী সংস্করণ হ্যান্ডলারগুলি স্থানে রেখে পশ্চাদপটে সামঞ্জস্য রেখে ভবিষ্যতের পরিবর্তনগুলিকে সমর্থন করবে।
এই নিবন্ধের প্রাথমিক উদ্বেগটি কোনও প্রদত্ত পণ্য / সংস্থার জন্য সমস্ত সংজ্ঞায়িত শেষ পয়েন্টগুলির জন্য কোন প্যাটার্নটি অনুসরণ করা উচিত to
বেস স্কিম
https://rest.product.com/আমি একটি বেস ইউআরএল টেমপ্লেট দিয়েছি যে আমি তৈরি করেছি যে সমস্ত পরিষেবাদি /apiপাশাপাশি থাকা /authএবং অন্যান্য নন-রেস্ট বেসড এন্ডপয়েন্টগুলিতে থাকে /doc। অতএব আমি নীচের হিসাবে বেস সমাপ্তিগুলি স্থাপন করতে পারি:
https://rest.product.com/api/...
https://rest.product.com/auth/login
https://rest.product.com/auth/logout
https://rest.product.com/doc/...
পরিষেবা সমাপ্তি
এখন শেষ পয়েন্টগুলি তাদের জন্য। উদ্বেগের কথা POST, GET, DELETEএই প্রবন্ধের প্রাথমিক উদ্দেশ্য নয় এবং যারা কর্মের নিজেদের উপর উদ্বেগের বিষয়।
শেষের স্থানগুলি নামস্থান এবং ক্রিয়ায় বিভক্ত হতে পারে। রিটার্ন টাইপ বা প্রয়োজনীয় পরামিতিগুলিতে মৌলিক পরিবর্তনগুলিকে সমর্থন করার জন্য প্রতিটি ক্রিয়াকলাপ নিজেই উপস্থাপন করতে হবে।
একটি অনুমানমূলক চ্যাট পরিষেবা গ্রহণ করা যেখানে নিবন্ধিত ব্যবহারকারীরা নিম্নলিখিত বার্তাটি আমাদের কাছে পাঠাতে পারেন:
https://rest.product.com/api/messages/list/{user}
https://rest.product.com/api/messages/send
এখন ভবিষ্যতের এপিআই পরিবর্তনগুলির জন্য সংস্করণ সমর্থন যুক্ত করতে যা ভঙ্গ হতে পারে। আমরা হয় সংস্করণ স্বাক্ষর পরে /api/বা পরে যোগ করতে পারে /messages/। শেষের sendপয়েন্টটি দেওয়া হলে আমাদের নিম্নলিখিত ভি 1 এর জন্য নিম্নলিখিতটি থাকতে পারে।
https://rest.product.com/api/v1/messages/send
https://rest.product.com/api/messages/v1/send
সুতরাং আমার প্রথম প্রশ্নটি হল, সংস্করণ শনাক্তকারীর জন্য প্রস্তাবিত স্থানটি কী?
নিয়ন্ত্রণকারী কোড পরিচালনা করা
সুতরাং এখন আমরা প্রতিষ্ঠিত করেছি আমাদের পূর্ববর্তী সংস্করণগুলিকে সমর্থন করার প্রয়োজন আমাদের এভাবে কোনওভাবেই নতুন সংস্করণগুলির সময়ের সাথে সাথে হ্রাস করতে পারে যা হ্যান্ডেল কোডের হ্যান্ডেল করতে হবে। ধরে নিই আমরা জাভাতে এন্ডপয়েন্ট লিখছি আমরা প্যাকেজগুলির মাধ্যমে এটি পরিচালনা করতে পারি।
package com.product.messages.v1;
public interface MessageController {
void send();
Message[] list();
}
এর সুবিধাটি রয়েছে যে সমস্ত কোড নেমস্পেসের মাধ্যমে পৃথক করা হয়েছে যেখানে কোনও ব্রেকিং পরিবর্তনের অর্থ পরিষেবাটির শেষ পয়েন্টগুলির একটি নতুন অনুলিপি হবে। এর ক্ষতিকারকটি হ'ল সমস্ত কোড অনুলিপি করা প্রয়োজন এবং বাগ ফিক্সগুলি প্রতিটি অনুলিপিটির জন্য নতুন এবং পূর্ববর্তী সংস্করণগুলিতে প্রয়োগ / পরীক্ষা করা প্রয়োজন।
আরেকটি পদ্ধতি হ'ল প্রতিটি শেষ পয়েন্টের জন্য হ্যান্ডলার তৈরি করা।
package com.product.messages;
public class MessageServiceImpl {
public void send(String version) {
getMessageSender(version).send();
}
// Assume we have a List of senders in order of newest to oldest.
private MessageSender getMessageSender(String version) {
for (MessageSender s : senders) {
if (s.supportsVersion(version)) {
return s;
}
}
}
}
এটি এখন প্রতিটি প্রান্তে নিজেই সংস্করণকে পৃথক করে এবং বাগ ফিক্সগুলি ব্যাক পোর্টটিকে সামঞ্জস্য করে তোলে বেশিরভাগ ক্ষেত্রে কেবল একবার প্রয়োগ করা প্রয়োজন, তবে এর অর্থ এই যে এটি সমর্থন করার জন্য আমাদের প্রতিটি স্বতন্ত্র বিন্দুতে আরও কিছুটা বেশি কাজ করা দরকার।
সুতরাং আমার দ্বিতীয় প্রশ্নটি আছে "পূর্ববর্তী সংস্করণগুলিকে সমর্থন করার জন্য REST পরিষেবা কোডটি নকশা করার সর্বোত্তম উপায়" "