چگونه SQL می تواند دسترسی به API ها را یکسان کند

بسته‌بندی‌های داده خارجی PostgreSQL یک راه عالی برای افشای APIها در معرض SQL هستند. و SQL یک راه عالی برای استدلال بر روی داده ها است.

در پیشنهاد اصلی برای شبکه جهانی وب، تیم برنرز لی نوشت:

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

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

در سال ۲۰۰۹ من در حال ساختن سیستمی برای ترکیب اطلاعات تقویم از بسیاری از منابع بودم. این سؤال از همه آنها یکسان بود: چه رویدادهایی برای یک مکان و زمان معین برنامه ریزی شده است؟ برای انجام این کار باید از نیم دوجین API استفاده می‌کرد که هر کدام به روشی متفاوت برای درخواست و باز کردن پاسخ نیاز داشتند.

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

این ایده به عنوان Open Data، با نام OData، یک استاندارد OASIS از سال ۲۰۱۴. در اصل، هر برنامه وب مبتنی بر پایگاه داده اکنون می تواند یک “OData head” داشته باشد که یک API پیش فرض ارائه کند، بدون نیاز به کد توسط توسعه دهندگان برنامه نوشته شود و هیچ پروتکل درخواست/پاسخ جدیدی توسط توسعه دهندگانی که از API استفاده می کنند، یاد نگیرند.

در عمل اغلب این اتفاق نیفتاده است.

بیش از هر زمان دیگری، ساخت نرم افزار به توسعه دهندگان نیاز دارد تا راه حل هایی را با استفاده از گسترش روزافزون API ها ایجاد کنند. اغلب یک کتابخانه برای قرار دادن هر API در زبان برنامه نویسی انتخابی شما وجود دارد، بنابراین از تلاش برای برقراری تماس های REST خام و تجزیه نتایج دریغ می کنید. اما هر wrapper روش خاص خود را برای نمایش نتایج دارد، بنابراین هنگام نوشتن یک راه حل چند API باید آن نمایش ها را عادی کنید. از آنجایی که ترکیب نتایج به روشی خاص زبان اتفاق می افتد، راه حل شما به آن زبان گره خورده است. و اگر آن زبان جاوا اسکریپت یا پایتون یا جاوا یا سی شارپ باشد، مسلماً جهانی ترین و قدرتمندترین راه برای پرس و جو (یا به روز رسانی) پایگاه داده نیست.

بهترین راه چیست؟ همیشه در معرض دید پنهان بوده است: SQL. SQL که دهه‌ها در جنگ سخت شده بود، و تکامل فراتر از مدل رابطه‌ای خالص، خود را به عنوان رابط برجسته برای داده‌ها تثبیت کرده است. . و در موقعیتی قرار گرفته است که تبدیل به یکپارچه کننده API شود که بیش از هر زمان دیگری به آن نیاز داریم.

پوشه‌های داده خارجی برای APIها

Steampipe (steampipe.io) یک ابزار منبع باز است که داده ها را از API های مختلف واکشی می کند و از آن برای پر کردن جداول استفاده می کند. در یک پایگاه داده پایگاه داده Postgres است، که امروزه پلتفرمی است که بر روی آن می توان انواع سیستم های پایگاه داده مانند را با ایجاد برنامه های افزودنی که عمیقاً هسته را سفارشی می کند، ساخت. یک کلاس از پسوند Postgres، بسته بندی اطلاعات خارجی (FDW)، جداول را از داده های خارجی ایجاد می کند. Steampipe نمونه‌ای از Postgres را جاسازی می‌کند که یک پوشش داده خارجی مبتنی بر API را بارگیری می‌کند. FDW به نوبه خود با خانواده در حال رشد افزونه‌ها ارتباط برقرار می‌کند که APIها را مصرف می‌کنند و داده‌ها را از طریق FDW تغذیه می‌کنند. به جداول Postgres.

برای عینیت بخشیدن به این انتزاعات، از خود بپرسید که چگونه مشکل زیر را حل می کنید. شما سرویس‌های عمومی AWS را اجرا می‌کنید، و می‌خواهید بدانید که آیا هر یک از نقاط پایانی آن‌ها در Shodan، یک سرویس آسیب‌پذیر نشان داده می‌شود یا خیر. که نقاط پایانی عمومی را اسکن می کند. راه حل شما احتمالاً چیزی شبیه به این است:

1. با نحوه استفاده از AWS API که نقاط پایانی شما را پیدا می کند آشنا شوید
2. با نحوه استفاده از Shodan API برای بررسی نقاط پایانی شما آشنا شوید
3. با نحوه ترکیب این دو API برای پاسخ به سوال آشنا شوید

این راه حل Steampipe است.

```
select
  a.instance_id,
  s.ports,
  s.vulns,
  a.security_groups
from
  aws_ec2_instance a
left join
  shodan_host s on a.public_ip_address = s.ip
where
  a.public_ip_address is not null;
```
```
+---------------------+----------+--------------------+-------------------------------------------------------------+
| instance_id         | ports    | vulns              | security_groups                                             |
+---------------------+----------+--------------------+-------------------------------------------------------------+
| i-0dc60dd191cb84239 | <null>   | <null>             | [{"GroupId":"sg-042fe79169eb42818","GroupName":"lockdown"}] |
| i-042a51a815773780d | [80,22]  | <null>             | [{"GroupId":"sg-042042bac705630f4","GroupName":"bastion"}]  |
| i-00cf426db9b8a58b6 | [22]     | <null>             | [{"GroupId":"sg-0423f79169eb42818","GroupName":"default"}]  |
| i-0e97f373db42dfa3f | [22,111] | ["CVE-2018-15919"] | [{"GroupId":"sg-0423f79169eb42818","GroupName":"default"}]  |
+---------------------+----------+--------------------+-------------------------------------------------------------+
```

دو جدول به هم پیوسته در اینجا توسط پلاگین های Steampipe برای AWS و Shodan. اولین نقشه کاتالوگ گسترده APIهای AWS را به (در حال حاضر) ۲۶۹ جدول نشان می‌دهد. دومی دوجین جدول شدان را ارائه می دهد.

این افزونه‌ها را پیکربندی می‌کنید تا با همان اعتبارنامه‌هایی که در صورت استفاده مستقیم از APIها به آن نیاز دارید، در APIها احراز هویت شوند. اما لازم نیست چیز دیگری در مورد تماس های REST اساسی یا کتابخانه های پیچیده شده در اطراف آنها بدانید. این راه حل از جداولی ساخته شده است که در داخل و بین API ها به طور یکسان عمل می کنند. شما آنها را بررسی می کنید (aws_ec2_instance، shodan_host) تا نام ستون‌های آن‌ها را کشف کنید، و به آن‌ها در SQL قدیمی ملحق می‌شوید. راه.

یک افزونه برای هر API

واضح است که این راه حل دو API به وجود افزونه هایی برای نگاشت هر دو API به جداول بستگی دارد. اگر هر دو سرویس OData را پیاده سازی می کردند، لازم نبود. APIها به طور خودکار قابل پرس و جو خواهند بود، اگرچه مسلماً با ظرافتی که SQL ارائه می دهد قابل اتصال نیستند. اما این دو سرویس، مانند بسیاری از آنها، یک رابط یکپارچه برای API های خود ارائه نمی دهند. بنابراین این وحدت باید در بالای آنها قرار گیرد. افزونه SDK Steampipe با انتزاع مدیریت اتصال، راه را برای نویسندگان افزونه هموار می کند، دوباره امتحان کنید منطق، کش کردن، و البته نگاشت نتایج API به جداول.

افزونه های Steampipe در Go نوشته شده اند. آنها از کاتالوگ جامع کتابخانه های Go که API ها را بسته بندی می کنند، استفاده می کنند. اما فقط نویسندگان افزونه باید این را بدانند. به عنوان یک توسعه دهنده که با Steampipe کار می کند، فقط جداول را می بینید و فقط SQL می نویسید. امروزه، از آنجایی که SQL تکامل یافته است، شامل ویژگی هایی مانند عبارات جدول مشترک (معروف به CTE یا بندهای WITH) و ستون های JSON است. اما هنوز فقط SQL است.

آیا می توان چنین افزونه هایی را برای هر API ساخت؟ خب، Steampipe در اوایل سال ۲۰۲۱ با تعداد انگشت شماری پلاگین راه اندازی شد، امروزه بیش از ۶۰ مورد وجود دارد و تعداد آنها به سرعت در حال افزایش است. تاکنون بیشتر آنها توسط تیم اصلی نوشته شده است، اما مشارکت های خارجی در حال افزایش است. به لطف افزونه SDK، که کارهای سنگین را انجام می دهد، ساختن افزونه ای که یک API را به مجموعه ای از جداول نگاشت می کند، ساده است.

ایستاده روی شانه های Postgres

با جاسازی Postgres، Steampipe تمام قابلیت های آن را به ارث می برد. بنابراین، برای مثال، می توانید به جداول خارجی منبع API با جداول بومی Postgres بپیوندید. و در حالی که مزیت اصلی Steampipe جستجوی زنده از APIها است، می‌توانید برای تداوم آن داده‌ها، نماهای واقعی ایجاد کنید و توابع Postgres را برای کار بر روی آن بنویسید. حتی می‌توانید سایر برنامه‌های افزودنی Postgres را بارگیری کنید و از آنها با جداول Steampipe استفاده کنید. برای مثال، پسوند tablefunc داخلی Postgres، می‌تواند crosstabs را در SQL انجام دهد، با داده های صفحه گسترده از افزونه Google Sheets Steampipe.

یکی دیگر از مزایای جاسازی Postgres: هر سرویس گیرنده API سازگار با Postgres می تواند به Steampipe متصل شود. این شامل ابزارهای خط فرمان مانند psql و ابزارهای مبتنی بر رابط کاربری گرافیکی مانند Tableau، Power BI، Metabase و Superset است که تجسم و تعامل را به داده‌های API زنده می‌آورند.

Postgres ممکن است هرگز به اندازه SQLite فراگیر تعبیه نشده باشد، اما توانایی بیشتری دارد و به طور فزاینده ای برای تقویت اکوسیستمی از ابزارهای قابل همکاری برای کار با داده ها استفاده می شود. Steampipe Postgres را گسترش می‌دهد تا دسترسی یکپارچه به APIها و یک محیط SQL مشترک را ارائه دهد تا در آن درباره داده‌هایی که ارائه می‌کنند استدلال کنید.