REST API ۽ ٻيو ٽيسٽ ٽاسڪ.

حصو I: شروعات ڪٿان شروع ڪجي؟ ڪافي عجيب، پر ٽيڪنيڪل وضاحتن کان. ان ڳالهه کي يقيني بڻائڻ انتهائي ضروري آهي ته پيش ڪيل TOR پڙهڻ کان پوءِ توهان مڪمل طور تي سمجھو ٿا ته ان ۾ ڇا لکيل آهي ۽ ڪلائنٽ ڪهڙي توقع رکي ٿو. پهرين، اهو وڌيڪ عمل درآمد لاء ضروري آهي، ۽ ٻيو، جيڪڏهن توهان عمل نه ڪيو جيڪو توهان کان توقع ڪئي وئي آهي، اهو توهان جي فائدي ۾ نه ٿيندو. هوا کي ضايع ڪرڻ کان بچڻ لاء، اچو ته هڪ سادي ٽيڪنيڪل وضاحتن کي ترتيب ڏيو. تنهن ڪري، مان هڪ خدمت چاهيان ٿو جنهن ڏانهن آئون ڊيٽا موڪلي سگهان ٿو، اهو خدمت تي ذخيرو ڪيو ويندو ۽ مون ڏانهن موٽايو ويندو. جيڪڏهن ضروري هجي ته مون کي هن ڊيٽا کي اپڊيٽ ڪرڻ ۽ حذف ڪرڻ جي قابل پڻ هجي . ڪجھ جملن کي صاف شيء وانگر نٿو لڳي، صحيح؟ مان اتي ڊيٽا ڪيئن موڪلڻ چاهيان ٿو؟ ڪهڙيون ٽيڪنالاجيون استعمال ڪرڻ گهرجن؟ هي ڊيٽا ڪهڙي شڪل ۾ هوندي؟ هتي اچڻ ۽ نڪرڻ واري ڊيٽا جا ڪي به مثال نه آهن. نتيجو - ٽيڪنيڪل وضاحت اڳ ۾ ئي خراب آهي . اچو ته ٻيهر بيان ڪرڻ جي ڪوشش ڪريون: اسان کي هڪ خدمت جي ضرورت آهي جيڪا 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
  ]
}

حصو II: نوڪري جا اوزار تنهنڪري، ڪم جو دائرو گهٽ يا گهٽ واضح آهي، پر اسان اهو ڪيئن ڪرڻ وارا آهيون؟ ظاهر آهي، ٽيسٽ ۾ اهڙن ڪمن کي ڪجهه ايپليڪيشن مقصدن سان گڏ ڏنو ويو آهي، اهو ڏسڻ لاءِ ته توهان ڪيئن ڪوڊ ٿا ڪريو، توهان کي اسپرنگ استعمال ڪرڻ تي مجبور ڪرڻ ۽ ڊيٽابيس سان ٿورو ڪم ڪرڻ لاءِ. خير، اچو ته اهو ڪريون. اسان کي اسپرنگ بوٽ پروجيڪٽ جي ضرورت آهي REST API سپورٽ ۽ ڊيٽابيس سان. ويب سائيٽ تي https://start.spring.io/ توهان هر شي کي ڳولي سگهو ٿا جيڪو توهان کي گهربل آهي. توھان منتخب ڪري سگھوٿا بلڊنگ سسٽم، ٻولي، اسپرنگ بوٽ ورزن، سيٽنگ آرٽيڪل سيٽنگون، جاوا ورزن، ۽ انحصار. شامل ڪريو انحصار بٽڻ تي ڪلڪ ڪرڻ سان هڪ خاص مينيو آڻيندو سرچ بار سان. لفظ باقي ۽ ڊيٽا لاءِ پهريون اميدوار اسپرنگ ويب ۽ اسپرنگ ڊيٽا آهن - اسان انهن کي شامل ڪنداسين. Lombok هڪ آسان لائبريري آهي جيڪا توهان کي اطلاعن کي استعمال ڪرڻ جي اجازت ڏئي ٿي ڪوڊ جي ڪلوميٽرن کان نجات حاصل ڪرڻ لاء گيٽر ۽ سيٽر طريقن سان. ٺاھيو بٽڻ تي ڪلڪ ڪرڻ سان اسان پروجيڪٽ سان گڏ ھڪڙو آرڪائيو حاصل ڪنداسين جيڪو اڳ ۾ ئي انپيڪ ڪري سگھجي ٿو ۽ اسان جي پسنديده IDE ۾ کوليو وڃي. ڊفالٽ طور، اسان هڪ خالي پروجيڪٽ حاصل ڪنداسين، تعميراتي سسٽم لاء هڪ ترتيب واري فائل سان (منهنجي صورت ۾ اهو گرڊل هوندو، پر Maven شين سان ڪو به بنيادي فرق نه آهي، ۽ هڪ بهار جي شروعاتي فائل) ڌيان وارا ماڻهو ٻن شين تي ڌيان ڏئي سگھن ٿا. . پهرين، مون وٽ ٻه سيٽنگون فائلون آهن 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());
    }
}

هاڻي اسان جو ملازم ڪنٽرولر طبقو هن وانگر ڏسڻ ۾ اچي ٿو. هتي ڪجهه اهم شيون آهن جن تي ڌيان ڏيڻ ضروري آهي. 1. ڪلاس کان مٿي تشريحون، پهريون @RestController اسان جي ايپليڪيشن کي ٻڌائي ٿو ته هي ڪلاس هڪ آخري نقطو هوندو. 2. @RequestMapping، جيتوڻيڪ لازمي نه آهي، هڪ مفيد تشريح آهي؛ اهو توهان کي آخري نقطي لاءِ مخصوص رستو مقرر ڪرڻ جي اجازت ڏئي ٿو. اهي. ان تي دستڪ ڏيڻ لاءِ، توهان کي درخواستون موڪلڻ گهرجن localhost:port/employee ڏانهن نه، پر هن صورت ۾ localhost:8086/api/v1/employee اصل ۾، اهي api/v1 ۽ ملازم ڪٿان آيا؟ اسان جي application.yml مان جيڪڏهن توهان ويجهڙائي سان ڏسندا آهيو، توهان اتي هيٺيون لائينون ڳولي سگهو ٿا:

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

جئين توهان ڏسي سگهو ٿا، اسان وٽ اهڙا متغير آهن جيئن application.endpoint.root ۽ application.endpoint.employee، اهي بلڪل آهن جيڪي مون تشريح ۾ لکيا آهن، آئون هن طريقي کي ياد رکڻ جي صلاح ڪريان ٿو - اهو گهڻو وقت بچائيندو ته وڌائڻ يا ٻيهر لکڻ تي. ڪارڪردگي - اهو هميشه کان وڌيڪ آسان آهي ته هر شي کي ترتيب ۾ رکڻ لاء، ۽ پوري منصوبي کي هارڊ ڪوڊ نه ڪيو وڃي. 3. @RequiredArgsConstructor هڪ Lombok تشريح آهي، هڪ آسان لائبريري جيڪا توهان کي غير ضروري شيون لکڻ کان پاسو ڪرڻ جي اجازت ڏئي ٿي. انهي صورت ۾، تشريح ان حقيقت جي برابر آهي ته ڪلاس ۾ هڪ عوامي تعمير ڪندڙ هوندو جنهن ۾ سڀني شعبن کي حتمي طور نشان لڳايو ويو آهي.

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

پر جيڪڏهن هڪ تشريح ڪافي آهي ته اهڙي ڳالهه ڇو لکون؟ :) رستي جي ذريعي، مبارڪون، هي سڀ کان وڌيڪ نجي فائنل فيلڊ بدنام انحصار انجيڪشن کان وڌيڪ ناهي. اچو ته اڳتي وڌون، اصل ۾، ملازم سروس ڪهڙي قسم جي فيلڊ آهي؟ اها اسان جي پروجيڪٽ ۾ خدمتن مان هڪ هوندي جيڪا هن آخري پوائنٽ لاءِ درخواستن تي عمل ڪندي. هتي خيال بلڪل سادو آهي. هر طبقي کي پنهنجو ڪم هجڻ گهرجي ۽ غير ضروري ڪمن سان اوورلوڊ نه ٿيڻ گهرجي. جيڪڏهن اهو هڪ ڪنٽرولر آهي، ان کي درخواستون وصول ڪرڻ ۽ جواب موڪلڻ جو خيال رکڻ ڏيو، پر اسان پروسيسنگ کي اضافي خدمت جي حوالي ڪرڻ چاهيندا. هن طبقي ۾ ڇڏيل آخري شيء صرف هڪ طريقو آهي جيڪو اسان جي ڪمپني جي سڀني ملازمن جي فهرست کي واپس ڪري ٿو جيڪو مٿي ڄاڻايل خدمت استعمال ڪندي. لسٽ پاڻ هڪ اداري ۾ لپي وئي آهي جنهن کي ResponseEntity سڏيو ويندو آهي. مان ائين ڪريان ٿو ته جيئن مستقبل ۾، جيڪڏهن ضروري هجي ته، آئون آساني سان جوابي ڪوڊ ۽ پيغام واپس ڪري سگهان ٿو جيڪو مون کي گهربل آهي، جيڪو خودڪار سسٽم سمجهي سگهي ٿو. تنهن ڪري، مثال طور، ResponseEntity.ok() 200 هين ڪوڊ واپس ڪندو، جيڪو چوندو ته سڀ ڪجهه ٺيڪ آهي، پر جيڪڏهن آئون واپس ڪندس، مثال طور،

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

پوءِ ڪلائنٽ ڪوڊ 400 وصول ڪندو - خراب ريڪسٽ ۽ جواب ۾ هڪ خالي فهرست. عام طور تي هي ڪوڊ واپس ڪيو ويندو آهي جيڪڏهن درخواست غلط آهي. پر هڪ ڪنٽرولر اسان لاءِ ايپليڪيشن شروع ڪرڻ لاءِ ڪافي نه هوندو. اسان جا انحصار اسان کي ائين ڪرڻ جي اجازت نه ڏيندا، ڇو ته اسان کي اڃا تائين هڪ بنياد جي ضرورت آهي :) خير، اچو ته ايندڙ حصي ڏانهن وڃو. حصو IV: سادو استقامت جيئن ته اسان جو بنيادي ڪم ايپليڪيشن کي لانچ ڪرڻ آهي، اسان پاڻ کي في الحال ڪجهه اسٽبس تائين محدود ڪنداسين. توهان اڳ ۾ ئي ڪنٽرولر ڪلاس ۾ ڏٺو آهي ته اسان ملازمن جي قسم جي شين جي لسٽ واپس ڪندا آهيون، اهو ڊيٽابيس لاء اسان جو ادارو هوندو. اچو ته ان کي demo.persistence.entity پيڪيج ۾ ٺاهيون . مستقبل ۾، اداري جي پيڪيج کي ڊيٽابيس مان ٻين ادارن سان گڏ ڪري سگھجي ٿو.

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

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

هي هڪ ڪلاس آهي دروازو جيترو سادو، جنهن جون تشريحون بلڪل هن ريت آهن: هي هڪ ڊيٽابيس جو ادارو آهي @Entity، هي هڪ ڪلاس آهي ڊيٽا سان @Data - Lombok. مددگار Lombok اسان لاء تمام ضروري حاصل ڪندڙ، سيٽرز، تعمير ڪندڙ ٺاهيندو - مڪمل سامان. خير، ڪيڪ تي ٿورڙي چيري آهي @Accessors(زنجيرن = سچو) حقيقت ۾، هي بلڊر جي نموني جو لڪيل عمل آهي. فرض ڪريو توھان وٽ ھڪڙو ڪلاس آھي جنھن ۾ فيلڊز جو ھڪڙو گروپ آھي جيڪو توھان مقرر ڪرڻ چاھيو ٿا ٺاھيندڙ جي ذريعي نه، پر طريقن سان. مختلف ترتيب ۾، شايد سڀ هڪ ئي وقت ۾ نه. توهان ڪڏهن به نه ٿا ڄاڻو ته توهان جي درخواست ۾ ڪهڙي قسم جي منطق هوندي. هي تشريح هن ڪم لاءِ توهان جي ڪنجي آهي. اچو ته ڏسون:

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 سان ڳنڍيو آھي (يا ھٿ سان ٺاھيندڙ ٺاھيو آھي) اسپرنگ، جڏھن ايپليڪيشن کي شروع ڪندي، اھو ھن جڳھ کي ڳوليندو ۽ اسان کي ھڪڙي طبقاتي اعتراض کي ھن متغير ۾ سلپ ڪندو. هتي ڊفالٽ سنگلٽن آهي - يعني. اهڙين سڀني لنڪن لاءِ هڪ اعتراض هوندو؛ ايپليڪيشن کي ڊزائين ڪرڻ وقت اهو ضروري آهي ته اڪائونٽ ۾ رکيو وڃي. دراصل، اهو سڀ ڪجهه آهي، ايپليڪيشن کي شروع ڪري سگهجي ٿو. config ۾ ضروري سيٽنگون داخل ڪرڻ نه وساريو. مان بيان نه ڪندس ته ڊيٽابيس کي ڪيئن نصب ڪيو وڃي، هڪ صارف ۽ ڊيٽابيس پاڻ ٺاهيو، پر مان صرف اهو نوٽ ڪندس ته 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 ڊيٽابيس صرف ان صورت ۾، آئون پنهنجي 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 ۽ ڊيٽا جي تصديق