🎯 هدف

در این راهنما، من شما را با Postman، یک ابزار محبوب توسعه و تست API آشنا می کنم.

اگر مبتدی هستید که عمدتاً روی توسعه frontend متمرکز شده‌اید، ممکن است تجربه زیادی در واکشی داده‌ها از یک API نداشته باشید. و در این صورت احتمالاً با موقعیت‌های زیادی مواجه نشده‌اید که در طول فرآیند توسعه‌تان نیاز به درخواست‌های متعدد به یک API برای اهداف آزمایشی داشته باشید.

اما درک نحوه آزمایش APIها و ارتباط با آنها از طریق Postman یا ابزارهای مشابه در مقطعی از حرفه شما مهم خواهد شد. اگر تصمیم دارید در توسعه باطن سرمایه گذاری کنید، درک این مفاهیم ضروری است.

پس از پوشش برخی از اطلاعات اولیه درباره Postman و مستندات Spotify API، به آپشن های کلیدی Postman می‌پردازیم. سپس، یک نقطه پایانی Spotify را انتخاب می‌کنیم و روند درخواست‌ها را طی می‌کنیم.

🔐 در اینجا چیزی است که ما پوشش خواهیم داد

دانش اساسی کار با پستچی را به دست خواهید آورد.

شما توانایی خود را برای کار با APIها و مستندات آنها تقویت خواهید کرد.

شما اصول اولیه Spotify API عمومی را تحلیل خواهید کرد.

📝 پیش نیازها

شما باید درک اولیه ای از API ها داشته باشید.

شما نیازی به دانش قبلی در مورد پستچی ندارید.

فهرست مطالب

کاوش Spotify API با Postman

تجربه پستچی

چگونه اولین درخواست خود را به Spotify API ارسال کنید

مجوز Spotify API

محدوده مجوز API Spotify

خلاصه

کاوش Spotify API با Postman

برای اینکه نگاهی اجمالی به پستچی داشته باشیم، به توضیح زیر از ChatGPT مراجعه می کنیم:

"Postman یک ابزار محبوب توسعه و آزمایش API (Application Programming Interface) است که کار با API ها را با ارائه یک رابط کاربری آسان برای ارسال درخواست های HTTP و دریافت پاسخ ها ساده می کند. این ابزار به طور گسترده توسط توسعه دهندگان، مهندسان QA و تیم هایی که کار می کنند استفاده می شود. با API ها برای اطمینان از عملکرد صحیح و کارآمد آنها."

در حالی که ما بر روی ایجاد درخواست های HTTP تمرکز خواهیم کرد، توجه به این نکته مهم است که Postman نیز همه کاره است و می توان از آن برای کار با GraphQL، gRPC، WebSocket، Socket.IO و MQTT استفاده کرد.

با در دست داشتن Postman، برای آزمایش به یک نقطه پایانی API نیاز داریم. برای این کار، از Spotify API عمومی استفاده خواهیم کرد که نقاط پایانی مختلفی را برای موارد استفاده مختلف ارائه می‌کند. اگر مبتدی هستید که به دنبال یک پروژه سرگرم کننده برای اکتشاف هستید، این حتی می تواند یک فرصت هیجان انگیز برای پروژه بعدی شما باشد.

Spotify Web API به صورت حرفه ای طراحی شده است و تمام اطلاعات لازم را برای توسعه دهندگان ارائه می دهد. با بخش‌های «نمای کلی» و «شروع به کار»، پیگیری آن‌ها حتی برای مبتدیان ساده است.

در حین یادگیری اصول Postman، بخش‌های کلیدی مستندات Spotify API را که برای تست موفقیت‌آمیز API ضروری است، تحلیل می‌کنیم. به عنوان مثال، نحوه ایجاد یک درخواست HTTP به نقطه پایانی برای بازیابی داده ها از یک فهرست پخش را نشان خواهیم داد.

اما ابتدا اجازه دهید برخی از اصول پستچی را پوشش دهیم.

تجربه پستچی

می توانید از Postman به روش های مختلف استفاده کنید. در مورد من، من از نسخه دسکتاپ Postman استفاده می کنم.

اما می‌توانید مستقیماً از Postman در مرورگر خود یا حتی از طریق Postman CLI (واسط خط فرمان) استفاده کنید. همچنین یک پسوند رسمی Postman برای VS Code وجود دارد. شما می توانید این نسخه ها را از طریق پیوندی که من به اشتراک گذاشتم پیدا کنید.

اگر با Postman کاملاً تازه کار هستید، ممکن است بخواهید با نسخه وب یا نسخه دسکتاپ قابل دانلود شروع کنید، به خصوص اگر قصد دارید در آینده به طور منظم از Postman استفاده کنید.

پس از راه اندازی نسخه دسکتاپ Postman، اولین چیزی که می بینید این است:

این ممکن است کمی متفاوت از آنچه در ابتدا می بینید به نظر برسد. من قبلا یک حساب کاربری دارم. ممکن است لازم باشد ابتدا به صورت رایگان یکی بسازید. همچنین ممکن است لازم باشد ابتدا یک فضای کاری ایجاد کنید. در مورد من، من قبلاً در فضای کاری "My Workspace" هستم.

در گوشه سمت چپ بالا، چندین تب، از جمله "Collections"، "Environments"، "History" و یک نماد برای پیکربندی این نوار کناری را خواهید دید.

در حال حاضر، ما در برگه "Collections" می مانیم و روی "Create Collection" کلیک می کنیم:

پس از کلیک بر روی آن، تمرکز شما به نام مجموعه در مرکز بالا تغییر می کند. با تایپ کردن، می توانید نام مجموعه خود را از "مجموعه جدید" به چیزی مناسب تر برای مورد استفاده خاص خود تغییر دهید.

برای این مورد، نام مجموعه را "Spotify API" گذاشتم:

اکنون، ما یک مجموعه داریم، اما این دقیقا چیست؟ یک مجموعه اساساً فضایی برای سازماندهی ساختارهای درخواستی متعدد است. وقتی اولین درخواست HTTP خود را اضافه کنیم، این موضوع واضح تر می شود. می توانید این کار را با کلیک کردن بر روی متن آبی رنگ که می گوید "Add a request" انجام دهید:

وقتی این کار را انجام می دهید، تمرکز شما دوباره روی نام عنصر خواهد بود. اگر اکنون چیزی را تایپ کنید، می توانید نام درخواست را از "درخواست جدید" به چیزی مناسب تر برای موقعیت تغییر دهید. در این مورد، از آنجایی که هنوز مطمئن نیستم کدام درخواست را می‌خواهم ایجاد کنم، فعلاً آن را "تست" می‌نامم.

اگر می‌خواهید در این مرحله درخواست دیگری ایجاد کنید، می‌توانید روی سه نقطه سمت راست نام مجموعه کلیک کنید (گزینه ششم):

چندین گزینه وجود دارد که می توانید یکی از آنها را انتخاب کنید که " گفت ن درخواست" یکی از آنه است.

در این مرحله، ما یک مجموعه در فضای کاری خود ایجاد کرده ایم و در داخل آن مجموعه، یک درخواست HTTP اضافه کرده ایم. شما می توانید چندین مجموعه داشته باشید که هر کدام شامل چندین درخواست است. این به سازماندهی درخواست‌های شما کمک می‌کند، به‌ویژه زمانی که به نقطه‌ای می‌رسید که داشتن یک فهرست بزرگ از درخواست‌های از پیش پیکربندی‌شده برای مدیریت دشوار می‌شود.

در درخواست HTTP جدید ایجاد شده، می‌توانیم برخی جزئیات را مشاهده کنیم:

اولین چیزی که ممکن است متوجه شوید روش درخواست HTTP است که به طور پیش فرض روی "GET" تنظیم شده است. اگر با فلش رو به پایین بر روی "GET" کلیک کنید، می توانید از روش های مختلف انتخاب کنید یا حتی در صورت نیاز روش خود را تایپ کنید.

در سمت راست آن، یک فیلد متنی وجود دارد که در آن URL API خود را به همراه نقطه پایانی آن وارد خواهید کرد (به زودی این کار را امتحان خواهیم کرد).

در زیر چندین برگه مهم وجود دارد. در حال حاضر، ما در برگه "Params" هستیم. در اینجا، می‌توانید جفت‌های کلید-مقدار اضافه کنید که مستقیماً درخواستی را که می‌کنید تغییر می‌دهند. اینها Query Params نامیده می شوند که ممکن است قبلاً با آنها برخورد کرده باشید. به عنوان مثال، اگر URL شما https://google.com است، گفت ن یک جفت کلید-مقدار به عنوان Query Param ممکن است به شکل زیر باشد:

به درخواست HTTP در Postman" class="image--center mx-auto" width="1487" height="286" loading="lazy">

در مورد Query Params، اینکه آیا شما به آن‌ها نیاز دارید بستگی به درخواستی دارد که می‌کنید. یک مورد استفاده رایج صفحه بندی در یک وب سایت با جدول است. برای مثال، ممکن است از یک پارامتر پرس و جو مانند "page=4" استفاده کنید تا مشخص کنید کدام صفحه از نتایج را می خواهید.

سپس برگه "Authorization" است که احراز هویت و مجوز درخواست شما را انجام می دهد. ما بعداً به این موضوع خواهیم پرداخت، پس فعلاً از آن صرف نظر خواهیم کرد.

سپس، ما برگه "Headers" را داریم، که بسیار مهم است زیرا حاوی تمام اطلاعات موجود در سرصفحه درخواست شما است، مانند هر داده مجوز در صورت تنظیم.

در نهایت، تب "Body" که در سمت راست قرار دارد نیز بسیار مهم است. به عنوان مثال، اگر درخواست POST برای گفت ن یک آیتم به پایگاه داده دارید، احتمالاً باید اطلاعاتی مانند نام یا دسته مورد را ارسال کنید. این نوع داده ها اغلب در فرمت JSON در بدنه درخواست گنجانده می شوند.

برای گفت ن داده‌های با فرمت JSON، می‌توانید روی «raw» در برگه «Body» کلیک کنید و سپس قالب مورد نظر خود را انتخاب کنید (که «JSON» گزینه پیش‌فرض است):

همانند Query Params، قالب و داده های مورد نیاز به شدت به API و نقطه پایانی که استفاده می کنید بستگی دارد. فقط به خاطر داشته باشید که می توانید تمام گزینه های لازم را در این تب ها پیکربندی کنید.

دو برگه باقیمانده «اسکریپت‌ها» و «تنظیمات» هستند. در تب "اسکریپت ها" می توانید کد سفارشی اضافه کنید، اما این پیشرفته تر است و برای وضعیت فعلی ما ضروری نیست. تب "تنظیمات" امکان تنظیمات را فراهم می کند، اگرچه در بیشتر موارد، نیازی به تغییر چیزی در اینجا نخواهید داشت.

چگونه اولین درخواست خود را به Spotify API ارسال کنید

اکنون، اولین درخواست واقعی خود را با استفاده از Postman ارائه خواهیم کرد. برای این کار، می‌توانیم به مستندات توسعه‌دهنده Spotify API، جایی که تمام نقاط پایانی فهرست شده‌اند، شیرجه بزنیم. برای اولین آزمایش، داده‌های مربوط به فهرست پخش را واکشی می‌کنیم.

در این توضیحات، اطلاعات مفیدی از جمله نقطه پایانی و داده های مورد نیاز برای یک پاسخ موفقیت آمیز را خواهید یافت. همچنین می توانید پس از ورود به حساب کاربری Spotify خود، درخواست را مستقیماً از صفحه ارسال کنید:

چنین اسناد API گسترده ای فوق العاده مفید است و کار با آن را به خصوص برای مبتدیان آسان می کند. با این حال، به خاطر داشته باشید که تمام اسناد API به این اندازه کامل نیستند.

در این مورد، می‌توانیم ببینیم که نقطه پایانی https://api.spotify.com/v1/playlists/{playlist_id} است و playlist_id تنها پارامتر مورد نیاز در براکت‌های فرفری است. همچنین پارامترهای اختیاری مانند market ، fields ، و additional_types را خواهید دید که می توانند به اصلاح پاسخ کمک کنند. اما باز هم، اینها اختیاری هستند و شما فقط به playlist_id برای درخواست اولیه نیاز دارید.

اگر می‌خواهید اطلاعات اختیاری مانند market را درج کنید، از پارامترهای Query که قبلاً ذکر شد استفاده کنید. به عنوان مثال، گفت ن ES به عنوان بازار در کنار playlist_id ، URL را به https://api.spotify.com/v1/playlists/3cEYpjA9oz9GiPac4AsH4n?market=ES تغییر می دهد.

برای ایجاد درخواست اولیه در Postman (بدون هیچ پارامتر اختیاری)، به درخواست "تست" خود برمی گردیم و URL را با نقطه پایانی مربوطه وارد می کنیم:

این روش جواب می دهد، اما من روش دیگری را توصیه می کنم.

از آنجایی که مجموعه Spotify API خود را داریم و ممکن است بخواهیم چندین درخواست به آن مجموعه اضافه کنیم، استفاده از متغیرها برای بخش‌هایی از URL یا اطلاعاتی که در چندین درخواست ثابت باقی می‌مانند، تمرین خوبی است. در این صورت، URL پایه، https://api.spotify.com/v1/ ، برای همه درخواست‌های Spotify API یکسان می‌ماند. به جای اینکه به صورت دستی آن را به هر درخواست اضافه کنیم، می توانیم یک متغیر برای آن ایجاد کنیم.

برای انجام این کار، به تب "محیط ها" در گوشه سمت چپ بالا تغییر می کنیم. از آنجا روی نماد مثبت کلیک کنید تا یک محیط جدید ایجاد کنید:

نام محیط را Spotify API می گذاریم.

در مرحله بعد، متغیرهایی مانند base_url را ایجاد می کنیم و مقدار مناسب را به آن اختصاص می دهیم. همچنین می توانید بین گزینه های نوع انتخاب کنید: default یا secret . از آنجایی که این داده حساس نیست، می‌تواند روی default تنظیم شود. اگر secret انتخاب کنید، باید هر بار روی نماد چشم کلیک کنید تا مقدار متغیر نمایان شود، در غیر این صورت، مانند نحوه نمایش رمزهای عبور، با •••• پوشانده می شود.

این چیزی است که تا اینجا به نظر می رسد:

در مرحله بعد، ما به مجموعه Spotify API باز می گردیم و به گوشه سمت راست بالا نگاه می کنیم، جایی که در حال حاضر عبارت "بدون محیط" است. روی آنجا کلیک کنید و محیط «Spotify API» را که به تازگی ایجاد کردیم انتخاب کنید:

اکنون می‌توانیم از متغیرهای آن محیط برای تمام درخواست‌های مجموعه «Spotify API» استفاده کنیم. برای درج یک متغیر، از دو براکت مربع استفاده می کنید، مانند این:

اگر پیامی دریافت کردید که متغیر پیدا نشد، مطمئن شوید که محیط "Spotify API" را ذخیره کرده اید. نقطه‌های سمت راست نام برگه‌ها نشان می‌دهند که برای مثال می‌توانید با فشار دادن CTRL + S اطلاعات جدید را ذخیره کنید. این مرحله برای شناسایی متغیر ایجاد شده ضروری است.

با وجود متغیر، اکنون می توانید فقط این یک متغیر را تغییر دهید تا base_url برای همه درخواست های مربوطه خود تغییر دهید. اگرچه این ممکن است فوراً برای base_url مفید به نظر نرسد، زیرا احتمالاً به این زودی تغییر نخواهد کرد، متغیرها می توانند در سناریوهای دیگر بسیار مفید باشند. این فرصتی بود تا شما را با نحوه کار آنها آشنا کنم.

در مرحله بعد، من درخواست HTTP را از "test" به چیزی توصیفی تر، مانند "Playlist" تغییر نام می دهم تا نشان دهم این درخواست در مورد چیست. همراه با روش "GET" مشخص خواهد شد که این درخواست برای واکشی داده های فهرست پخش است.

اکنون که همه چیز تنظیم شده است، اجازه دهید هنگام مشاهده درخواست HTTP، با کلیک بر روی دکمه "ارسال" در سمت راست، درخواست را ارسال کنیم. پاسخ را در نیمه پایین صفحه خواهید دید:

چه بد، درخواست موفقیت آمیز نبود!

این اتفاق افتاد زیرا ما هیچ مجوزی ارائه نکردیم. به همین دلیل خطای 401 Unauthorized را با پیغام No Token ارائه شده دریافت کردیم.

از آنجایی که این یک نقطه پایانی محافظت شده است، ما به یک نشانه دسترسی نیاز داریم که با ورود به Spotify آن را دریافت خواهید کرد. اگر قبلاً سعی کرده‌اید درخواستی را در وب‌سایت اسناد Spotify API ارسال کنید، احتمالاً متوجه شده‌اید که قبل از ارسال درخواست از شما خواسته است که وارد شوید. با انجام این کار، رمز دسترسی جلسه شما را به دست آورد، که دقیقاً همان چیزی است که ما در موقعیت خود نیز به آن نیاز داریم.

با این حال، به جای ورود با نام کاربری و رمز عبور خود، از روش دیگری برای مجوز استفاده خواهیم کرد.

مجوز Spotify API

برای درخواست های اولیه به Spotify API، به یک نشانه دسترسی نیاز دارید که می تواند با استفاده از اعتبار شما ایجاد شود. این یک رویکرد رایج در بسیاری از APIها است، که در آن قبل از اینکه بتوانید به نقاط پایانی مورد نظر خود دسترسی پیدا کنید، باید یک نشانه دسترسی به دست آورید.

Spotify Developer API راهنمای گام به گام نحوه دریافت توکن دسترسی شما را ارائه می دهد.

با پیروی از مراحل ذکر شده، اولین کار ایجاد یک نمایه برنامه است که می توانید آن را فقط در چند ثانیه انجام دهید، مخصوصا برای یک پروژه آزمایشی:

پس از انجام این مرحله، می توانیم با کلیک بر روی پروژه "تست" به "تنظیمات" پروژه بروید. در اینجا، "شناسه مشتری" و "محرمانه مشتری" را خواهید یافت:

به خاطر داشته باشید که این اطلاعات عموماً حساس تلقی می شوند، پس باید از اشتراک گذاری آن به صورت عمومی (در بیشتر موارد) خودداری کنید. اما از آنجایی که این فقط یک پروژه آزمایشی است که تا زمان انتشار این راهنما حذف خواهد شد، من آن را نشان می‌دهم تا همراه با توضیحاتم، راحت‌تر دنبال کنید.

با در دست داشتن شناسه مشتری و راز مشتری، اکنون اطلاعات لازم برای درخواست رمز دسترسی را دارید. این نشانه‌های دسترسی برای اجازه دادن به خودتان هنگام تعامل با نقاط پایانی API استفاده می‌شوند.

می‌توانید این را با ورود به نرم‌افزار مقایسه کنید، جایی که باید قبل از دسترسی به اطلاعات خاص، خود را احراز هویت کنید. در چنین مواردی، این احتمال وجود دارد که یک نشانه دسترسی برای مدت زمان جلسه شما ایجاد شود تا درخواست های شما را به API پشتیبان نرم افزار تأیید کند.

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

مستندات Spotify API بسیار مفید است و دستورالعمل های دقیقی را در مورد درخواست دقیقی که باید انجام دهید ارائه می دهد. اکنون برای این مرحله وارد پستمن می شویم.

به مجموعه "Spotify API" خود بروید و روی تب "Authorization" کلیک کنید. در اینجا، باید «نوع تأیید» مناسب را انتخاب کنید. چندین گزینه وجود دارد، و روش مجوز ممکن است بسته به API مورد استفاده شما متفاوت باشد.

اگر از قبل یک نشانه دسترسی دارید، می‌توانید نوع تأییدیه «Token حامل» را انتخاب کنید، جایی که به سادگی رمز را مستقیماً جای‌گذاری می‌کنید. این نوع مجوزی است که در پایان از آن استفاده خواهیم کرد. اما به جای درخواست دستی یک رمز و سپس وارد کردن آن در قسمت "Bearer Token"، می‌توانیم این فرآیند را خودکار کنیم. برای این کار، « OAuth 2.0 » را به عنوان نوع تأیید انتخاب می کنیم.

چگونه متوجه شدم که "OAuth 2.0" انتخاب درستی است؟ اگر اسناد Spotify API را تحلیل کنید، در حالی که راهنمای گام به گام آنها را مرور می کنید، اطلاعات مربوطه را پیدا خواهید کرد. همچنین، تمام نقاط پایانی که نیاز به مجوز دارند با "OAuth 2.0" برچسب گذاری می شوند، از جمله نقطه پایانی " دریافت فهرست پخش ":

در اسناد همچنین اشاره شده است که Spotify برای آموزش خود از "Client Credentials" استفاده می کند. این "نوع کمک هزینه" است و نشان دهنده اطلاعاتی است که شما برای درخواست مجوز ارائه می کنید. با "Client Credentials"، شناسه مشتری و راز مشتری (اطلاعات برنامه آزمایشی ما) را پاس می کنید.

به عنوان مثال، با نوع اعطای "معتبر رمز عبور"، یک "نام کاربری" و "گذرواژه" را نیز ارسال می کنید، که هنگام ورود با یک حساب کاربری واقعی استفاده می شود.

روش‌های مجوز دیگری نیز وجود دارد، و اسناد API معمولاً مشخص می‌کند که از کدام رویکرد استفاده شود. در مورد ما، از آنجایی که ما شناسه مشتری و Client Secret را داریم و به دسترسی کاربر خاصی نیاز نداریم، می دانیم که نوع اعطای "Client Credentials" انتخاب مناسبی است.

هنگام ارسال Client ID و Client Secret در Postman، ممکن است پیشنهادی برای استفاده از متغیرها برای این اطلاعات دریافت کنید:

مشابه متغیر base_url که قبلا استفاده کردیم، ایجاد متغیرهایی برای Client ID و Client Secret می تواند مفید باشد، به خصوص اگر قصد دارید از چندین درخواست HTTP با مجوزهای مشابه استفاده کنید. به این ترتیب می توانید در تمام درخواست های خود به متغیرهای یکسانی ارجاع دهید و اگر چیزی تغییر کرد، فقط باید متغیر را در یک مکان به روز کنید.

در این مورد، همین کار را با جابجایی به برگه «محیط‌ها» و گفت ن متغیرهایی برای client_id و client_secret انجام خواهیم داد.

گفت ن متغیرهای محیطی برای Client ID و Client Secret" class="image--center mx-auto" width="1581" height="282" loading="lazy">

در مرحله بعد، شما آن متغیرها را در فرآیند مجوزدهی که قبلا شروع کرده بودیم وارد می‌کنید:

اکنون، فقط باید URL مجوز رمز را اضافه کنیم که می‌توانید آن را در همان صفحه قبلی پیدا کنید: https://accounts.spotify.com/api/token . این را در قسمت "Access Token URL" وارد کنید. سپس، نام مناسب مورد نظر خود را به تنظیمات بدهید و به پایین بروید تا روی دکمه «دریافت رمز دسترسی جدید» کلیک کنید:

موفق بود! اکنون، برای مشاهده جزئیات بیشتر در مورد توکن دسترسی تولید شده، روی "ادامه" کلیک کنید:

در حالی که نشانه دسترسی ما آماده است، روی "Use Token" در سمت راست بالا کلیک کنید، و Postman تایید می کند که توکن اضافه شده است.

اکنون، اگر به درخواست GET «فهرست پخش» که قبلاً ایجاد کرده‌ایم برویم، گزینه تنظیم یک روش مجوز برای این درخواست خاص را خواهید دید. اما از آنجایی که ما قبلاً مجوز را برای کل مجموعه تنظیم کرده‌ایم، کافی است «وارث تأیید اعتبار از والدین» را به عنوان «نوع تأیید» برای این درخواست انتخاب کنید:

پستچی نشان می دهد که کدام نوع مجوز استفاده می شود و از کجا آمده است. در این مورد، می گوید: "درخواست از OAuth 2.0 از مجموعه Spotify API استفاده می کند."

در مرحله بعد، اگر به تب "Headers" بروید و روی "8 hidden" کلیک کنید، می توانیم یک کلید "Authorization" را مشاهده کنیم. با کلیک بر روی علامت چشم در سمت راست، می توانیم این اطلاعات را آشکار کنیم.

اگر این را با توکن دسترسی که ما به تازگی تولید کرده‌ایم مقایسه کنید، متوجه می‌شوید که آنها یکسان هستند (با علامت "حامل" در مقابل نشانه دسترسی واقعی). هنگامی که یک توکن جدید برای مجموعه ایجاد می کنید، همانطور که قبلا انجام دادیم، این اطلاعات به طور خودکار به روز می شوند.

با تنظیم همه چیز، اکنون آماده ارسال درخواستی هستیم که قبلاً امتحان کرده بودیم، این بار با یک نشانه دسترسی معتبر در هدر "Authorization".

و اگر اکنون "ارسال" را بزنید، پاسخی مانند این دریافت خواهیم کرد:

پاسخ یک شی JSON است که حاوی اطلاعات زیادی برای کاوش است. شما می توانید این کار را برای فهرست پخش خود نیز انجام دهید، البته تا زمانی که در Spotify به صورت عمومی تنظیم شده باشد.

برای مثال دیگر، من به Spotify می روم، از گزینه "اشتراک گذاری" برای فهرست پخش خود استفاده می کنم و لینک فهرست پخش را کپی می کنم، که به شکل زیر است: https://open.spotify.com/playlist/1OPgvkPckzXm9SB0CIJf3o?si=cbe9c361f8024abd .

بخشی که ما به آن علاقه مندیم شناسه فهرست پخش است که بعد از آخرین اسلش رو به جلو و قبل از علامت سوال پیدا می شود - در این مورد، 1OPgvkPckzXm9SB0CIJf3o . شناسه فهرست پخش فعلی را با این شناسه در Postman جایگزین می‌کنیم:

اکنون، اگر "ارسال" را بزنید، پاسخ JSON مربوطه را دریافت خواهیم کرد:

این پاسخ همچنین یک شی بزرگ JSON با داده های زیادی برای کاوش است.

و بس! ما با موفقیت یک راه‌اندازی اساسی Postman را با درخواست HTTP GET، از جمله مجوز، برای واکشی داده‌ها از Spotify API پیکربندی کردیم.

محدوده مجوز Spotify API

در حال حاضر، ما با موفقیت از مجوز با شناسه مشتری و راز مشتری استفاده کرده‌ایم. اما اگر عمیق‌تر در اسناد Spotify API غوطه‌ور شوید، موقعیت‌هایی را خواهید دید که این روش مجوز برای برخی اقدامات کافی نیست.

در حالی که واکشی داده‌های فهرست پخش و سایر درخواست‌های GET با شناسه مشتری و مجوز Client Secret کار می‌کند، ممکن است با نقاط پایانی مواجه شوید که از روش‌های POST، PUT یا DELETE استفاده می‌کنند.

برای مثال، گفت ن آهنگ‌های جدید به فهرست پخش به چیزی بیش از شناسه مشتری و مجوز Client Secret نیاز دارد. شما باید به عنوان کاربر واقعی مرتبط با فهرست پخش احراز هویت کنید.

در چنین مواردی، اسناد "محدوده های مجوز" را فهرست می کند که مجوزهای مورد نیاز را تعریف می کند. به‌عنوان مثال، دامنه‌های «playlist-modify-public» و «playlist-modify-private» به ترتیب برای اصلاح فهرست‌های پخش عمومی و خصوصی مورد نیاز است:

گفت ن موارد به فهرست پخش" در Spotify API" class="image--center mx-auto" width="405" height="235" loading="lazy">

اگر مستندات Spotify API را مرور کنید، خواهید دید که چهار روش اصلی مجوز را مشخص می کند:

کد مجوز

کد مجوز با پسوند PKCE

اعتبار مشتری

کمک ضمنی

روش Client credentials (که ما از آن استفاده کردیم) دسترسی به داده های خاص کاربر را فراهم نمی کند. برای انجام اقداماتی از طرف یک کاربر، مانند اصلاح فهرست پخش آنها، روش "کد مجوز" مورد نیاز است.

در پروژه‌های دنیای واقعی، معمولاً وقتی کاربران وارد سیستم می‌شوند، این را به عنوان بخشی از فرآیند احراز هویت و مجوز برنامه خود اجرا می‌کنید. به عنوان مثال، در پروژه‌های Next.js، NextAuth مکانیزم ورود به Spotify را ارائه می‌کند که این فرآیند را ساده می‌کند.

از طرف دیگر، می توانید به صورت دستی درخواست های لازم را در طول فرآیند احراز هویت رسیدگی کنید و داده های مربوطه را به اطلاعات جلسه اضافه کنید.

این موضوع فراتر از محدوده این راهنما است، زیرا به جای موارد استفاده خاص Postman، به جریان‌های مجوز عمومی و احراز هویت برای Spotify API (و سایر APIها) می‌پردازد. اما اگر علاقه مند به کاوش در تست های پیشرفته تر با Postman هستید، اسناد Spotify API منابع ارزشمندی را فراهم می کند. آنها همچنین راهنمای نحوه بازیابی اطلاعات نمایه کاربر و نمایش آن در برنامه frontend شما را ارائه می دهند.

خلاصه

در این راهنما، ما اصول Postman را پوشش دادیم: نحوه راه‌اندازی اولین فضای کاری خود با یک مجموعه، ایجاد یک درخواست HTTP، استفاده از متغیرها برای ساده‌سازی فرآیند درخواست‌های آینده، و اضافه کردن منطق مجوز برای به دست آوردن یک نشانه دسترسی مورد نیاز برای درخواست‌ها. . همه اینها با استفاده از Spotify API نشان داده شده است که اسناد گسترده ای در مورد دسترسی به نقاط پایانی آن ارائه می دهد.

از اینجا، ممکن است بخواهید با یادگیری نحوه دسترسی به نقاط پایانی Spotify API که به اطلاعات دسترسی خاص کاربر، همراه با حوزه‌های خاص، مانند گفت ن آهنگ‌های جدید به فهرست پخش Spotify، نیاز دارند، عمیق‌تر کاوش کنید.

خبرکاو