در حالی که CRUD درک اساسی از افعال HTTP ارائه می دهد، طراحی ReST API را بیش از حد ساده می کند. بسیاری استدلال می کنند که ReST فقط CRUD بر روی HTTP است، با:
- ارسال کنید مربوط به خلقت است،
- دریافت کنید برای بازیابی،
- قرار دادن به روز رسانی، و
- حذف کنید به حذف
در حالی که این قیاس معقول به نظر می رسد و برای اکثر مردم کار می کند، اگر چیز بیشتری برای آن وجود دارد، ارزش آن را دارد. Shoehorning A به CRUD به عمق طراحی سیستم هایی که واقعاً در خدمت اهداف کاربر هستند، چشم پوشی می کند.
در قسمت اول این مجموعه ReST، یک ایده کلیدی را معرفی کردم:
طراحی ReST API مانند نوشتن یک دیالوگ بین دو نفر است
مرحله 1: در مورد “زبان” مکالمه توافق کنید
اولین گام در طراحی یک ReST API تصمیم گیری در مورد “زبان” مکالمه است، در اصل، قالب مورد استفاده برای تبادل اطلاعات. به این فکر کنید که از قبل در مورد “صحبت” کردن از قبل توافق کرده اید:
- متن ساده،
- JSON،
- XML یا
- حتی یک قالب کاملاً جدید منحصر به فرد برای API شما.
این تضمین می کند که هر دو طرف، کاربر و سیستم، از همان ابتدا می توانند یکدیگر را به وضوح درک کنند.
مرحله 2: درک مقاصد کاربر
بعد، بر درک موضوع تمرکز کنید الزامات، که اساساً مقاصد کاربر است:
- آنها برای رسیدن به چه چیزی تلاش می کنند؟
- ساده ترین و طبیعی ترین راه برای بیان درخواستشان چیست؟
مرحله 3: ایجاد یک دیالوگ
یک بار…