اعمال محدودیت برای خروجی API

shape
shape
shape
shape
shape
shape
shape
shape

اعمال محدودیت (limit) بر روی فیلد های خروجی API

در این مقاله قصد داریم در مورد اعمال محدودیت برای خروجی API توضیح دهیم.

همان طور که گفته شد برای آن که کاربران بتوانند به یک یا چند منبع دسترسی پیدا نمایند باید در خواستی را با متد GET به سرویسشما ارسال نمایند. در پاسخ به درخواست آن ها دو رویکرد وجود دارد. یکی آن که همیشه کل فیلد های منبع یا منابع را باز گردانید و یا آنکه آنچه را که مورد نیاز کاربر است در اختیار وی قرار دهید. باید گفت کسانی که از API شما استفاده می کنند در بسیاری از مواقع فقط به بخشی از منبع نیاز دارند. بنابراین بهتر است راهکاری را در اختیار آنها قرار دهید تا بتوانند به API شما فیلد های مورد نیازشان را اعلام کنند. به این ترتیب هم API شما بهینه تر عمل می کند و هم آنکه اطلاعات اضافی و غیر ضروری در اختیار کاربران قرار نمی گیرد. علاوه بر این در پهنای باند شبکه صرفه جویی شده و پاسخ به کاربر با سرعت بیشتری می رسد.

برای این منظور پیشنهاد می شود همانند آنچه در مورد search گفتیم عمل شود. مثلا پارامتری با نام fields در URL در نظر بگیرید و به کاربر این امکان را دهید تا فیلد های مورد نیازش را بصورت comma separated به API اعلام نماید. در زیر نمونه ای از این نحوه کار آورده شده است :

استفاده از نام های مستعار برای برخی از پرس و جو های رایج
برخی از پرس و جو ها ممکن است بسیار رایج و مورد استفاده باشند. بد نیست برای راحتی کار استفاده کنندگان API های خود این پرس و جو ها را در قالب URL های خاصی در اختیار آنها قرار دهید. به عنوان مثال گرفتن آخرین لیست آخرین محصولات را می توانید در قالب یک مسیر مجزا مثلا GET /products/recently_added در اختیار کاربران قرار دهید.

اعمال محدودیت (limit) بر روی فیلد های خروجی API
همان طور که گفته شد برای آن که کاربران بتوانند به یک یا چند منبع دسترسی پیدا نمایند باید در خواستی را با متد GET به سرویسشما ارسال نمایند. در پاسخ به درخواست آن ها دو رویکرد وجود دارد. یکی آن که همیشه کل فیلد های منبع یا منابع را باز گردانید و یا آنکه آنچه را که مورد نیاز کاربر است در اختیار وی قرار دهید. باید گفت کسانی که از API شما استفاده می کنند در بسیاری از مواقع فقط به بخشی از منبع نیاز دارند. بنابراین بهتر است راهکاری را در اختیار آنها قرار دهید تا بتوانند به API شما فیلد های مورد نیازشان را اعلام کنند. به این ترتیب هم API شما بهینه تر عمل می کند و هم آنکه اطلاعات اضافی و غیر ضروری در اختیار کاربران قرار نمی گیرد. علاوه بر این در پهنای باند شبکه صرفه جویی شده و پاسخ به کاربر با سرعت بیشتری می رسد.

برای این منظور پیشنهاد می شود همانند آنچه در مورد search گفتیم عمل شود. مثلا پارامتری با نام fields در URL در نظر بگیرید و به کاربر این امکان را دهید تا فیلد های مورد نیازش را بصورت comma separated به API اعلام نماید. در زیر نمونه ای از این نحوه کار آورده شده است :پس از انجام عملیات درج و بروزرسانی منبع را نیز بازگردانید
همانطور که گفتیم فراخوانی های PUT، POST و PATCH برای اعمال تغییرات بر روی منابع استفاده میشوند. از آنجایی که در بسیاری از مواقع برنامه نویسان پس از اعمال اینگونه تغییرات، می خواهند منبع تغییر یافته یا ایجاد شده را نمایش دهند و یا از آن استفاده نمایند، پیشنهاد می شود برای جلوگیری از فراخوانی مجدد جهت دریافت منبع ، منبع تغییر یافته در پاسخ بازگردانده شود تا برای استفاده های آتی در اختیار برنامه نویسان قرار گیرد.

در مورد POST دقت کنید که بهتر است در پاسخ علاوه بر خود منبع، کد HTTP 201 (کد HTTP 201 به معنی دریافت موفقیت آمیز درخواست و ساخته شدن یک منبع جدید در سرور است (به فرض ایجاد یک فایل یا صفحه جدید)، ارسال کد ۲۰۱ تنها در صورتی صحیح است که سرور منبع جدید را ساخته باشد، در غیر اینصورت (اگر منبع هنوز ساخته نشده باشد) باید کد ۲۰۲ را ارسال کند.) را بازگردانید. علاوه بر آن هدر مربوط به Location را نیز با آدرس مربوط به منبع جدید مقدار دهی نمایید.

منبع

پاسخی بگذارید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *