রেস্ট এপিআই - মোবাইল নির্দিষ্ট চ্যালেঞ্জ

Question

আমি মোবাইলের পাশে একটি নতুন আইওএস অ্যাপ প্রকল্পে কাজ করছি। কিছু আর্কিটেকচার পরিবর্তন ঘটছে এবং দেখা যাচ্ছে যে আমাদের একটি কাস্টম বিল্ট প্রাইভেট এপিআইয়ের উপর নির্ভর করতে হবে যা আমাদের নির্মিত অ্যাপ্লিকেশন এবং অন্য ক্লায়েন্ট যেমন একটি ওয়েবসাইট দ্বারা ব্যবহৃত হবে।

ডিজাইন করা এপিআই এইচটিটিপি ক্রিয়াগুলিতে ম্যাপযুক্ত সম্পদ-কেন্দ্রিক ইউআরআই এবং সিআরইউডি অপারেশনগুলির বিশিষ্ট স্টাইল অনুসরণ করে। ভালো জিনিস:

GET www.example.com/books
DELETE www.example.com/books/482094
POST www.example.com/users/6793

সমস্যাটি হ'ল এই স্টাইলটি প্রায়শই মোবাইল ক্লায়েন্টকে একটি একক অ্যাপ্লিকেশন স্ক্রিন লোড করার জন্য বা একক ব্যবহারকারী ইউআই ক্রিয়াকলাপ পরিচালনার জন্য অনেক অনুরোধ করতে পারে to এটি অ্যাপ্লিকেশনটির প্রয়োজনীয় সবকিছু না হওয়া পর্যন্ত 8 সেকেন্ডের জন্য লোডিং মোডে রাখে। একটি ধীর এবং প্রতিক্রিয়াহীন অ্যাপ।

কানেক্টিভিটির ক্ষেত্রে মোবাইল ক্লায়েন্টদের গুরুতর সীমাবদ্ধতা থাকে এবং তাই আদর্শভাবে আমাদের এই ধরণের নিয়ম অনুসরণ করা উচিত:

1 স্ক্রিন == 1 এপিআই কল

1 সেভ == 1 এপিআই কল।

অনেকগুলি পরিস্থিতি রয়েছে যেখানে এটি আপনাকে আরইএসটি নকশা নীতিগুলির সাথে সংঘর্ষের কোর্সে নিয়ে যায়, উদাহরণস্বরূপ:

• ধরা যাক আপনার অ্যাপ্লিকেশনটি এক দিনের জন্য অফলাইন হয়েছে এবং আপনাকে ব্যাক-এন্ড ডাটাবেসের চারটি টেবিলের সাথে সিঙ্ক করতে হবে এবং আপনার মতো কল দরকার www.example.com/sync_everything?since=2015-07-24
• আসুন বলতে পারি যে একটি স্ক্রিন রয়েছে যেখানে ব্যবহারকারী তার অনেকগুলি বস্তু সম্পাদনা করতে পারেন, উদাহরণস্বরূপ তার টুডো তালিকায় টিক্কি টাস্কগুলি। সেই সম্পাদনা প্রতি একক এপিআই কলের পরিবর্তে একক ব্যাচের এপিআই কলটিতে সেই সমস্ত কার্য রেকর্ড সম্পাদনা করার উপায় থাকতে হবে।
• আসুন আমরা বলি যে একটি পর্দা রয়েছে যা অর্ডার, বিক্রয় ও পণ্য ডিবি টেবিলগুলি থেকে তথ্য মিশ্রিত করে, আমার তিনটি পরিবর্তে একটি কলে সেই ডেটা পাওয়া উচিত।

ঝুঁকিটি হ'ল আমরা সম্ভবত সেখানে থাকা সবচেয়ে রেস্টহুল এপিআই এবং সেখানে থাকা সবচেয়ে অকেজো প্রতিক্রিয়াশীল মোবাইল অ্যাপ্লিকেশনটি দিয়ে শেষ করতে পারি।

জিনিসটি হ'ল আমি কেবল সেখানে একজন নতুন ঠিকাদার এবং আমার যা দরকার তা হ'ল এমন কিছু যা আমাকে এই বিষয়গুলি তৈরি করতে সহায়তা করে, ভাল সম্মানিত উত্স থেকে কিছু নিবন্ধ বা এরকম কিছু। প্রধান মোবাইল প্লেয়াররা তাদের মোবাইল ক্লায়েন্টের জন্য আরইএসটি স্টাইলের সাথে আপোস করে (যেমন: কম্পোজিট এগ্রিগেট এপিআই শেষ পয়েন্টগুলি ব্যবহার করে)।

অথবা এই সাধারণ সমস্যার কোনও সমাধান ধন্যবাদ!

Comments

আপনার প্রশ্নটি মনে হতে পারে, "একটি এআইপিআইএসইএসইএস স্টাইলটি ধরে রাখার সময় পছন্দ মতো বা অসম্পূর্ণ বস্তুর সংগ্রহ এবং এম্বেড করা অবজেক্টগুলিকে কীভাবে বিতরণ করতে পারে?" আমি আপনার প্রশ্ন বুঝতে পারি?

— জোশপ

আমি বিশ্বাস করি যে সাধারণ উত্তরটি হ'ল প্রতিটি REST কলটিতে বিভিন্ন alচ্ছিক পরামিতি গ্রহণ করা প্রয়োজন যাতে এটি নমনীয় হতে পারে তবে এখনও তুলনামূলক স্বজ্ঞাত। সিঙ্কিং কেসটি সর্বদা জটিল হবে তবে নিয়মিত পৃষ্ঠাগুলির জন্য আপনি সাধারণত একই ধরণের বেশ কয়েকটি কল , যেমন সমস্ত জিইটি, ঠিক তাকাচ্ছেন ?

— Ixrec

আমি মনে করি যখন সমস্যাটি সমান্তরাল অনুরোধগুলির অভাব হয় তখন আপনার এপিআই মানিয়ে নেওয়া ভুল সমাধান - ছোট ছোট 8 টি অনুরোধগুলি যখন একে অপরের জন্য অপেক্ষা করতে হয় না তখন একটি বড় অনুরোধের চেয়ে খুব খারাপ হয় না। আপনি কি HTTP / 2 এ স্যুইচ করতে পারবেন? বা কমপক্ষে HTTP / 1.1 পাইপলাইন ব্যবহার করবেন?

— আমন

আরও দেখুন: REST ওয়েব পরিষেবাদিতে ব্যাচ অপারেশন পরিচালনা করার জন্য প্যাটার্নস? । কীটি কোন ধরণের কমান্ড (এবং কোন পূর্বশর্তের অধীনে) কোনও সংঘাত ছাড়াই একসাথে ব্যাচ করা যায় তা সনাক্ত করে এবং তারপরে সজ্জিত আদেশের একটি JSON উপস্থাপনা তৈরি করে এবং তারপরে প্রেরণ করে। এটি আরইএসটি- র মূল আকর্ষণ হারিয়ে ফেলে যা এটির ক্যাশেযোগ্যতা তবে ক্যাশেবিলিটি সব ধরণের অ্যাপ্লিকেশনের ক্ষেত্রে সর্বদা প্রাসঙ্গিক নয়। মনে রাখবেন যে ল্যাজিকাল নির্ভরতা থাকলে ব্যাচ / চুক্তিটি প্রযোজ্য নয়।

— রওয়ং

পূর্ববর্তী প্রতিটি ক্রিয়াকলাপে অ-তুচ্ছ লজিকাল নির্ভরতা সহ মধ্যস্থতাকে একের পর এক ক্রিয়াকলাপে একাধিক ক্রিয়াকলাপ সম্পাদনের প্রয়োজন হওয়া পরিস্থিতির একটি উপমা, "সঞ্চিত প্রক্রিয়া" এর মতো কিছু, যা ডাটাবেসের অভ্যন্তরের পরিবর্তে সেই মিডলম্যানে সম্পাদিত হয়। নীচে, মধ্যস্থতাকারী একটি একক "সঞ্চিত পদ্ধতি" কলটিকে প্রয়োজনীয় হিসাবে অনেকগুলি RESTful অনুরোধগুলিতে রূপান্তর করতে অনুমোদিত, তবে এটি মধ্যস্থতাকারীর একটি বাস্তবায়ন বিশদ।

— রওয়ং

Answer 1

ডিজাইন করা এপিআই এইচটিটিপি ক্রিয়াগুলিতে ম্যাপযুক্ত সম্পদ-কেন্দ্রিক ইউআরআই এবং সিআরইউডি অপারেশনগুলির বিশিষ্ট স্টাইল অনুসরণ করে।

এই মুহুর্তে এটি আপনার সমস্যা।

আপনি আপনার ডাটাবেসের মডেলগুলিতে সীমাবদ্ধ রেখেছেন (আমি ধরে নিচ্ছি)। এর ফলে এই সমস্ত সংস্থানগুলি লোড হতে যুগে যুগে সময় লাগছে কারণ আপনার সার্ভারের এমন সংস্থানগুলির কোনও ধারণা নেই যা ডেটাবেসে প্রতিনিধিত্ব করে না।

উদাহরণস্বরূপ থাকতে পারে

www.example.com/books/482094
www.example.com/books/582045
www.example.com/books/427454
www.example.com/books/319343

আমার লাইব্রেরিটি পেতে সমস্ত লোড করতে হবে

এটি RESTful ডিজাইনে কোনও সমস্যা নয়, এটি আসলে একটি REST বিরোধী প্যাটার্ন। আরইএসটি-তে একেবারেই কিছু নেই যা বলে যে আমাদের সংস্থানগুলিতে আপনার সিস্টেমে ডাটাবেস মডেল সহ অন্য কোনও কিছুর সাথে এক থেকে এক ম্যাপিং থাকতে হবে।

সমাধানটি হ'ল আরও সংস্থান তৈরি করা যা আপনি কী লোড করতে চান তার সাথে আরও ভাল মেলে। আপনার যদি 5 টি সংস্থান থাকে যা সর্বদা একসাথে শেষ হয় এমন একটি নতুন সংস্থান তৈরি করুন যা সেই 5 টি সংস্থার জন্য তথ্য ধারণ করে।

আপনার যা হওয়া উচিত তা হ'ল এটি

www.example.com/users/334/my_library

যা কেবল ব্যবহারকারীর জন্য সমস্ত বই লোড করে। "মাই_লাইবারি" আপনার ডাটাবেসের কোনও মডেল নয়, তবে এটি একটি সংস্থান। সার্ভারটি এটি ডেটাবেজে মডেলগুলির উপর ভিত্তি করে তৈরি করে তবে কোনও 1-থেকে -1 ম্যাপিং নেই এবং সার্ভারটি আপনার ডিবি মডেলটি পরিবর্তন না করেই এই সংস্থান তৈরি করতে নমনীয়তা রয়েছে।

আপনারও থাকতে পারে

www.example.com/users/334/favioured_books
www.example.com/users/334/books_ordered_last_week
www.example.com/users/334/wishlist

যার কোনওটিই আপনার ডাটাবেস বা ডোমেন স্পেসে মডেল হিসাবে উপস্থিত থাকতে পারে না।

একটি বিস্তৃত ভুল ধারণা রয়েছে যে এটি করা ভুল কারণ কারণ রইলের মতো ফ্রেমওয়ার্কগুলি ডোমেন স্পেসের মডেলগুলিতে 1-থেকে -1 ফ্যাশনে 1-2 থেকে 1-এ ম্যাপ করার জন্য 1-থেকে -1 ফ্যাশনে সংস্থানগুলি ম্যাপ করতে শেখায়। এটি প্রয়োজনীয় নয় বা এটি সুপারিশ করা হয় না।

সংস্থানগুলি অসংখ্য, সস্তা এবং লাইটওয়েট হওয়া উচিত । এগুলি তৈরি করা সহজ হওয়া উচিত এবং এগুলি আপনার ডোমেন মডেল থেকে বাদ দেওয়া উচিত। যদি আপনি খুঁজে পান যে আপনার একটি নতুন প্রয়োজন কেবল আপনি একটি নতুন তৈরি করুন। এটি করতে যদি আপনার সমস্যা হয় তবে এটি আপনার ফ্রেমওয়ার্কের ফল্ট, আরইএসটি-তে কোনও দোষ নয়।

অবশ্যই এটির সাথে বৃহত সাবধানতা হ'ল আপনার কাঠামোটি আপনাকে এটি করতে দেয় কিনা। "আপনার সময় বাঁচাতে" এই কাজটি করা কঠিন করার জন্য রেলস এবং জ্যাঙ্গোর মতো ফ্রেমওয়ার্কগুলি 1-থেকে -1 মানচিত্রের কোর্সটি গ্রহণ করেছে। তবে এটি ফ্রেমওয়ার্কগুলির সাথে একটি ত্রুটি, আরএসটিফুল ডিজাইনের সাথে নয়।

জিম ওয়েবার এখানে এই সম্পর্কে আরও বিস্তারিতভাবে আলোচনা করছেন (পাশাপাশি রেলের কয়েকটি খননও রয়েছে!)

https://yow.eventer.com/yow-2011-1004/domain-driven-design-for-restful-systems-by-jim-webber-1047

Comments

এটি অত্যন্ত আকর্ষণীয় এবং আমি এটির সাথে পুরোপুরি একমত হই তবে দুঃখের বিষয়, আমি এপিআই করছি না এবং আমার যদি এর কোনও প্রভাব ফেলতে পারে তবে তার কোনও উপায় নেই। অনেক লোক এই "অ্যান্টি-প্যাটার্ন "টি সর্বত্র ব্যবহার করবে (বহু কারণে, কাঠামোর সীমাবদ্ধতা এক হ'ল) ​​এবং তারা কেবল তাদের ডাটাবেস সম্পর্কে স্পষ্টভাবে চিন্তা করার জন্য ইউআরআই সংজ্ঞাটি ব্যবহার করে। এপিআই এন্ডপয়েন্টগুলি তাদের ডিবিটি কল্পনা করার এক অন্য উপায় ... এছাড়াও, কিছু ক্ষেত্রে, আপনি বর্ণিত হিসাবে এমন একটি উত্স তৈরি করা সত্য যে বস্তুগুলি সত্যই আলাদা, কারণ কেবল তাদের নামকরণ করা খুব অস্পষ্ট শর্তগুলির দিকে পরিচালিত করে।

— মিকেলডাব্লু

দক্ষতার কোণ থেকে ইস্যুটিতে ফিরে যেতে, তারা একমত হয়েছে যে কোনও মোবাইল স্ক্রিনটি যদি খুব ধীর হয় (এবং কেবল এটি ঘটে তবে) কিছু সংমিশ্রিত কল আসতে পারে তবে তারা এমন একটি অংশে বসে থাকবে যা এপিআইয়ের চারপাশে আবৃত থাকে ( কেবলমাত্র API টির পরিবর্তে) কেবলমাত্র মোবাইল ক্লায়েন্টরা ব্যবহার করবে এবং মূল ডোমেন, মূল API এর অংশ হিসাবে বিবেচিত হবে না।

— মিকেলডাব্লু

@ মিকায়েলডাব্লু, আপনি ঠিক বলেছেন এমনকি করম্যাক যা বলেছিল তা আদর্শ দৃশ্যাবলী, কিছু সময় আপনি এমন একটি এপিআই নিয়ে কাজ করছেন যা প্রচুর পরিমাণে অন্যান্য সিস্টেমে (ডেস্কটপ, মোবাইল, ওয়েব, নির্ধারিত কাজ, লিগ্যাসি সিস্টেম ইত্যাদি) উপস্থিতি প্রয়োজন। এই জাতীয় এপিআইকে সত্যিকারের নমনীয় হওয়া প্রয়োজন, সম্ভাব্য সংখ্যক সম্ভাব্যতায় উপস্থিত হওয়ার জন্য সংস্থান দেওয়া হয় তবে একজন গ্রাহকের কাছ থেকে সমস্ত নির্দিষ্ট কর্মক্ষমতা প্রয়োজনীয়তার সাথে উপস্থিত থাকতে পারে না।

— সেক্ষেত্রে