REST API اور ایک اور ٹیسٹ ٹاسک۔

حصہ اول: آغاز کہاں سے شروع کیا جائے؟ عجیب بات ہے، لیکن تکنیکی خصوصیات سے۔ یہ یقینی بنانا انتہائی ضروری ہے کہ جمع کرائے گئے ٹی او آر کو پڑھنے کے بعد آپ پوری طرح سمجھ گئے ہوں کہ اس میں کیا لکھا ہے اور مؤکل کیا توقع رکھتا ہے۔ اول، یہ مزید نفاذ کے لیے ضروری ہے، اور دوسرا، اگر آپ اس پر عمل نہیں کرتے جس کی آپ سے توقع کی جاتی ہے، تو یہ آپ کے فائدے کے لیے نہیں ہوگا۔ ہوا کے ضیاع سے بچنے کے لیے، آئیے ایک سادہ تکنیکی تفصیلات کا خاکہ بنائیں۔ لہذا، میں ایک ایسی سروس چاہتا ہوں جس پر میں ڈیٹا بھیج سکوں، اسے سروس میں محفوظ کیا جائے گا اور اپنی مرضی سے مجھے واپس کر دیا جائے گا۔ اگر ضروری ہو تو مجھے اس ڈیٹا کو اپ ڈیٹ کرنے اور حذف کرنے کے قابل ہونے کی بھی ضرورت ہے ۔ ایک دو جملے ایک واضح چیز کی طرح نہیں لگتے، ٹھیک ہے؟ میں وہاں ڈیٹا کیسے بھیجنا چاہتا ہوں؟ کون سی ٹیکنالوجیز استعمال کرنی ہیں؟ یہ ڈیٹا کس فارمیٹ میں ہوگا؟ آنے والے اور جانے والے ڈیٹا کی بھی کوئی مثال نہیں ہے۔ نتیجہ - تکنیکی تفصیلات پہلے ہی خراب ہے ۔ آئیے دوبارہ بیان کرنے کی کوشش کریں: ہمیں ایک ایسی خدمت کی ضرورت ہے جو HTTP درخواستوں پر کارروائی کر سکے اور منتقل شدہ ڈیٹا کے ساتھ کام کر سکے۔ یہ عملے کے ریکارڈ کا ڈیٹا بیس ہوگا۔ ہمارے پاس ملازمین ہوں گے، وہ محکموں اور خصوصیات کے لحاظ سے تقسیم ہوتے ہیں، ملازمین کو ان کے لیے کام تفویض کیے جا سکتے ہیں۔ ہمارا کام کرایہ پر لیے گئے، برطرف کیے گئے، منتقل کیے گئے ملازمین کے لیے اکاؤنٹنگ کے عمل کو خودکار بنانا ہے، ساتھ ہی REST API کا استعمال کرتے ہوئے کام تفویض کرنے اور منسوخ کرنے کے عمل کو بھی۔ فیز 1 کے طور پر، ہم فی الحال صرف ملازمین کے ساتھ کام کر رہے ہیں۔ اس کے ساتھ کام کرنے کے لیے سروس کے پاس کئی اختتامی نکات ہونے چاہئیں: - POST/employee - POST درخواست، جس میں ملازم کے بارے میں ڈیٹا کے ساتھ JSON آبجیکٹ کو قبول کرنا چاہیے۔ اس آبجیکٹ کو ڈیٹا بیس میں محفوظ کیا جانا چاہیے؛ اگر ایسی کوئی چیز ڈیٹا بیس میں پہلے سے موجود ہے، تو فیلڈز میں موجود معلومات کو نئے ڈیٹا کے ساتھ اپ ڈیٹ کیا جانا چاہیے۔ - GET /employee - GET درخواست جو ڈیٹا بیس میں محفوظ کردہ ملازمین کی پوری فہرست کو واپس کرتی ہے - DELETE - DELETE /employee کسی مخصوص ملازم کے ملازم ڈیٹا ماڈل کو حذف کرنے کے لیے:

{
  "firstName": String,
  "lastName": String,
  "department": String,
  "salary": String
  "hired": String //"yyyy-mm-dd"
  "tasks": [
  	//List of tasks, not needed for Phase 1
  ]
}

حصہ دوم: کام کے اوزار تو، کام کا دائرہ کم و بیش واضح ہے، لیکن ہم اسے کیسے کریں گے؟ ظاہر ہے، ٹیسٹ میں ایسے کاموں کو ایپلیکیشن کے دو مقاصد کے ساتھ دیا جاتا ہے، یہ دیکھنے کے لیے کہ آپ کس طرح کوڈ کرتے ہیں، آپ کو سپرنگ استعمال کرنے پر مجبور کرتے ہیں اور ڈیٹا بیس کے ساتھ تھوڑا سا کام کرتے ہیں۔ ٹھیک ہے، چلو یہ کرتے ہیں. ہمیں REST API سپورٹ اور ڈیٹا بیس کے ساتھ SpringBoot پروجیکٹ کی ضرورت ہے۔ ویب سائٹ https://start.spring.io/ پر آپ اپنی ضرورت کی ہر چیز تلاش کر سکتے ہیں۔ آپ بلڈ سسٹم، زبان، اسپرنگ بوٹ ورژن، آرٹفیکٹ سیٹنگز، جاوا ورژن، اور انحصار کو منتخب کر سکتے ہیں۔ انحصار شامل کریں بٹن پر کلک کرنے سے سرچ بار کے ساتھ ایک خصوصیت والا مینو سامنے آئے گا۔ الفاظ آرام اور ڈیٹا کے پہلے امیدوار اسپرنگ ویب اور اسپرنگ ڈیٹا ہیں - ہم انہیں شامل کریں گے۔ لومبوک ایک آسان لائبریری ہے جو آپ کو گیٹر اور سیٹٹر کے طریقوں سے کلومیٹر کے کوڈ سے چھٹکارا حاصل کرنے کے لیے تشریحات استعمال کرنے کی اجازت دیتی ہے۔ جنریٹ بٹن پر کلک کرنے سے ہمیں پروجیکٹ کے ساتھ ایک آرکائیو ملے گا جسے پہلے سے ہی پیک کیا جا سکتا ہے اور ہمارے پسندیدہ IDE میں کھولا جا سکتا ہے۔ پہلے سے طے شدہ طور پر، ہمیں ایک خالی پروجیکٹ ملے گا، جس میں بلڈ سسٹم کے لیے ایک کنفیگریشن فائل ہوگی (میرے معاملے میں یہ گریڈل ہوگی، لیکن ماون کے ساتھ چیزوں میں کوئی بنیادی فرق نہیں ہے، اور ایک اسپرنگ اسٹارٹ اپ فائل) توجہ دینے والے لوگ دو چیزوں پر توجہ دے سکتے ہیں۔ . سب سے پہلے، میرے پاس دو سیٹنگ فائلیں application.properties اور application.yml ہیں۔ پہلے سے طے شدہ طور پر، آپ کو بالکل پراپرٹیز ملیں گی - ایک خالی فائل جس میں آپ سیٹنگز اسٹور کر سکتے ہیں، لیکن میرے نزدیک yml فارمیٹ کچھ زیادہ پڑھنے کے قابل لگتا ہے، اب میں ایک موازنہ دکھاؤں گا: اس حقیقت کے باوجود کہ بائیں طرف کی تصویر زیادہ کمپیکٹ نظر آتی ہے۔ ، خصوصیات کے راستے میں نقل کی ایک بڑی مقدار کو دیکھنا آسان ہے۔ دائیں طرف کی تصویر درخت کی ساخت کے ساتھ ایک باقاعدہ yml فائل ہے جسے پڑھنا کافی آسان ہے۔ میں اس فائل کو بعد میں پروجیکٹ میں استعمال کروں گا۔ دوسری چیز جس پر توجہ دینے والے لوگ محسوس کر سکتے ہیں وہ یہ ہے کہ میرے پروجیکٹ کے پہلے ہی کئی پیکج ہیں۔ وہاں ابھی تک کوئی سمجھدار کوڈ نہیں ہے، لیکن یہ ان کے ذریعے جانے کے قابل ہے۔ درخواست کیسے لکھی جاتی ہے؟ ایک مخصوص کام ہونے کے بعد، ہمیں اسے تحلیل کرنا چاہیے - اسے چھوٹے ذیلی کاموں میں تقسیم کریں اور ان کا مستقل نفاذ شروع کریں۔ ہم سے کیا تقاضا ہے؟ ہمیں ایک API فراہم کرنے کی ضرورت ہے جسے کلائنٹ استعمال کر سکے؛ کنٹرولر پیکیج کے مواد فعالیت کے اس حصے کے لیے ذمہ دار ہوں گے۔ درخواست کا دوسرا حصہ ڈیٹابیس ہے - استقامت پیکیج۔ اس میں ہم ڈیٹابیس اینٹٹیز (اینٹیٹیز) کے ساتھ ساتھ ریپوزٹریز جیسی چیزوں کو ذخیرہ کریں گے - خصوصی اسپرنگ انٹرفیس جو آپ کو ڈیٹا بیس کے ساتھ بات چیت کرنے کی اجازت دیتے ہیں۔ سروس پیکج سروس کلاسز پر مشتمل ہوگا۔ ہم ذیل میں اسپرنگ ٹائپ سروس کے بارے میں بات کریں گے۔ اور آخری لیکن کم از کم، utils پیکیج۔ ہر طرح کے معاون طریقوں کے ساتھ یوٹیلیٹرین کلاسز کو وہاں ذخیرہ کیا جائے گا، مثال کے طور پر، تاریخ اور وقت کے ساتھ کام کرنے کی کلاسیں، یا تاروں کے ساتھ کام کرنے کی کلاسیں، اور کون جانتا ہے کہ اور کیا ہے۔ آئیے فعالیت کے پہلے حصے کو لاگو کرنا شروع کریں۔ حصہ III: کنٹرولر

@RestController
@RequestMapping("${application.endpoint.root}")
@RequiredArgsConstructor
public class EmployeeController {

    private final EmployeeService employeeService;

    @GetMapping("${application.endpoint.employee}")
    public ResponseEntity<List<Employee>> getEmployees() {
        return ResponseEntity.ok().body(employeeService.getAllEmployees());
    }
}

اب ہماری EmployeeController کلاس اس طرح نظر آتی ہے۔ یہاں بہت سی اہم چیزیں ہیں جن پر توجہ دینا ضروری ہے۔ 1. کلاس کے اوپر تشریحات، پہلا @RestController ہماری درخواست کو بتاتا ہے کہ یہ کلاس ایک اختتامی نقطہ ہوگا۔ 2. @RequestMapping، اگرچہ لازمی نہیں، ایک مفید تشریح ہے؛ یہ آپ کو اختتامی نقطہ کے لیے ایک مخصوص راستہ متعین کرنے کی اجازت دیتا ہے۔ وہ. اس پر دستک دینے کے لیے، آپ کو لوکل ہوسٹ:پورٹ/ملازم کو نہیں، بلکہ اس معاملے میں لوکل ہوسٹ:8086/api/v1/employee کو درخواستیں بھیجنی ہوں گی، دراصل، یہ api/v1 اور ملازم کہاں سے آئے؟ ہماری application.yml سے اگر آپ قریب سے دیکھیں تو آپ کو وہاں درج ذیل لائنیں مل سکتی ہیں۔

application:
  endpoint:
    root: api/v1
    employee: employee
    task: task

جیسا کہ آپ دیکھ سکتے ہیں، ہمارے پاس application.endpoint.root اور application.endpoint.employee جیسے متغیرات ہیں، یہ بالکل وہی ہیں جو میں نے تشریحات میں لکھے ہیں، میں اس طریقہ کو یاد رکھنے کی سفارش کرتا ہوں - اس سے توسیع یا دوبارہ لکھنے میں کافی وقت بچ جائے گا۔ فعالیت - ہر چیز کو config میں رکھنا ہمیشہ زیادہ آسان ہوتا ہے، اور پورے پروجیکٹ کو ہارڈ کوڈ نہیں کرنا۔ 3. @RequiredArgsConstructor ایک Lombok تشریح ہے، ایک آسان لائبریری جو آپ کو غیر ضروری چیزوں کو لکھنے سے بچنے کی اجازت دیتی ہے۔ اس صورت میں، تشریح اس حقیقت کے مترادف ہے کہ کلاس میں ایک پبلک کنسٹرکٹر ہوگا جس کے تمام فیلڈز کو فائنل کے طور پر نشان زد کیا گیا ہے۔

public EmployeeController(EmployeeService employeeService) {
    this.employeeService=employeeService;
}

لیکن اگر ایک تشریح کافی ہے تو ہم ایسی بات کیوں لکھیں؟ :) ویسے، مبارک ہو، یہ سب سے پرائیویٹ فائنل فیلڈ بدنام زمانہ ڈیپینڈینسی انجکشن سے زیادہ کچھ نہیں ہے۔ آئیے آگے بڑھتے ہیں، دراصل ایمپلائی سروس کس قسم کی فیلڈ ہے؟ یہ ہمارے پروجیکٹ کی ان خدمات میں سے ایک ہوگی جو اس اختتامی نقطہ کی درخواستوں پر کارروائی کرے گی۔ یہاں خیال بہت آسان ہے۔ ہر طبقے کا اپنا کام ہونا چاہیے اور غیر ضروری کاموں سے زیادہ بوجھ نہیں ہونا چاہیے۔ اگر یہ ایک کنٹرولر ہے، تو اسے درخواستیں وصول کرنے اور جوابات بھیجنے کا خیال رکھنے دیں، لیکن ہم پروسیسنگ کو ایک اضافی سروس کے سپرد کرنا چاہتے ہیں۔ اس کلاس میں آخری چیز باقی رہ گئی ہے وہ واحد طریقہ ہے جو مذکورہ سروس کا استعمال کرتے ہوئے ہماری کمپنی کے تمام ملازمین کی فہرست واپس کرتا ہے۔ فہرست بذات خود ResponseEntity نامی ایک ہستی میں لپٹی ہوئی ہے۔ میں ایسا اس لیے کرتا ہوں تاکہ مستقبل میں، اگر ضروری ہو تو، میں آسانی سے اپنے مطلوبہ رسپانس کوڈ اور پیغام کو واپس کر سکتا ہوں، جسے خودکار نظام سمجھ سکتا ہے۔ لہذا، مثال کے طور پر، ResponseEntity.ok() 200 واں کوڈ واپس کرے گا، جو کہے گا کہ سب کچھ ٹھیک ہے، لیکن اگر میں واپس کرتا ہوں، مثال کے طور پر،

return ResponseEntity.badRequest().body(Collections.emptyList());

تب کلائنٹ کو کوڈ 400 ملے گا - خراب ریوکیسٹ اور جواب میں ایک خالی فہرست۔ اگر درخواست غلط ہے تو عام طور پر یہ کوڈ واپس کر دیا جاتا ہے۔ لیکن ایک کنٹرولر ہمارے لیے درخواست شروع کرنے کے لیے کافی نہیں ہوگا۔ ہمارا انحصار ہمیں ایسا کرنے کی اجازت نہیں دے گا، کیونکہ ہمیں ابھی بھی ایک بنیاد کی ضرورت ہے :) ٹھیک ہے، آئیے اگلے حصے کی طرف چلتے ہیں۔ حصہ چہارم: سادہ استقامت چونکہ ہمارا اصل کام ایپلی کیشن کو لانچ کرنا ہے، اس لیے ہم ابھی خود کو چند اسٹبس تک محدود رکھیں گے۔ آپ پہلے ہی کنٹرولر کلاس میں دیکھ چکے ہیں کہ ہم Employee قسم کی اشیاء کی فہرست واپس کرتے ہیں، یہ ڈیٹا بیس کے لیے ہماری ہستی ہوگی۔ آئیے اسے demo.persistence.entity پیکیج میں بناتے ہیں ۔ مستقبل میں، entity پیکیج کو ڈیٹا بیس سے دیگر اداروں کے ساتھ مل سکتا ہے۔

@Entity
@Data
@Accessors(chain = true)
public class Employee {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    Long id;
}

یہ ایک دروازے کی طرح سادہ کلاس ہے، جس کی تشریحات بالکل درج ذیل ہیں: یہ ایک ڈیٹا بیس ادارہ ہے @Entity، یہ ایک کلاس ہے جس میں ڈیٹا @Data - Lombok ہے۔ مددگار Lombok ہمارے لیے تمام ضروری حاصل کرنے والے، سیٹرز، کنسٹرکٹرز - مکمل سامان تیار کرے گا۔ ٹھیک ہے، کیک پر ایک چھوٹی سی چیری ہے @Accessors(chain = true) درحقیقت، یہ بلڈر پیٹرن کا پوشیدہ نفاذ ہے۔ فرض کریں کہ آپ کے پاس فیلڈز کے ایک گروپ کے ساتھ ایک کلاس ہے جسے آپ کنسٹرکٹر کے ذریعے نہیں بلکہ طریقوں سے تفویض کرنا چاہتے ہیں۔ مختلف ترتیب میں، شاید سب ایک ہی وقت میں نہیں۔ آپ کبھی نہیں جانتے کہ آپ کی درخواست میں کس قسم کی منطق ہوگی۔ یہ تشریح اس کام کے لیے آپ کی کلید ہے۔ آئیں دیکھیں:

public Employee createEmployee() {
    return new Employee().setName("Peter")
        				.setAge("28")
        				.setDepartment("IT");
}

آئیے مان لیں کہ ہماری کلاس میں یہ تمام فیلڈز ہیں😄 آپ انہیں تفویض کر سکتے ہیں، آپ انہیں تفویض نہیں کر سکتے، آپ انہیں جگہوں پر ملا سکتے ہیں۔ صرف 3 جائیدادوں کے معاملے میں، ایسا نہیں لگتا کہ کوئی بقایا ہے۔ لیکن ایسی کلاسیں ہیں جن میں پراپرٹیز کی ایک بہت بڑی تعداد ہے، مثال کے طور پر 50۔ اور کچھ اس طرح لکھیں۔

public Employee createEmployee() {
    return new Employee("Peter", "28", "IT", "single", "loyal", List.of(new Task("do Something 1"), new Task ("do Something 2")));
}

بہت خوبصورت نہیں لگتی، ہے نا؟ ہمیں کنسٹرکٹر کے مطابق متغیرات کو شامل کرنے کے حکم پر بھی سختی سے عمل کرنے کی ضرورت ہے۔ بہر حال، میں اختلاف کرتا ہوں، آئیے بات پر واپس آتے ہیں۔ اب ہمارے پاس اس میں ایک (لازمی) فیلڈ ہے - ایک منفرد شناخت کنندہ۔ اس صورت میں، یہ ایک لمبی قسم کا نمبر ہے، جو ڈیٹا بیس میں محفوظ ہونے پر خود بخود بن جاتا ہے۔ اسی مناسبت سے، @Id تشریح ہمیں واضح طور پر بتاتی ہے کہ یہ ایک منفرد شناخت کنندہ ہے؛ @GeneratedValue اپنی منفرد نسل کے لیے ذمہ دار ہے۔ یہ بات قابل غور ہے کہ @Id کو ان فیلڈز میں شامل کیا جا سکتا ہے جو خود بخود پیدا نہیں ہوتے ہیں، لیکن پھر انفرادیت کے مسئلے کو دستی طور پر نمٹنا ہوگا۔ ایک منفرد ملازم شناخت کنندہ کیا ہو سکتا ہے؟ ٹھیک ہے، مثال کے طور پر، پورا نام + شعبہ... تاہم، ایک شخص کے پورے نام ہیں، اور اس بات کا امکان ہے کہ وہ اسی محکمے میں کام کریں گے، چھوٹا، لیکن وہاں ہے - اس کا مطلب ہے کہ فیصلہ خراب ہے۔ دوسرے شعبوں کا ایک گروپ شامل کرنا ممکن ہو گا، جیسے کرایہ کی تاریخ، شہر، لیکن یہ سب، مجھے لگتا ہے، منطق کو بہت زیادہ پیچیدہ بنا دیتا ہے۔ آپ سوچ سکتے ہیں، یہ کیسے ممکن ہے کہ کھیتوں کا ایک گروپ ایک ساتھ منفرد ہو؟ میں جواب دیتا ہوں - شاید۔ اگر آپ متجسس ہیں تو، آپ @Embeddable اور @Embedded جیسی چیز کے بارے میں گوگل کر سکتے ہیں، ہم نے جوہر کے ساتھ کام کر لیا ہے۔ اب ہمیں ایک سادہ ذخیرہ کی ضرورت ہے۔ یہ اس طرح نظر آئے گا:

public interface EmployeeRepository extends JpaRepository<Employee, Long> {

}

ہاں بس اتنا ہی ہے۔ صرف ایک انٹرفیس، ہم اسے EmployeeRepository کہتے ہیں، یہ JpaRepository کو بڑھاتا ہے جس میں دو ٹائپ شدہ پیرامیٹرز ہوتے ہیں، پہلا ڈیٹا ٹائپ کے لیے ذمہ دار ہوتا ہے جس کے ساتھ یہ کام کرتا ہے، دوسرا کلیدی قسم کے لیے۔ ہمارے معاملے میں، یہ ملازم اور لانگ ہیں۔ ابھی کے لیے اتنا ہی کافی ہے۔ ایپلیکیشن لانچ کرنے سے پہلے آخری ٹچ ہماری سروس ہوگی:

@Service
@RequiredArgsConstructor
public class EmployeeService {

    private final EmployeeRepository employeeRepository;

    public List<Employee> getAllEmployees() {
        return List.of(new Employee().setId(123L));
    }
}

پہلے سے ہی واقف RequiredArgsConstructor اور نیا @Service تشریح ہے - یہ وہی ہے جو عام طور پر کاروباری منطق کی پرت کو ظاہر کرتا ہے۔ موسم بہار کے سیاق و سباق کو چلاتے وقت، اس تشریح کے ساتھ نشان زد کلاسز بطور Beans بنائے جائیں گے۔ جب EmployeeController کلاس میں ہم نے حتمی پراپرٹی EmployeeService بنائی ہے اور RequiredArgsConstructor کو منسلک کیا ہے (یا ہاتھ سے ایک کنسٹرکٹر بنایا ہے) Spring، جب ایپلی کیشن شروع کریں گے، تو یہ اس جگہ کو تلاش کرے گا اور اس متغیر میں کلاس آبجیکٹ کو سلپ کر دے گا۔ یہاں پہلے سے طے شدہ سنگلٹن ہے - یعنی اس طرح کے تمام لنکس کے لیے ایک اعتراض ہوگا؛ ایپلی کیشن کو ڈیزائن کرتے وقت اس کا خیال رکھنا ضروری ہے۔ دراصل، بس اتنا ہی ہے، ایپلیکیشن لانچ کی جا سکتی ہے۔ تشکیل میں ضروری ترتیبات درج کرنا نہ بھولیں۔ میں اس بات کی وضاحت نہیں کروں گا کہ ڈیٹا بیس کو کیسے انسٹال کیا جائے، صارف اور خود ڈیٹا بیس کیسے بنایا جائے، لیکن میں صرف یہ نوٹ کروں گا کہ URL میں میں دو اضافی پیرامیٹرز استعمال کرتا ہوں - useUnicore=true اور characterEncoding=UTF-8۔ ایسا اس لیے کیا گیا تاکہ متن کسی بھی سسٹم پر کم و بیش یکساں طور پر ظاہر ہو۔ تاہم، اگر آپ ڈیٹا بیس کے ساتھ ٹنکر کرنے میں بہت سست ہیں اور واقعی ورکنگ کوڈ کے ارد گرد پوک کرنا چاہتے ہیں، تو ایک فوری حل ہے: 1. درج ذیل انحصار کو build.gradle میں شامل کریں:

implementation 'com.h2database:h2:2.1.214'

2. application.yml میں آپ کو متعدد خصوصیات میں ترمیم کرنے کی ضرورت ہے، میں سادگی کے لیے موسم بہار کے حصے کی مکمل مثال دوں گا:

spring:
  application:
    name: "employee-management-service"
  jpa:
    show-sql: true
    hibernate:
      ddl-auto: update
    database-platform: org.hibernate.dialect.H2Dialect
  datasource:
    driver-class-name: org.h2.Driver
    url: jdbc:h2:file:./mydb
    username: sa
    password:

ڈیٹا بیس پراجیکٹ فولڈر میں، mydb نامی فائل میں محفوظ کیا جائے گا ۔ لیکن میں ایک مکمل ڈیٹا بیس انسٹال کرنے کی تجویز کروں گا 😉 اس موضوع پر مفید مضمون: H2 ڈیٹا بیس کے ساتھ Spring Boot صرف اس صورت میں، میں انحصار میں تضادات کو ختم کرنے کے لیے اپنے build.gradle کا مکمل ورژن فراہم کروں گا:

plugins {
	id 'org.springframework.boot' version '2.7.2'
	id 'io.spring.dependency-management' version '1.0.12.RELEASE'
	id 'java'
}

group = 'com.example'
version = '0.0.1-SNAPSHOT'
sourceCompatibility = '17'

configurations {
	compileOnly {
		extendsFrom annotationProcessor
	}
}

repositories {
	mavenCentral()
}

dependencies {
	implementation 'org.springframework.boot:spring-boot-starter-data-jpa'
	implementation 'org.springframework.boot:spring-boot-starter-web'
	implementation 'mysql:mysql-connector-java:8.0.30'
	compileOnly 'org.projectlombok:lombok'
	annotationProcessor 'org.projectlombok:lombok'
	testImplementation 'org.springframework.boot:spring-boot-starter-test'
}

tasks.named('test') {
	useJUnitPlatform()
}

سسٹم لانچ کرنے کے لیے تیار ہے: آپ کسی بھی مناسب پروگرام سے ہمارے اینڈ پوائنٹ پر GET کی درخواست بھیج کر اسے چیک کر سکتے ہیں۔ اس خاص معاملے میں، ایک باقاعدہ براؤزر کرے گا، لیکن مستقبل میں ہمیں پوسٹ مین کی ضرورت ہوگی۔ ہاں، درحقیقت، ہم نے ابھی تک کسی بھی کاروباری تقاضے کو نافذ نہیں کیا ہے، لیکن ہمارے پاس پہلے سے ہی ایک ایپلیکیشن ہے جو شروع ہوتی ہے اور اسے مطلوبہ فعالیت تک بڑھایا جا سکتا ہے۔ جاری: REST API اور ڈیٹا کی توثیق