ਸਪਰਿੰਗ ਬੂਟ ਵਿੱਚ ਇੱਕ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਡਿਲੀਟ ਐਂਡਪੁਆਇੰਟ ਤਿਆਰ ਕਰਨਾ
ਸਪਰਿੰਗ ਬੂਟ ਵਿੱਚ ਇੱਕ ਆਰਾਮਦਾਇਕ API ਡਿਜ਼ਾਈਨ ਕਰਨਾ ਅਕਸਰ ਇੱਕ ਗੁੰਝਲਦਾਰ ਬੁਝਾਰਤ ਨੂੰ ਸੁਲਝਾਉਣ ਵਰਗਾ ਮਹਿਸੂਸ ਹੁੰਦਾ ਹੈ, ਖਾਸ ਕਰਕੇ ਜਦੋਂ ਤੁਸੀਂ ਗੈਰ-ਰਵਾਇਤੀ ਲੋੜਾਂ ਦਾ ਸਾਹਮਣਾ ਕਰਦੇ ਹੋ। ਇਸ ਦ੍ਰਿਸ਼ ਦੀ ਕਲਪਨਾ ਕਰੋ: ਤੁਹਾਨੂੰ `user_mail_address` ਸਾਰਣੀ ਵਿੱਚ ਇੱਕ ਈਮੇਲ ਪਤਾ ਸਾਫਟ-ਮਿਟਾਉਣ ਲਈ ਇੱਕ DELETE ਐਂਡਪੁਆਇੰਟ ਬਣਾਉਣ ਦਾ ਕੰਮ ਸੌਂਪਿਆ ਗਿਆ ਹੈ। ਸਧਾਰਨ ਲੱਗਦਾ ਹੈ, ਠੀਕ ਹੈ? ਪਰ ਇੱਕ ਕੈਚ ਹੈ—ਤੁਸੀਂ ਸਿਰਫ਼ ਈਮੇਲ ਪਤੇ ਦੀ ਵਰਤੋਂ ਕਰ ਸਕਦੇ ਹੋ, ਨਾ ਕਿ ਇਸਦੀ ਆਈ.ਡੀ. 🤔
ਇਹ ਇੱਕ ਮਹੱਤਵਪੂਰਨ ਸਵਾਲ ਲਿਆਉਂਦਾ ਹੈ: ਤੁਹਾਨੂੰ ਈਮੇਲ ਪਤਾ ਕਿੱਥੇ ਰੱਖਣਾ ਚਾਹੀਦਾ ਹੈ? ਕੀ ਇਹ ਬੇਨਤੀ ਦੇ ਭਾਗ ਵਿੱਚ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ, ਭਾਵੇਂ ਕਿ DELETE ਵਿਧੀਆਂ ਰਵਾਇਤੀ ਤੌਰ 'ਤੇ ਬੇਨਤੀ ਪੇਲੋਡ ਤੋਂ ਬਚਦੀਆਂ ਹਨ? ਜਾਂ ਕੀ ਤੁਹਾਨੂੰ URL ਵਿੱਚ ਸੰਵੇਦਨਸ਼ੀਲ ਡੇਟਾ ਨੂੰ ਉਜਾਗਰ ਕਰਦੇ ਹੋਏ, ਪੁੱਛਗਿੱਛ ਦੇ ਪੈਰਾਮੀਟਰਾਂ ਵਿੱਚ ਸ਼ਾਮਲ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ? ਦੋਵੇਂ ਵਿਕਲਪ ਵਿਲੱਖਣ ਚੁਣੌਤੀਆਂ ਅਤੇ ਜੋਖਮ ਪੇਸ਼ ਕਰਦੇ ਹਨ।
ਇੱਕ ਡਿਵੈਲਪਰ ਦੇ ਰੂਪ ਵਿੱਚ, ਇਹ ਦੁਬਿਧਾਵਾਂ HTTP ਸੰਮੇਲਨਾਂ ਦੀ ਪਾਲਣਾ ਕਰਨ ਅਤੇ ਸੁਰੱਖਿਆ ਦੇ ਵਧੀਆ ਅਭਿਆਸਾਂ ਨੂੰ ਕਾਇਮ ਰੱਖਣ ਦੇ ਵਿਚਕਾਰ ਸੰਤੁਲਨ ਕਾਰਜ ਨੂੰ ਉਜਾਗਰ ਕਰਦੀਆਂ ਹਨ। ਗਲਤ ਚੋਣ ਕਰਨ ਨਾਲ ਨਾ ਸਿਰਫ਼ ਪਰੰਪਰਾਵਾਂ ਨੂੰ ਤੋੜਿਆ ਜਾ ਸਕਦਾ ਹੈ ਬਲਕਿ ਉਪਭੋਗਤਾ ਡੇਟਾ ਦੀ ਸੁਰੱਖਿਆ ਨਾਲ ਸਮਝੌਤਾ ਵੀ ਹੋ ਸਕਦਾ ਹੈ। ⚠️
ਇਸ ਲੇਖ ਵਿੱਚ, ਅਸੀਂ ਇਹਨਾਂ ਵਿਕਲਪਾਂ ਦੀ ਪੜਚੋਲ ਕਰਾਂਗੇ, ਉਹਨਾਂ ਦੇ ਵਪਾਰ ਦਾ ਮੁਲਾਂਕਣ ਕਰਾਂਗੇ, ਅਤੇ ਇੱਕ ਵਿਕਲਪਿਕ ਪਹੁੰਚ ਦਾ ਪਤਾ ਲਗਾਵਾਂਗੇ ਜੋ ਆਰਾਮਦੇਹ ਸਿਧਾਂਤਾਂ ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਹੈ। ਅੰਤ ਤੱਕ, ਤੁਹਾਡੇ ਕੋਲ ਤੁਹਾਡੀ ਸਪਰਿੰਗ ਬੂਟ ਐਪਲੀਕੇਸ਼ਨ ਲਈ ਇੱਕ ਸੁਰੱਖਿਅਤ ਅਤੇ ਸਾਫ਼ DELETE ਅੰਤਮ ਬਿੰਦੂ ਨੂੰ ਲਾਗੂ ਕਰਨ ਲਈ ਇੱਕ ਸਪਸ਼ਟ ਮਾਰਗ ਹੋਵੇਗਾ। 🚀
ਹੁਕਮ | ਵਰਤੋਂ ਦੀ ਉਦਾਹਰਨ |
---|---|
@DeleteMapping | ਨਿਸ਼ਚਿਤ ਕਰਦਾ ਹੈ ਕਿ ਵਿਧੀ HTTP ਮਿਟਾਉਣ ਦੀਆਂ ਬੇਨਤੀਆਂ ਨੂੰ ਸੰਭਾਲਦੀ ਹੈ। ਇਹ ਕੰਟਰੋਲਰ ਵਿੱਚ DELETE ਕਾਰਵਾਈ ਲਈ ਅੰਤਮ ਬਿੰਦੂ URL ਨੂੰ ਮੈਪ ਕਰਨ ਲਈ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ। ਉਦਾਹਰਨ: @DeleteMapping("/user/email")। |
@RequestParam | URL ਤੋਂ ਇੱਕ ਵਿਧੀ ਪੈਰਾਮੀਟਰ ਨਾਲ ਪੁੱਛਗਿੱਛ ਪੈਰਾਮੀਟਰਾਂ ਨੂੰ ਜੋੜਦਾ ਹੈ। ਇਹ URL ਵਿੱਚ ਈਮੇਲ ਪਤਾ ਪਾਸ ਕਰਨ ਵੇਲੇ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ। ਉਦਾਹਰਨ: ਪਬਲਿਕ ResponseEntity |
@RequestBody | HTTP ਬੇਨਤੀ ਬਾਡੀ ਨੂੰ ਇੱਕ ਵਿਧੀ ਪੈਰਾਮੀਟਰ ਨਾਲ ਮੈਪ ਕਰਦਾ ਹੈ, ਜੋ ਆਮ ਤੌਰ 'ਤੇ POST ਜਾਂ PUT ਬੇਨਤੀਆਂ ਲਈ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ ਪਰ ਕਦੇ-ਕਦਾਈਂ ਪੇਲੋਡ ਡੇਟਾ ਲਈ DELETE ਬੇਨਤੀਆਂ ਵਿੱਚ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ। ਉਦਾਹਰਨ: ਪਬਲਿਕ ResponseEntity |
ResponseEntity | ਇੱਕ ਸਪਰਿੰਗ ਕਲਾਸ HTTP ਜਵਾਬਾਂ ਨੂੰ ਦਰਸਾਉਣ ਲਈ ਵਰਤੀ ਜਾਂਦੀ ਹੈ, ਜਿਸ ਵਿੱਚ ਸਟੇਟਸ ਕੋਡ, ਹੈਡਰ ਅਤੇ ਬਾਡੀ ਸ਼ਾਮਲ ਹੈ। ਉਦਾਹਰਨ: ResponseEntity.ok("ਸਫਲਤਾ"); |
MockMvc | ਸਪਰਿੰਗ ਦੀ ਟੈਸਟਿੰਗ ਲਾਇਬ੍ਰੇਰੀ ਦਾ ਹਿੱਸਾ, HTTP ਬੇਨਤੀਆਂ ਦੀ ਨਕਲ ਕਰਕੇ MVC ਕੰਟਰੋਲਰਾਂ ਦੀ ਜਾਂਚ ਕਰਨ ਲਈ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ। ਉਦਾਹਰਨ: mockMvc.perform(delete("/user/email?email=test@example.com")).andExpect(status().isOk());। |
.perform() | MockMvc ਦੀ ਇੱਕ ਵਿਧੀ ਟੈਸਟਾਂ ਵਿੱਚ ਇੱਕ HTTP ਬੇਨਤੀ ਨੂੰ ਚਲਾਉਣ ਲਈ ਵਰਤੀ ਜਾਂਦੀ ਹੈ। ਉਦਾਹਰਨ: mockMvc.perform(delete("/user/email"))। |
@WebMvcTest | ਨਿਯੰਤਰਕਾਂ ਅਤੇ ਉਹਨਾਂ ਦੇ ਵਿਵਹਾਰ 'ਤੇ ਕੇਂਦ੍ਰਤ ਕਰਦੇ ਹੋਏ, ਐਪਲੀਕੇਸ਼ਨ ਦੀ ਸਿਰਫ ਵੈਬ ਪਰਤ ਦੀ ਜਾਂਚ ਕਰਨ ਲਈ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ। ਉਦਾਹਰਨ: @WebMvcTest(UserController.class)। |
.andExpect() | ਇੱਕ HTTP ਬੇਨਤੀ ਦੇ ਜਵਾਬ ਦੀ ਪੁਸ਼ਟੀ ਕਰਨ ਲਈ MockMvc ਟੈਸਟਿੰਗ ਵਿੱਚ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ। ਉਦਾਹਰਨ: .andExpect(status().isOk())। |
.content() | MockMvc ਟੈਸਟਾਂ ਵਿੱਚ ਇੱਕ ਬੇਨਤੀ ਦਾ ਮੁੱਖ ਭਾਗ ਸੈੱਟ ਕਰਦਾ ਹੈ, ਅਕਸਰ JSON ਜਾਂ ਹੋਰ ਪੇਲੋਡਾਂ ਦੀ ਲੋੜ ਵਾਲੀਆਂ ਬੇਨਤੀਆਂ ਲਈ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ। ਉਦਾਹਰਨ: .content("{"email":"test@example.com"}")। |
.status() | MockMvc ਟੈਸਟਾਂ ਵਿੱਚ HTTP ਜਵਾਬ ਸਥਿਤੀ ਨੂੰ ਪ੍ਰਮਾਣਿਤ ਕਰਦਾ ਹੈ। ਉਦਾਹਰਨ: .andExpect(status().isOk())। |
ਸਪਰਿੰਗ ਬੂਟ ਵਿੱਚ ਡੀਲੀਟ ਐਂਡਪੁਆਇੰਟ ਨੂੰ ਲਾਗੂ ਕਰਨ ਨੂੰ ਸਮਝਣਾ
ਪਹਿਲੀ ਸਕ੍ਰਿਪਟ ਮਿਟਾਉਣ ਦੀ ਬੇਨਤੀ ਲਈ ਈਮੇਲ ਪਤੇ ਨੂੰ ਸੰਭਾਲਣ ਲਈ ਪੁੱਛਗਿੱਛ ਪੈਰਾਮੀਟਰਾਂ ਦੀ ਵਰਤੋਂ ਕਰਦੀ ਹੈ। ਇਹ ਪਹੁੰਚ ਅੰਤਮ ਬਿੰਦੂ ਨੂੰ ਸਾਫ਼ ਅਤੇ ਸਿੱਧਾ ਰੱਖ ਕੇ ਆਰਾਮਦੇਹ ਸਿਧਾਂਤਾਂ ਨਾਲ ਮੇਲ ਖਾਂਦੀ ਹੈ। ਹੁਕਮ @RequestParam ਇੱਥੇ ਮਹੱਤਵਪੂਰਨ ਹੈ ਕਿਉਂਕਿ ਇਹ URL ਤੋਂ ਵਿਧੀ ਦੇ ਆਰਗੂਮੈਂਟ ਨਾਲ ਪੁੱਛਗਿੱਛ ਪੈਰਾਮੀਟਰ "ਈਮੇਲ" ਨੂੰ ਜੋੜਦਾ ਹੈ। ਉਦਾਹਰਨ ਲਈ, ਜਦੋਂ ਇੱਕ ਗਾਹਕ ਕਾਲ ਕਰਦਾ ਹੈ /user/email?email=test@example.com, ਕੰਟਰੋਲਰ ਈਮੇਲ ਪੈਰਾਮੀਟਰ ਨੂੰ ਸਿੱਧੇ ਤੌਰ 'ਤੇ ਪ੍ਰਕਿਰਿਆ ਕਰਦਾ ਹੈ। ਇਹ ਵਿਧੀ ਲਾਗੂ ਕਰਨ ਲਈ ਸਧਾਰਨ ਹੈ ਪਰ URL ਵਿੱਚ ਸੰਵੇਦਨਸ਼ੀਲ ਜਾਣਕਾਰੀ ਨੂੰ ਉਜਾਗਰ ਕਰਨ ਤੋਂ ਰੋਕਣ ਲਈ ਧਿਆਨ ਨਾਲ ਪ੍ਰਬੰਧਨ ਦੀ ਲੋੜ ਹੈ। 🌐
ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਦੂਜੀ ਸਕ੍ਰਿਪਟ ਇੱਕ ਵੱਖਰਾ ਮਾਰਗ ਲੈਂਦੀ ਹੈ @RequestBody ਬੇਨਤੀ ਪੇਲੋਡ ਵਿੱਚ ਈਮੇਲ ਪਤਾ ਪਾਸ ਕਰਨ ਲਈ ਐਨੋਟੇਸ਼ਨ। ਹਾਲਾਂਕਿ ਇਹ ਮਿਟਾਉਣ ਦੇ ਤਰੀਕਿਆਂ ਲਈ ਰਵਾਇਤੀ ਨਹੀਂ ਹੈ, ਇਹ ਗੋਪਨੀਯਤਾ ਦੀ ਇੱਕ ਪਰਤ ਜੋੜਦਾ ਹੈ ਕਿਉਂਕਿ ਈਮੇਲ URL ਵਿੱਚ ਪ੍ਰਦਰਸ਼ਿਤ ਨਹੀਂ ਹੁੰਦੀ ਹੈ। ਕੰਟਰੋਲਰ ਪੇਲੋਡ ਨੂੰ ਕਿਸੇ ਵਸਤੂ ਵਿੱਚ ਡੀਸੀਰੀਅਲਾਈਜ਼ ਕਰਦਾ ਹੈ, ਜਿਸ ਨਾਲ ਬੇਨਤੀ ਦੀ ਬਣਤਰ ਅਤੇ ਸਮੱਗਰੀ ਨੂੰ ਪ੍ਰਮਾਣਿਤ ਕਰਨਾ ਆਸਾਨ ਹੋ ਜਾਂਦਾ ਹੈ। ਉਦਾਹਰਨ ਲਈ, ਇੱਕ ਕਲਾਇੰਟ ਇੱਕ JSON ਪੇਲੋਡ ਭੇਜ ਸਕਦਾ ਹੈ ਜਿਵੇਂ {"ਈਮੇਲ":"test@example.com"}, ਜੋ ਯਕੀਨੀ ਬਣਾਉਂਦਾ ਹੈ ਕਿ ਈਮੇਲ ਸੁਰੱਖਿਅਤ ਰਹੇ। ਹਾਲਾਂਕਿ, ਇਹ ਵਿਧੀ REST ਮਾਪਦੰਡਾਂ ਤੋਂ ਥੋੜ੍ਹਾ ਵੱਖਰਾ ਹੈ, ਜੋ ਸ਼ੁੱਧਵਾਦੀਆਂ ਲਈ ਚਿੰਤਾ ਕਰ ਸਕਦਾ ਹੈ। 🛡️
ਇਹ ਸੁਨਿਸ਼ਚਿਤ ਕਰਨ ਲਈ ਕਿ ਇਹ ਲਾਗੂਕਰਨ ਭਰੋਸੇਯੋਗਤਾ ਨਾਲ ਕੰਮ ਕਰਦੇ ਹਨ, ਜਵਾਬਦੇਹੀ ਕਲਾਸ ਨੂੰ HTTP ਜਵਾਬਾਂ ਨੂੰ ਸੰਭਾਲਣ ਲਈ ਨਿਯੁਕਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਇਹ ਕਲਾਸ ਰਿਸਪਾਂਸ ਬਾਡੀ, ਸਟੇਟਸ ਕੋਡ ਅਤੇ ਸਿਰਲੇਖਾਂ ਨੂੰ ਗਤੀਸ਼ੀਲ ਰੂਪ ਵਿੱਚ ਕੌਂਫਿਗਰ ਕਰਨ ਦੀ ਆਗਿਆ ਦੇ ਕੇ ਲਚਕਤਾ ਦੀ ਪੇਸ਼ਕਸ਼ ਕਰਦਾ ਹੈ। ਉਦਾਹਰਨ ਲਈ, ਦੋਨੋਂ ਸਕ੍ਰਿਪਟਾਂ ਵਿੱਚ, ਜੇਕਰ ਈਮੇਲ ਸਫਲਤਾਪੂਰਵਕ "ਸਾਫਟ-ਡਿਲੀਟ" ਹੋ ਗਈ ਹੈ, ਤਾਂ ਸਰਵਰ 200 ਠੀਕ ਸਥਿਤੀ ਅਤੇ ਇੱਕ ਸਫਲਤਾ ਸੰਦੇਸ਼ ਦੇ ਨਾਲ ਜਵਾਬ ਦਿੰਦਾ ਹੈ। ਜੇਕਰ ਈਮੇਲ ਮੌਜੂਦ ਨਹੀਂ ਹੈ, ਤਾਂ ਸਰਵਰ ਇੱਕ 404 ਨਹੀਂ ਮਿਲਿਆ ਸਥਿਤੀ ਵਾਪਸ ਕਰਦਾ ਹੈ, ਗਾਹਕ ਲਈ ਅਰਥਪੂਰਨ ਫੀਡਬੈਕ ਨੂੰ ਯਕੀਨੀ ਬਣਾਉਂਦਾ ਹੈ।
ਮਜ਼ਬੂਤੀ ਦੀ ਗਾਰੰਟੀ ਦੇਣ ਲਈ ਇਹਨਾਂ ਅੰਤਮ ਬਿੰਦੂਆਂ ਦੀ ਜਾਂਚ ਕਰਨਾ ਜ਼ਰੂਰੀ ਹੈ। ਪ੍ਰਦਾਨ ਕੀਤੇ ਯੂਨਿਟ ਟੈਸਟਾਂ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਨ MockMvc HTTP ਬੇਨਤੀਆਂ ਦੀ ਨਕਲ ਕਰਨ ਅਤੇ ਕੰਟਰੋਲਰ ਦੇ ਵਿਵਹਾਰ ਨੂੰ ਪ੍ਰਮਾਣਿਤ ਕਰਨ ਲਈ ਫਰੇਮਵਰਕ। ਵਰਗੇ ਹੁਕਮ .perform() ਅਤੇ .andExpect() ਇਸ ਪ੍ਰਕਿਰਿਆ ਵਿੱਚ ਮਹੱਤਵਪੂਰਨ ਹਨ, ਡਿਵੈਲਪਰਾਂ ਨੂੰ ਇਹ ਯਕੀਨੀ ਬਣਾਉਣ ਲਈ ਸਮਰੱਥ ਬਣਾਉਂਦੇ ਹਨ ਕਿ ਪੁੱਛਗਿੱਛ ਪੈਰਾਮੀਟਰ ਅਤੇ ਬੇਨਤੀ ਬਾਡੀ ਪਹੁੰਚ ਬੇਨਤੀਆਂ ਨੂੰ ਸਹੀ ਢੰਗ ਨਾਲ ਸੰਭਾਲਦੇ ਹਨ। ਉਦਾਹਰਨ ਲਈ, ਟੈਸਟ ਜਾਂਚ ਕਰਦਾ ਹੈ ਕਿ ਕੀ ਪੁੱਛਗਿੱਛ ਪੈਰਾਮੀਟਰ ਵਿੱਚ ਇੱਕ ਖਾਸ ਈਮੇਲ ਦੇ ਨਾਲ ਮਿਟਾਉਣ ਦੀ ਬੇਨਤੀ ਜਾਂ ਸਰੀਰ ਦੇ ਨਤੀਜੇ ਸੰਭਾਵਿਤ ਸਥਿਤੀ ਕੋਡ ਅਤੇ ਸੰਦੇਸ਼ ਵਿੱਚ ਆਉਂਦੇ ਹਨ। ਇਹਨਾਂ ਦ੍ਰਿਸ਼ਾਂ ਦੀ ਚੰਗੀ ਤਰ੍ਹਾਂ ਜਾਂਚ ਕਰਕੇ, ਡਿਵੈਲਪਰ ਭਰੋਸੇ ਨਾਲ ਸੁਰੱਖਿਅਤ ਅਤੇ ਕਾਰਜਸ਼ੀਲ ਅੰਤ ਬਿੰਦੂਆਂ ਨੂੰ ਤੈਨਾਤ ਕਰ ਸਕਦੇ ਹਨ। 🚀
ਸਪਰਿੰਗ ਬੂਟ ਵਿੱਚ ਅੰਤਮ ਬਿੰਦੂ ਮਿਟਾਉਣ ਲਈ ਪੁੱਛਗਿੱਛ ਪੈਰਾਮੀਟਰਾਂ ਦੀ ਵਰਤੋਂ ਕਰਨਾ
ਇਹ ਪਹੁੰਚ ਦਰਸਾਉਂਦੀ ਹੈ ਕਿ ਸਪਰਿੰਗ ਬੂਟ ਡਿਲੀਟ ਐਂਡਪੁਆਇੰਟ ਨੂੰ ਈਮੇਲ ਪਤਾ ਪਾਸ ਕਰਨ ਲਈ ਪੁੱਛਗਿੱਛ ਪੈਰਾਮੀਟਰਾਂ ਦੀ ਵਰਤੋਂ ਕਿਵੇਂ ਕਰਨੀ ਹੈ। ਇਹ ਵਿਧੀ REST ਸਿਧਾਂਤਾਂ ਦੀ ਪਾਲਣਾ ਕਰਦੀ ਹੈ ਪਰ ਇਹ ਯਕੀਨੀ ਬਣਾਉਣ ਲਈ ਸਾਵਧਾਨੀ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ ਕਿ ਸੰਵੇਦਨਸ਼ੀਲ ਡੇਟਾ ਨੂੰ ਸੁਰੱਖਿਅਤ ਢੰਗ ਨਾਲ ਸੰਭਾਲਿਆ ਜਾਵੇ।
// Import necessary packages
import org.springframework.http.ResponseEntity;
import org.springframework.web.bind.annotation.DeleteMapping;
import org.springframework.web.bind.annotation.RequestParam;
import org.springframework.web.bind.annotation.RestController;
@RestController
public class UserController {
// Inject UserService for business logic
private final UserService userService;
public UserController(UserService userService) {
this.userService = userService;
}
// Endpoint to soft-delete email address
@DeleteMapping("/user/email")
public ResponseEntity<String> softDeleteEmail(@RequestParam("email") String email) {
boolean isDeleted = userService.softDeleteByEmail(email);
if (isDeleted) {
return ResponseEntity.ok("Email address soft-deleted successfully.");
} else {
return ResponseEntity.status(404).body("Email address not found.");
}
}
}
// Service logic
public class UserService {
public boolean softDeleteByEmail(String email) {
// Simulate database operation
// Update 'status' column to 0 where email matches
// Return true if operation succeeds
return true;
}
}
ਸਪਰਿੰਗ ਬੂਟ ਵਿੱਚ ਅੰਤਮ ਬਿੰਦੂ ਮਿਟਾਉਣ ਲਈ ਬੇਨਤੀ ਬਾਡੀ ਦੀ ਵਰਤੋਂ ਕਰਨਾ
ਇਹ ਪਹੁੰਚ ਈਮੇਲ ਪਤਾ ਪਾਸ ਕਰਨ ਲਈ ਬੇਨਤੀ ਬਾਡੀ ਦੀ ਵਰਤੋਂ ਕਰਦੀ ਹੈ। DELETE ਵਿਧੀਆਂ ਲਈ ਗੈਰ-ਰਵਾਇਤੀ ਹੋਣ ਦੇ ਬਾਵਜੂਦ, ਇਹ ਯਕੀਨੀ ਬਣਾਉਂਦਾ ਹੈ ਕਿ ਈਮੇਲ URL ਵਿੱਚ ਪ੍ਰਗਟ ਨਹੀਂ ਹੋਈ ਹੈ। ਉਚਿਤ ਪ੍ਰਮਾਣਿਕਤਾ ਇੱਥੇ ਮਹੱਤਵਪੂਰਨ ਹੈ।
// Import necessary packages
import org.springframework.http.ResponseEntity;
import org.springframework.web.bind.annotation.DeleteMapping;
import org.springframework.web.bind.annotation.RequestBody;
import org.springframework.web.bind.annotation.RestController;
@RestController
public class UserController {
// Inject UserService for business logic
private final UserService userService;
public UserController(UserService userService) {
this.userService = userService;
}
// Endpoint to soft-delete email address
@DeleteMapping("/user/email")
public ResponseEntity<String> softDeleteEmail(@RequestBody EmailRequest emailRequest) {
boolean isDeleted = userService.softDeleteByEmail(emailRequest.getEmail());
if (isDeleted) {
return ResponseEntity.ok("Email address soft-deleted successfully.");
} else {
return ResponseEntity.status(404).body("Email address not found.");
}
}
}
// Request Body Model
public class EmailRequest {
private String email;
// Getters and setters
public String getEmail() {
return email;
}
public void setEmail(String email) {
this.email = email;
}
}
// Service logic
public class UserService {
public boolean softDeleteByEmail(String email) {
// Simulate database operation
// Update 'status' column to 0 where email matches
// Return true if operation succeeds
return true;
}
}
ਯੂਨਿਟ ਟੈਸਟਿੰਗ ਐਂਡਪੁਆਇੰਟ
ਇਹ ਸਕ੍ਰਿਪਟ ਦੋਵਾਂ ਲਾਗੂਕਰਨਾਂ ਨੂੰ ਪ੍ਰਮਾਣਿਤ ਕਰਨ ਲਈ JUnit ਅਤੇ MockMvc ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ DELETE ਐਂਡਪੁਆਇੰਟ ਲਈ ਯੂਨਿਟ ਟੈਸਟ ਪ੍ਰਦਾਨ ਕਰਦੀ ਹੈ।
// Import packages
import org.junit.jupiter.api.Test;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.boot.test.autoconfigure.web.servlet.WebMvcTest;
import org.springframework.test.web.servlet.MockMvc;
import static org.springframework.test.web.servlet.request.MockMvcRequestBuilders.delete;
import static org.springframework.test.web.servlet.result.MockMvcResultMatchers.status;
@WebMvcTest(UserController.class)
public class UserControllerTest {
@Autowired
private MockMvc mockMvc;
@Test
public void testSoftDeleteByQueryParam() throws Exception {
mockMvc.perform(delete("/user/email?email=test@example.com"))
.andExpect(status().isOk());
}
@Test
public void testSoftDeleteByRequestBody() throws Exception {
String jsonBody = "{\"email\":\"test@example.com\"}";
mockMvc.perform(delete("/user/email")
.contentType("application/json")
.content(jsonBody))
.andExpect(status().isOk());
}
}
ਡਿਲੀਟ ਐਂਡਪੁਆਇੰਟਸ ਵਿੱਚ ਸੁਰੱਖਿਆ ਅਤੇ ਆਰਾਮਦਾਇਕ ਅਭਿਆਸਾਂ ਨੂੰ ਸੰਤੁਲਿਤ ਕਰਨਾ
ਸਪਰਿੰਗ ਬੂਟ ਵਿੱਚ ਇੱਕ ਡਿਲੀਟ ਐਂਡਪੁਆਇੰਟ ਨੂੰ ਡਿਜ਼ਾਈਨ ਕਰਨ ਵੇਲੇ ਵਿਚਾਰਨ ਲਈ ਇੱਕ ਮਹੱਤਵਪੂਰਨ ਪਹਿਲੂ ਇਹ ਹੈ ਕਿ ਇਹ ਸੁਰੱਖਿਆ ਪ੍ਰੋਟੋਕੋਲਾਂ ਨਾਲ ਕਿਵੇਂ ਏਕੀਕ੍ਰਿਤ ਹੁੰਦਾ ਹੈ। ਜਦੋਂ ਇੱਕ ਈਮੇਲ ਪਤਾ ਇੱਕ ਪੁੱਛਗਿੱਛ ਪੈਰਾਮੀਟਰ ਵਿੱਚ ਪ੍ਰਗਟ ਹੁੰਦਾ ਹੈ, ਜਿਵੇਂ ਕਿ ਵਿੱਚ /user/email?email=test@example.com, ਇਸ ਨੂੰ ਸਰਵਰ ਐਕਸੈਸ ਲੌਗਸ ਵਿੱਚ ਲੌਗਇਨ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ ਜਾਂ ਬ੍ਰਾਊਜ਼ਰ ਇਤਿਹਾਸ ਵਿੱਚ ਵੀ ਕੈਸ਼ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ। ਇਸ ਨੂੰ ਘਟਾਉਣ ਲਈ, ਡਿਵੈਲਪਰ HTTPS ਦੀ ਵਰਤੋਂ ਕਰ ਸਕਦੇ ਹਨ, ਇਹ ਯਕੀਨੀ ਬਣਾਉਂਦੇ ਹੋਏ ਕਿ ਸੰਚਾਰ ਦੌਰਾਨ ਈਮੇਲ ਪਤਾ ਐਨਕ੍ਰਿਪਟ ਕੀਤਾ ਗਿਆ ਹੈ। ਇਸ ਤੋਂ ਇਲਾਵਾ, ਲਾਗਿੰਗ ਫਿਲਟਰਾਂ ਨੂੰ ਲਾਗੂ ਕਰਨਾ ਜੋ ਲੌਗਸ ਤੋਂ ਸੰਵੇਦਨਸ਼ੀਲ ਡੇਟਾ ਨੂੰ ਸੋਧਦੇ ਹਨ, ਉਪਭੋਗਤਾ ਦੀ ਗੋਪਨੀਯਤਾ ਨੂੰ ਹੋਰ ਸੁਰੱਖਿਅਤ ਕਰ ਸਕਦੇ ਹਨ। 🔒
ਇਕ ਹੋਰ ਪਹਿਲੂ ਇਨਪੁਟ ਪ੍ਰਮਾਣਿਕਤਾ ਹੈ। ਭਾਵੇਂ ਈਮੇਲ ਪਤਾ ਬੇਨਤੀ ਬਾਡੀ ਜਾਂ ਪੁੱਛਗਿੱਛ ਪੈਰਾਮੀਟਰਾਂ ਰਾਹੀਂ ਪਾਸ ਕੀਤਾ ਗਿਆ ਹੈ, ਸਰਵਰ ਨੂੰ ਅਵੈਧ ਬੇਨਤੀਆਂ ਨੂੰ ਰੋਕਣ ਲਈ ਇਸਦੇ ਫਾਰਮੈਟ ਨੂੰ ਪ੍ਰਮਾਣਿਤ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ। ਅਪਾਚੇ ਕਾਮਨਜ਼ ਵੈਲੀਡੇਟਰ ਵਰਗੀਆਂ ਲਾਇਬ੍ਰੇਰੀਆਂ ਦੀ ਵਰਤੋਂ ਕਰਨਾ ਜਾਂ ਰੀਜੈਕਸ-ਅਧਾਰਿਤ ਪ੍ਰਮਾਣਿਕਤਾ ਨੂੰ ਲਾਗੂ ਕਰਨਾ ਇਹ ਯਕੀਨੀ ਬਣਾਉਂਦਾ ਹੈ ਕਿ ਇਨਪੁਟ ਨੂੰ ਪ੍ਰਕਿਰਿਆ ਕੀਤੇ ਜਾਣ ਤੋਂ ਪਹਿਲਾਂ ਰੋਗਾਣੂ-ਮੁਕਤ ਕੀਤਾ ਗਿਆ ਹੈ। ਉਦਾਹਰਨ ਲਈ, ਜੇਕਰ "ਨਟ-ਐਨ-ਈ-ਮੇਲ" ਵਰਗੀ ਇੱਕ ਅਵੈਧ ਈਮੇਲ ਭੇਜੀ ਜਾਂਦੀ ਹੈ, ਤਾਂ ਸਰਵਰ ਨੂੰ ਇੱਕ ਮਦਦਗਾਰ ਸੰਦੇਸ਼ ਦੇ ਨਾਲ ਇੱਕ 400 ਖਰਾਬ ਬੇਨਤੀ ਜਵਾਬ ਵਾਪਸ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ।
ਅੰਤ ਵਿੱਚ, DELETE ਅੰਤਮ ਬਿੰਦੂ ਦੇ ਨਾਲ ਟੋਕਨ-ਅਧਾਰਿਤ ਅਧਿਕਾਰ ਦੀ ਵਰਤੋਂ ਕਰਨ 'ਤੇ ਵਿਚਾਰ ਕਰੋ। JSON Web Tokens (JWT) ਜਾਂ OAuth ਵਰਗੇ ਟੂਲ ਇਹ ਯਕੀਨੀ ਬਣਾ ਸਕਦੇ ਹਨ ਕਿ ਸਿਰਫ਼ ਪ੍ਰਮਾਣਿਤ ਅਤੇ ਅਧਿਕਾਰਤ ਵਰਤੋਂਕਾਰ ਹੀ ਬਦਲਾਅ ਕਰ ਸਕਦੇ ਹਨ। ਉਦਾਹਰਨ ਲਈ, ਜੇਕਰ ਕੋਈ ਪ੍ਰਸ਼ਾਸਕ ਇੱਕ ਈਮੇਲ "ਸਾਫਟ-ਮਿਟਾਉਣ" ਲਈ DELETE ਬੇਨਤੀ ਨੂੰ ਚਾਲੂ ਕਰਦਾ ਹੈ, ਤਾਂ ਉਹਨਾਂ ਦੇ ਟੋਕਨ ਵਿੱਚ ਇੱਕ ਭੂਮਿਕਾ ਦਾ ਦਾਅਵਾ ਸ਼ਾਮਲ ਹੋ ਸਕਦਾ ਹੈ, ਜਿਸ ਨਾਲ ਬੈਕਐਂਡ ਉਹਨਾਂ ਦੇ ਵਿਸ਼ੇਸ਼ ਅਧਿਕਾਰਾਂ ਦੀ ਪੁਸ਼ਟੀ ਕਰ ਸਕਦਾ ਹੈ। ਇਹ ਅੰਤਮ ਬਿੰਦੂ ਦੀ ਸਾਦਗੀ ਨੂੰ ਕਾਇਮ ਰੱਖਦੇ ਹੋਏ ਨਿਯੰਤਰਣ ਦੀ ਇੱਕ ਪਰਤ ਜੋੜਦਾ ਹੈ। 🚀
DELETE Endpoints ਬਾਰੇ ਅਕਸਰ ਪੁੱਛੇ ਜਾਂਦੇ ਸਵਾਲ
- DELETE ਐਂਡਪੁਆਇੰਟ ਨੂੰ ਸੁਰੱਖਿਅਤ ਕਰਨ ਦਾ ਸਭ ਤੋਂ ਵਧੀਆ ਤਰੀਕਾ ਕੀ ਹੈ?
- ਸੰਵੇਦਨਸ਼ੀਲ ਡੇਟਾ ਐਕਸਪੋਜ਼ਰ ਤੋਂ ਬਚਣ ਲਈ ਸੁਰੱਖਿਅਤ ਸੰਚਾਰ ਅਤੇ ਲੌਗ ਰੀਡੈਕਸ਼ਨ ਫਿਲਟਰਾਂ ਲਈ HTTPS ਦੀ ਵਰਤੋਂ ਕਰੋ। ਟੋਕਨ-ਅਧਾਰਿਤ ਪ੍ਰਮਾਣਿਕਤਾ 'ਤੇ ਵਿਚਾਰ ਕਰੋ ਜਿਵੇਂ JWT ਜਾਂ OAuth.
- ਕੀ ਮੈਂ DELETE ਬੇਨਤੀਆਂ ਲਈ @RequestBody ਦੀ ਵਰਤੋਂ ਕਰ ਸਕਦਾ/ਸਕਦੀ ਹਾਂ?
- ਹਾਂ, ਹਾਲਾਂਕਿ ਗੈਰ-ਰਵਾਇਤੀ, ਬਸੰਤ ਬੂਟ ਦਾ ਸਮਰਥਨ ਕਰਦਾ ਹੈ @RequestBody ਬੇਨਤੀਆਂ ਨੂੰ ਮਿਟਾਉਣ ਲਈ, ਤੁਹਾਨੂੰ ਬੇਨਤੀ ਪੇਲੋਡ ਵਿੱਚ ਡੇਟਾ ਸ਼ਾਮਲ ਕਰਨ ਦੀ ਆਗਿਆ ਦਿੰਦਾ ਹੈ।
- ਮੈਂ ਸਪਰਿੰਗ ਬੂਟ ਵਿੱਚ ਈਮੇਲ ਪਤਿਆਂ ਨੂੰ ਕਿਵੇਂ ਪ੍ਰਮਾਣਿਤ ਕਰਾਂ?
- regex ਜਾਂ ਲਾਇਬ੍ਰੇਰੀਆਂ ਦੀ ਵਰਤੋਂ ਕਰੋ Apache Commons Validator ਇਹ ਯਕੀਨੀ ਬਣਾਉਣ ਲਈ ਕਿ ਕਾਰਵਾਈ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਈਮੇਲ ਫਾਰਮੈਟ ਸਹੀ ਹੈ।
- ਕੀ ਪੁੱਛਗਿੱਛ ਪੈਰਾਮੀਟਰਾਂ ਵਿੱਚ ਸੰਵੇਦਨਸ਼ੀਲ ਡੇਟਾ ਪਾਸ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ?
- ਇਸਦੀ ਸਿਫ਼ਾਰਸ਼ ਨਹੀਂ ਕੀਤੀ ਜਾਂਦੀ ਜਦੋਂ ਤੱਕ ਤੁਸੀਂ ਡੇਟਾ ਨੂੰ ਸੁਰੱਖਿਅਤ ਨਹੀਂ ਕਰਦੇ HTTPS ਅਤੇ ਸੰਵੇਦਨਸ਼ੀਲ ਜਾਣਕਾਰੀ ਨੂੰ ਨਕਾਬ ਦੇਣ ਲਈ ਮਜ਼ਬੂਤ ਲੌਗਿੰਗ ਅਭਿਆਸਾਂ ਨੂੰ ਲਾਗੂ ਕਰੋ।
- ਮੈਂ ਆਪਣੇ DELETE ਐਂਡਪੁਆਇੰਟ ਦੀ ਜਾਂਚ ਕਿਵੇਂ ਕਰ ਸਕਦਾ ਹਾਂ?
- ਵਰਤੋ MockMvc ਯੂਨਿਟ ਟੈਸਟਾਂ ਜਾਂ ਟੂਲਸ ਜਿਵੇਂ ਕਿ Postman ਮੈਨੁਅਲ ਟੈਸਟਿੰਗ ਲਈ। ਵੱਖ-ਵੱਖ ਸਥਿਤੀਆਂ ਲਈ ਜਵਾਬਾਂ ਨੂੰ ਪ੍ਰਮਾਣਿਤ ਕਰੋ, ਜਿਵੇਂ ਕਿ ਸਫਲਤਾ ਅਤੇ ਅਸਫਲਤਾ ਦੇ ਕੇਸ।
ਪ੍ਰਭਾਵੀ ਪੈਰਾਮੀਟਰ ਹੈਂਡਲਿੰਗ ਲਈ ਮੁੱਖ ਉਪਾਅ
ਇਹ ਫੈਸਲਾ ਕਰਨ ਵਿੱਚ ਕਿ ਕੀ ਪੁੱਛਗਿੱਛ ਪੈਰਾਮੀਟਰਾਂ ਦੀ ਵਰਤੋਂ ਕਰਨੀ ਹੈ ਜਾਂ ਅੰਤਮ ਬਿੰਦੂਆਂ ਨੂੰ ਮਿਟਾਉਣ ਲਈ ਬੇਨਤੀ ਬਾਡੀ ਦੀ ਵਰਤੋਂ ਕਰਨੀ ਹੈ, ਚੋਣ ਜ਼ਿਆਦਾਤਰ ਤੁਹਾਡੀਆਂ ਤਰਜੀਹਾਂ 'ਤੇ ਨਿਰਭਰ ਕਰਦੀ ਹੈ - ਬਾਕੀ ਦੀ ਪਾਲਣਾ ਬਨਾਮ ਡਾਟਾ ਸੁਰੱਖਿਆ। ਦੋਵਾਂ ਪਹੁੰਚਾਂ ਵਿੱਚ ਵਪਾਰ-ਆਫ ਹਨ, ਪਰ HTTPS ਅਤੇ ਲੌਗਿੰਗ ਅਭਿਆਸਾਂ ਦੇ ਨਾਲ, ਪੁੱਛਗਿੱਛ ਪੈਰਾਮੀਟਰ ਅਕਸਰ ਸਵੀਕਾਰਯੋਗ ਹੁੰਦੇ ਹਨ। 🛡️
ਇਨਪੁਟ ਪ੍ਰਮਾਣਿਕਤਾ, ਸੁਰੱਖਿਅਤ ਪ੍ਰਸਾਰਣ, ਅਤੇ ਉਚਿਤ ਅਧਿਕਾਰ ਨੂੰ ਯਕੀਨੀ ਬਣਾਉਣਾ ਤੁਹਾਡੇ ਲਾਗੂਕਰਨ ਨੂੰ ਮਜ਼ਬੂਤ ਕਰਦਾ ਹੈ। ਵਿਚਾਰਸ਼ੀਲ ਡਿਜ਼ਾਈਨ ਦੇ ਨਾਲ, ਤੁਹਾਡੀ ਸਪਰਿੰਗ ਬੂਟ ਐਪਲੀਕੇਸ਼ਨ ਕਾਰਜਕੁਸ਼ਲਤਾ ਅਤੇ ਉਪਭੋਗਤਾ ਵਿਸ਼ਵਾਸ ਦੋਵਾਂ ਨੂੰ ਬਰਕਰਾਰ ਰੱਖ ਸਕਦੀ ਹੈ, ਸਾਫ਼, ਸੁਰੱਖਿਅਤ APIs ਲਈ ਰਾਹ ਪੱਧਰਾ ਕਰ ਸਕਦੀ ਹੈ। 🔧
ਸਰੋਤ ਅਤੇ ਹਵਾਲੇ
- RESTful API ਡਿਜ਼ਾਈਨ ਸਿਧਾਂਤਾਂ ਦੀ ਸੂਝ ਇਸ ਤੋਂ ਪ੍ਰਾਪਤ ਕੀਤੀ ਗਈ ਸੀ RESTful API ਦਸਤਾਵੇਜ਼ .
- ਸਪਰਿੰਗ ਬੂਟ DELETE ਵਿਧੀ ਸੰਮੇਲਨਾਂ ਅਤੇ ਉਦਾਹਰਨਾਂ ਦਾ ਅਧਿਕਾਰੀ ਤੋਂ ਹਵਾਲਾ ਦਿੱਤਾ ਗਿਆ ਸੀ ਬਸੰਤ ਫਰੇਮਵਰਕ ਦਸਤਾਵੇਜ਼ .
- URL ਵਿੱਚ ਸੰਵੇਦਨਸ਼ੀਲ ਡੇਟਾ ਨੂੰ ਸੰਭਾਲਣ ਲਈ ਸੁਰੱਖਿਆ ਵਿਚਾਰਾਂ ਨੂੰ ਇੱਕ ਲੇਖ ਦੁਆਰਾ ਪ੍ਰੇਰਿਤ ਕੀਤਾ ਗਿਆ ਸੀ OWASP ਚੋਟੀ ਦੇ ਦਸ ਸੁਰੱਖਿਆ ਜੋਖਮ .
- ਦੁਆਰਾ ਈਮੇਲ ਫਾਰਮੈਟਾਂ ਲਈ ਪ੍ਰਮਾਣਿਕਤਾ ਤਕਨੀਕਾਂ ਦੀ ਜਾਣਕਾਰੀ ਦਿੱਤੀ ਗਈ ਸੀ ਅਪਾਚੇ ਕਾਮਨਜ਼ ਵੈਲੀਡੇਟਰ ਲਾਇਬ੍ਰੇਰੀ ਦਸਤਾਵੇਜ਼
- ਸਪਰਿੰਗ ਬੂਟ ਐਂਡਪੁਆਇੰਟ ਦੀ ਜਾਂਚ ਕਰਨ ਲਈ ਸਭ ਤੋਂ ਵਧੀਆ ਅਭਿਆਸਾਂ ਨੂੰ ਉਦਾਹਰਨਾਂ ਤੋਂ ਲਿਆ ਗਿਆ ਸੀ ਬਸੰਤ ਗਾਈਡ .