REST API ۽ ڊيٽا جي تصديق

پهرين حصي جو لنڪ: REST API ۽ ايندڙ ٽيسٽ ٽاسڪ خير، اسان جي ايپليڪيشن ڪم ڪري رهي آهي، اسان ان مان ڪجهه قسم جو جواب حاصل ڪري سگهون ٿا، پر اهو اسان کي ڇا ڏئي ٿو؟ اهو ڪو به مفيد ڪم نٿو ڪري. جلد ئي نه چيو ويو آهي، اچو ته ڪجهه مفيد عمل تي عمل ڪريون. سڀ کان پهرين، اچو ته اسان جي build.gradle ۾ ڪجهه نوان انحصار شامل ڪريون، اهي اسان لاءِ ڪارآمد ثابت ٿينديون:

implementation 'org.apache.commons:commons-lang3:3.12.0'
implementation 'org.apache.commons:commons-collections4:4.4'
implementation 'org.springframework.boot:spring-boot-starter-validation'

۽ اسان اصل ڊيٽا سان شروع ڪنداسين جيڪو اسان کي پروسيس ڪرڻ گهرجي. اچو ته اسان جي تسلسل واري پيڪيج ڏانهن واپس وڃو ۽ ادارو ڀرڻ شروع ڪيو. جيئن توهان کي ياد آهي، اسان ان کي صرف هڪ فيلڊ سان موجود رهڻ لاءِ ڇڏيو آهي، ۽ پوءِ آٽو ٺاهي ويندي آهي `@GeneratedValue(strategy= GenerationType.IDENTITY)` ذريعي، اچو ته ياد رکون ٽيڪنيڪل وضاحتن کي پهرين باب کان:

{
  "firstName": String,
  "lastName": String,
  "department": String,
  "salary": String
  "hired": String //"yyyy-mm-dd"
  "tasks": [
  ]
}

اسان وٽ پهريون ڀيرو ڪافي فيلڊ آهن، تنهنڪري اچو ته ان تي عمل ڪرڻ شروع ڪريون. پهرين ٽي شعبا سوال نه ٿا ڪن - اهي عام لائينون آهن، پر تنخواه جو ميدان اڳ ۾ ئي تجويز ڪيل آهي. اصل لائن ڇو؟ حقيقي ڪم ۾، اهو به ٿئي ٿو، هڪ گراهڪ توهان وٽ اچي ٿو ۽ چوي ٿو - مان توهان کي هي پيل لوڊ موڪلڻ چاهيان ٿو، ۽ توهان ان تي عمل ڪيو. توهان، يقينا، توهان جي ڪلهن کي ڇڪيو ۽ اهو ڪري سگهو ٿا، توهان هڪ معاهدي تي اچڻ جي ڪوشش ڪري سگهو ٿا ۽ وضاحت ڪري سگهو ٿا ته اهو بهتر آهي ته ڊيٽا کي گهربل شڪل ۾ منتقل ڪرڻ. اچو ته تصور ڪريون ته اسان هڪ سمارٽ ڪلائنٽ سان ملاقات ڪئي ۽ اتفاق ڪيو ته اهو بهتر آهي ته انگن اکرن کي عددي شڪل ۾ منتقل ڪيو وڃي، ۽ جيئن ته اسان رقم جي باري ۾ ڳالهائي رهيا آهيون، ان کي ٻيڻو ٿيڻ ڏيو. اسان جي پيلي لوڊ جو ايندڙ پيٽرولر نوڪرين جي تاريخ هوندي، گراهڪ ان کي اسان ڏانهن موڪليندو متفقه فارميٽ ۾: yyyy-mm-dd، جتي y سالن لاءِ ذميوار آهي، m ڏينهن لاءِ، ۽ d ڏينهن لاءِ متوقع آهي - 2022- 08-12. هن وقت آخري فيلڊ ڪلائنٽ کي مقرر ڪيل ڪمن جي هڪ فهرست هوندي. ظاهر آهي، ٽاسڪ اسان جي ڊيٽابيس ۾ هڪ ٻيو ادارو آهي، پر اسان اڃا تائين ان بابت گهڻو ڪجهه نٿا ڄاڻون، تنهنڪري اسان سڀ کان وڌيڪ بنيادي ادارو ٺاهينداسين جيئن اسان اڳ ۾ ملازم سان ڪيو هو. صرف هڪ شيء جيڪا اسان هاڻي فرض ڪري سگهون ٿا اهو آهي ته هڪ کان وڌيڪ ڪم هڪ ملازم کي تفويض ڪري سگهجي ٿو، تنهنڪري اسين نام نهاد هڪ کان گهڻن طريقي کي لاڳو ڪنداسين، هڪ کان گهڻن تناسب. تفصيل سان ڳالهائيندي، ملازم جي ٽيبل ۾ هڪ رڪارڊ ڪم جي ٽيبل مان ڪيترن ئي رڪارڊ سان ملندو . مون پڻ فيصلو ڪيو ته اهڙي شيءِ کي شامل ڪرڻ جو هڪ منفرد نمبر فيلڊ، ته جيئن اسان واضح طور تي هڪ ملازم کي ٻئي کان ڌار ڪري سگهون. هن وقت اسان جو ملازم طبقو هن طرح نظر اچي ٿو:

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

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

    @NotBlank
    @Column(unique = true)
    private String uniqueNumber;
    private String firstName;
    private String lastName;
    private String department;
    private Double salary;
    private LocalDate hired;

    @OneToMany
    @JoinColumn(name = "employee_id")
    List<Task> tasks = new ArrayList<>();
}

ٽاسڪ اداري لاءِ ھيٺ ڏنل ڪلاس ٺاھيو ويو:

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

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

جيئن مون چيو، اسان ٽاسڪ ۾ ڪا به نئين شيءِ نه ڏسنداسين، هن ڪلاس لاءِ هڪ نئون مخزن پڻ ٺاهيو ويو آهي، جيڪو ملازمن لاءِ مخزن جي هڪ ڪاپي آهي- مان نه ڏيندس، توهان ان کي قياس ذريعي پاڻ ٺاهي سگهو ٿا. پر اهو احساس آهي ته ملازم طبقي بابت ڳالهائڻ. جيئن مون چيو، اسان ڪيترن ئي شعبن کي شامل ڪيو، پر صرف آخري هڪ دلچسپي جو آهي - ڪم. هي هڪ فهرست آهي<Task> tasks ، ان کي فوري طور تي هڪ خالي ArrayList سان شروع ڪيو ويندو آهي ۽ ڪيترن ئي تشريح سان نشان لڳل هوندو آهي. 1. @OneToMany جيئن مون چيو، اهو هوندو اسان جي ملازمن جو ڪمن جو تناسب. 2. @JoinColumn - اهو ڪالم جنهن ۾ ادارا شامل ڪيا ويندا. انهي صورت ۾، هڪ ملازم_id ڪالم ٺاهيو ويندو ٽاسڪ ٽيبل ۾ جيڪو اسان جي ملازم جي آئي ڊي ڏانهن اشارو ڪندي؛ اهو اسان جي خدمت ڪندو ForeighnKey نالي جي ظاهري تقدس جي باوجود، توهان ڪالم جو نالو ڏئي سگهو ٿا جيڪو توهان چاهيو. صورتحال ٿوري وڌيڪ پيچيده ٿي ويندي جيڪڏهن توهان کي صرف هڪ ID نه، پر ڪنهن قسم جو حقيقي ڪالم استعمال ڪرڻ جي ضرورت آهي؛ اسان هن موضوع تي بعد ۾ رابطو ڪنداسين. 3. توهان شايد id جي مٿان هڪ نئين تشريح پڻ محسوس ڪئي آهي - @JsonIgnore. جيئن ته id اسان جو اندروني ادارو آهي، اسان کي لازمي طور تي ان کي ڪلائنٽ ڏانهن واپس ڪرڻ جي ضرورت ناهي. 4. @NotBlank تصديق لاءِ هڪ خاص تشريح آهي، جنهن جو چوڻ آهي ته فيلڊ لازمي نه هجي null يا خالي اسٽرنگ 5. @Column(unique = true) چوي ٿو ته هن ڪالمن ۾ منفرد قدر هجڻ گهرجن. تنهن ڪري، اسان وٽ اڳ ۾ ئي ٻه ادارا آهن، اهي پڻ هڪ ٻئي سان ڳنڍيل آهن. انهن کي اسان جي پروگرام ۾ ضم ڪرڻ جو وقت اچي ويو آهي - اچو ته خدمتن ۽ ڪنٽرولرز سان معاملو ڪريون. سڀ کان پهريان، اچو ته اسان جي اسٽب کي getAllEmployees() طريقي مان هٽائي ڇڏيون ۽ ان کي ڪنهن شيءِ ۾ ڦيرايو جيڪو اصل ۾ ڪم ڪري ٿو:

public List<Employee> getAllEmployees() {
       return employeeRepository.findAll();
   }

اهڙيء طرح، اسان جي مخزن هر شيء کي ريڪ ڪندو جيڪو ڊيٽابيس مان موجود آهي ۽ اسان کي ڏيندو. اهو قابل ذڪر آهي ته اهو پڻ ڪم جي فهرست کڻندو. پر ان کي ٻاهر ڪڍڻ يقيناً دلچسپ آهي، پر جيڪڏهن اتي ڪجهه به ناهي ته ان کي ٻاهر ڪڍڻ ڇا آهي؟ اھو صحيح آھي، ان جو مطلب آھي اسان کي اھو معلوم ڪرڻو پوندو ته اتي ڪا شيءِ ڪيئن رکجي. سڀ کان پهريان، اچو ته اسان جي ڪنٽرولر ۾ هڪ نئون طريقو لکون.

@PostMapping("${application.endpoint.employee}")
    public ResponseEntity<?> createOrUpdateEmployee(@RequestBody final Employee employee) {
        try {
            employeeService.save(employee);
        } catch (ValidationException e) {
            return ResponseEntity.badRequest().body(e.getViolations());
        }
        return ResponseEntity.status(HttpStatus.CREATED).build();
    }

هي آهي @PostMapping، i.e. اهو عمل ڪري ٿو پوسٽ جي درخواستن کي اسان جي ملازمن جي آخري پوائنٽ تي اچڻ. عام طور تي، مون سوچيو ته جيئن هن ڪنٽرولر جي سڀني درخواستن کي هڪ آخري نقطي تي ايندي، اچو ته هن کي ٿورو آسان بڻائي. application.yml ۾ اسان جون سٺيون سيٽنگون ياد رکو؟ اچو ته انهن کي درست ڪريون. اچو ته ايپليڪيشن سيڪشن کي هاڻي هن طرح نظر اچي:

application:
  endpoint:
    root: api/v1
    employee: ${application.endpoint.root}/employees
    task: ${application.endpoint.root}/tasks

هي اسان کي ڇا ڏئي ٿو؟ حقيقت اها آهي ته ڪنٽرولر ۾ اسان هر مخصوص طريقي لاءِ ميپنگ کي ختم ڪري سگهون ٿا، ۽ آخري نقطي کي @RequestMapping("${application.endpoint.employee}") تشريح ۾ ڪلاس جي سطح تي سيٽ ڪيو ويندو . اها خوبصورتي هاڻي آهي. اسان جو ڪنٽرولر:

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

    private final EmployeeService employeeService;

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

    @PostMapping
    public ResponseEntity<?> createOrUpdateEmployee(@RequestBody final Employee employee) {
        try {
            employeeService.save(employee);
        } catch (ValidationException e) {
            return ResponseEntity.badRequest().body(e.getViolations());
        }
        return ResponseEntity.status(HttpStatus.CREATED).build();
    }
}

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

import com.example.demo.exception.ValidationException;
import com.example.demo.persistence.entity.Employee;
import lombok.RequiredArgsConstructor;
import org.apache.commons.collections4.CollectionUtils;
import org.springframework.stereotype.Service;

import java.util.List;
import java.util.Set;

import javax.validation.ConstraintViolation;
import javax.validation.Validator;

@Service
@RequiredArgsConstructor
public class ValidationService {

    private final Validator validator;

    public boolean isValidEmployee(Employee employee) throws ValidationException {
        Set<Constraintviolation<Employee>> constraintViolations = validator.validate(employee);

        if (CollectionUtils.isNotEmpty(constraintViolations)) {
            throw new ValidationException(buildViolationsList(constraintViolations));
        }
        return true;
    }

    private <T> List<Violation> buildViolationsList(Set<Constraintviolation<T>> constraintViolations) {
        return constraintViolations.stream()
                                   .map(violation -> new Violation(
                                                   violation.getPropertyPath().toString(),
                                                   violation.getMessage()
                                           )
                                   )
                                   .toList();
    }
}

ڪلاس ڪجھ وڏو ٿي ويو، پر گھٻرايو نه، اسان ان کي ھاڻي معلوم ڪنداسين :) ھتي اسان تيار ٿيل تصديق واري لائبريري جا اوزار استعمال ڪندا آھيون javax.validation ھي لائبريري اسان وٽ نئين انحصار مان آئي آھي. اسان build.graddle عملدرآمد ۾ شامل ڪيو آهي 'org.springframework.boot:spring-boot-starter -validation' اسان جا پراڻا دوست سروس ۽ RequiredArgsConstructor اڳ ۾ ئي اسان کي سڀ ڪجهه ٻڌايو جيڪو اسان کي هن ڪلاس بابت ڄاڻڻ جي ضرورت آهي، اتي پڻ هڪ خانگي فائنل صحيح ڪندڙ فيلڊ آهي. هو جادو ڪندو. اسان isValidEmployee طريقو ٺاھيو آھي، جنھن ۾ اسين ملازم جي اداري کي پاس ڪري سگھون ٿا؛ اھو طريقو ھڪڙو ValidationException اڇلائي ٿو، جنھن کي اسين ٿوري دير بعد لکنداسين. ها، اهو اسان جي ضرورتن لاء هڪ رواج استثنا هوندو. validator.validate(employee) طريقي کي استعمال ڪندي، اسان کي ConstraintViolation شين جي هڪ فهرست ملندي - اهي سڀئي تضاد جيڪي تصديق جي تشريح سان اسان اڳ ۾ شامل ڪيا آهن. وڌيڪ منطق سادو آهي، جيڪڏهن هي فهرست خالي نه آهي (يعني خلاف ورزيون آهن)، اسان هڪ استثنا ڏيون ٿا ۽ خلاف ورزين جي هڪ فهرست ٺاهيون ٿا - buildViolationsList طريقو مهرباني ڪري نوٽ ڪريو ته هي هڪ عام طريقو آهي، يعني. مختلف شين جي خلاف ورزين جي لسٽن سان ڪم ڪري سگھي ٿو - اھو مستقبل ۾ ڪارائتو ٿي سگھي ٿو جيڪڏھن اسان ڪنھن ٻئي شيءِ جي تصديق ڪريون. هي طريقو اصل ۾ ڇا ڪندو؟ اسٽريم API استعمال ڪندي، اسان خلاف ورزين جي لسٽ ذريعي وڃون ٿا. اسان نقشي جي طريقي ۾ هر خلاف ورزي کي اسان جي پنهنجي خلاف ورزي واري اعتراض ۾ ڦيرايو، ۽ سڀني نتيجن واري شين کي هڪ فهرست ۾ گڏ ڪيو. اسان هن کي واپس ڪري رهيا آهيون. اسان جي خلاف ورزي جو ٻيو ڪهڙو اعتراض آهي، توهان پڇو؟ هتي هڪ سادي رڪارڊ آهي

public record Violation(String property, String message) {}

رڪارڊ جاوا ۾ اهڙيون خاص جدتون آهن، جيڪڏهن توهان کي ڊيٽا سان گڏ ڪنهن شئي جي ضرورت هجي، بغير ڪنهن منطق يا ڪنهن ٻئي جي. جيتوڻيڪ مان پاڻ اڃا تائين نه سمجهي سگهيو آهيان ته اهو ڇو ڪيو ويو، ڪڏهن ڪڏهن اهو ڪافي آسان شيء آهي. اهو هڪ الڳ فائل ۾ ٺاهيو وڃي، هڪ باقاعده ڪلاس وانگر. ڪسٽم ValidationException ڏانهن واپسي - اهو هن طرح نظر اچي ٿو:

@RequiredArgsConstructor
public class ValidationException extends Exception {

    @Getter
    private final List<Violation> violations;
}

اهو سڀني خلاف ورزين جي هڪ فهرست محفوظ ڪري ٿو، Lombok تشريح - Getter لسٽ سان ڳنڍيل آهي، ۽ هڪ ٻي Lombok تشريح ذريعي اسان "لاڳو ڪيو" گهربل تعمير ڪندڙ :) هتي اهو نوٽ ڪرڻ جي قابل آهي ته مان صحيح طريقي سان عمل نٿو ڪري سگهان isValid جي رويي کي. ... طريقو، اهو يا ته صحيح يا استثنا ڏئي ٿو، پر اهو پاڻ کي عام غلط تائين محدود ڪرڻ جي قابل هوندو. استثنا وارو طريقو ٺاهيو ويو آهي ڇاڪاڻ ته مان هن غلطي کي ڪلائنٽ ڏانهن موٽڻ چاهيان ٿو، جنهن جو مطلب آهي ته مون کي بولين طريقي کان صحيح يا غلط کان سواء ٻيو ڪجهه واپس ڪرڻ جي ضرورت آهي. خالص اندروني تصديق جي طريقن جي صورت ۾، استثنا ڏيڻ جي ڪا ضرورت ناهي؛ هتي لاگنگ جي ضرورت پوندي. بهرحال، اچو ته اسان جي EmployeeService ڏانهن واپس وڃون، اسان کي اڃا تائين شيون محفوظ ڪرڻ شروع ڪرڻ جي ضرورت آهي :) اچو ته ڏسون ته هي طبقو هاڻي ڪيئن نظر اچي ٿو:

@Service
@RequiredArgsConstructor
public class EmployeeService {

    private final EmployeeRepository employeeRepository;
    private final ValidationService validationService;

    public List<Employee> getAllEmployees() {
        return employeeRepository.findAll();
    }

    @Transactional
    public void save(Employee employee) throws ValidationException {
        if (validationService.isValidEmployee(employee)) {
            Employee existingEmployee = employeeRepository.findByUniqueNumber(employee.getUniqueNumber());
            if (existingEmployee == null) {
                employeeRepository.save(employee);
            } else {
                existingEmployee = updateFields(existingEmployee, employee);
                employeeRepository.save(existingEmployee);
            }
        }
    }

    private Employee updateFields(Employee existingEmployee, Employee updatedEmployee) {
        return existingEmployee.setDepartment(updatedEmployee.getDepartment())
                               .setSalary(updatedEmployee.getSalary())
            				 //TODO implement tasks merging instead of replacement
                               .setTasks(updatedEmployee.getTasks());
    }
}

نوٽ ڪريو نئين فائنل ملڪيت نجي فائنل ValidationService validationService؛ محفوظ ڪرڻ جو طريقو پاڻ کي @Transactional annotation سان نشان لڳايو ويو آهي ته جيئن جيڪڏهن هڪ RuntimeException ملي وڃي، تبديليون واپس هليون وڃن. سڀ کان پهريان، اسان ايندڙ ڊيٽا کي تصديق ڪريون ٿا خدمت استعمال ڪندي جيڪو اسان لکيو آهي. جيڪڏهن هر شي آسان ٿي وئي، اسان چيڪ ڪريون ٿا ته ڇا ڊيٽابيس ۾ موجود ملازم موجود آهي (هڪ منفرد نمبر استعمال ڪندي). جيڪڏهن نه، اسان نئين کي بچايو، جيڪڏهن هڪ آهي، اسان ڪلاس ۾ فيلڊ کي اپڊيٽ ڪندا آهيون. ها، اسان اصل ۾ ڪيئن چيڪ ڪريون ٿا؟ ها، اهو تمام سادو آهي، اسان ملازمن جي مخزن ۾ هڪ نئون طريقو شامل ڪيو آهي:

public interface EmployeeRepository extends JpaRepository<Employee, Long> {
    Employee findByUniqueNumber(String uniqueNumber);
}

ڇا قابل ذڪر آهي؟ مون ڪو به منطق يا SQL سوال نه لکيو آهي، جيتوڻيڪ اهو هتي موجود آهي. بهار، صرف طريقي جو نالو پڙهڻ سان، اهو طئي ڪري ٿو ته مان ڇا چاهيان ٿو - ڳوليو ByUniqueNumber ۽ طريقي سان لاڳاپيل اسٽرنگ کي پاس ڪريو. فيلڊز کي اپڊيٽ ڪرڻ لاءِ واپسي - هتي مون فيصلو ڪيو عام احساس کي استعمال ڪرڻ ۽ صرف ڊپارٽمينٽ، تنخواه ۽ ڪمن کي اپڊيٽ ڪرڻ، ڇاڪاڻ ته نالو تبديل ڪرڻ، جيتوڻيڪ هڪ قابل قبول شيء آهي، اڃا تائين تمام عام ناهي. ۽ نوڪرين جي تاريخ تبديل ڪرڻ عام طور تي هڪ تڪراري مسئلو آهي. هتي ڇا ڪرڻ سٺو ٿيندو؟ ڪمن جي فهرستن کي گڏ ڪريو، پر جيئن ته اسان وٽ اڃا تائين ڪم نه آهن ۽ نه ڄاڻون ٿا ته انهن ۾ فرق ڪيئن ڪجي، اسان TODO کي ڇڏي ڏينداسين. اچو ته اسان جي Frankenstein کي شروع ڪرڻ جي ڪوشش ڪريو. جيڪڏهن مان ڪجھ به بيان ڪرڻ نه وساريان، اهو ڪم ڪرڻ گهرجي، پر پهرين، هتي ڪلاس جو وڻ آهي جيڪو اسان حاصل ڪيو: ڪلاس جيڪي تبديل ڪيا ويا آهن انهن کي نيري رنگ ۾ نمايان ڪيو ويو آهي، نوان سائي رنگ ۾ نمايان ٿيل آهن، اهڙا اشارا حاصل ڪري سگهجن ٿا جيڪڏهن توهان ڪم ڪيو. هڪ گٽ مخزن سان، پر گٽ اسان جي مضمون جو موضوع ناهي، تنهنڪري اسان ان تي نه رهنداسين. تنهن ڪري، هن وقت اسان وٽ هڪ آخري نقطو آهي جيڪو ٻن طريقن جي حمايت ڪري ٿو GET ۽ POST. رستي جي ذريعي، آخري نقطي بابت ڪجهه دلچسپ معلومات. ڇو، مثال طور، ڇا اسان GET ۽ POST لاءِ الڳ الڳ پوائنٽس مختص نه ڪيا، جيئن getAllEmployees يا CreateEmployees؟ هر شي انتهائي سادو آهي - سڀني درخواستن لاءِ هڪ نقطو هجڻ تمام گهڻو آسان آهي. روئٽنگ HTTP طريقي جي بنياد تي ٿيندي آهي ۽ اهو وجداني آهي، getAllEmployees، getEmployeeByName، حاصل ڪريو... اپڊيٽ... ٺاهيو... حذف ڪريو... اچو ته جانچ ڪريون ته اسان کي ڇا مليو. مون اڳ ۾ ئي اڳئين مضمون ۾ لکيو آهي ته اسان کي پوسٽمن جي ضرورت پوندي، ۽ اهو ان کي انسٽال ڪرڻ جو وقت آهي. پروگرام انٽرفيس ۾، اسان هڪ نئين پوسٽ جي درخواست ٺاهي ۽ ان کي موڪلڻ جي ڪوشش ڪريو. جيڪڏهن سڀ ڪجهه ٺيڪ ٿي ويو ته اسان حاصل ڪنداسين اسٽيٽس 201 اسڪرين جي ساڄي پاسي. پر مثال طور، هڪ ئي شيءِ موڪلڻ کان سواءِ هڪ منفرد نمبر (جنهن تي اسان وٽ تصديق آهي)، مون کي هڪ مختلف جواب ملي ٿو: خير، اچو ته ڏسون ته اسان جي مڪمل چونڊ ڪيئن ڪم ڪري ٿي - اسان هڪ GET طريقو ٺاهينداسين ساڳئي آخري نقطي لاءِ ۽ ان کي موڪليو. . مون کي خلوص سان اميد آهي ته سڀ ڪجهه توهان لاءِ ڪم ڪيو آهي جيئن اهو مون لاءِ ڪيو هو، ۽ توهان کي ايندڙ مضمون ۾ ڏسندا .