Asked Feb 16th, 4:44 AM 1178 1 1
  • 1178 1 1
+2

Các phương thức get post patch delete put khác nhau ntn

Share
  • 1178 1 1

Các bác có thể giải thích câu hỏi này giúp e vs ạ, hoặc có thể cho e link giải thích đc k ạ, e cảm ơn 😄

1 ANSWERS


Answered Feb 16th, 5:06 AM
Accepted
+22

Có vẻ là bạn đang hỏi về các HTTP Methods nhỉ 😄 Nếu là vậy thì tên method phải là PUT chứ không phải là PUSH đâu 😜

GET, POST, PATCH, PUT, DELETE là 5 methods cơ bản dùng để gọi phía server Restful. Bạn có thể tìm hiểu thêm về REST cũng như các HTTP Methods này thông qua một số bài viết sau trên Viblo:

Chuẩn REST có quy định rõ ràng như thế nào là một resource controller, và phải dùng method nào cho từng action trong controller đấy.

Cụ thể thì với action index để lấy ra list dữ liệu, bạn cần gửi request lên server với method GET, hay với action store để lưu dữ liệu, bạn cần gửi request lên server với method POST, để sửa dữ liệu thì bạn cần dùng method PUT hoặc PATCH (PUT để sửa toàn bộ record, trong khi PATCH thường dùng trong trường hợp sửa 1 phần của record), để xoá dữ liệu thì cần method DELETE.... Chỉ cần bạn gọi lên server với Method khác với quy định (ví dụ như dùng method POST để update dữ liệu chẳng hạn) thì sẽ nhận về lỗi 405 (Method not allowed)

Đương nhiên, đây là tiêu chuẩn của REST, bạn có thể tuân theo hoặc không. Bạn vẫn có thể code theo kiểu dùng GET để tạo dữ liệu, vẫn có thể dùng POST để xoá dữ liệu, và hệ thống vẫn sẽ chạy. Tuy nhiên, đã là tự code theo ý mình thì về sau bạn có thể sẽ gặp rất nhiều vấn đề về chất lượng code, về bảo mật, sẽ rất khó trong việc làm document, hay trao đổi với các thành viên khác trong development team (ví dụ như bạn làm theo chuẩn của REST về HTTP Method, thì chỉ cần bảo với thành viên khác một câu là gọi API để tạo dữ liệu đi, là teammate của bạn sẽ biết ngay cần phải gọi đến URL nào, với method là gì ... )

Ngoài ra, bạn nên đọc thêm bài này, để hiểu rõ hơn về những lợi ích khác của REST, bên cạnh HTTP Method được define rõ ràng ra 😄

Share
duongricky @duongricky
Feb 16th, 5:12 AM

tks bác ẹp zai hay sp e 😄

0
| Reply
Share
hi ha @1111
Feb 18th, 4:37 AM
Tran Duc Thang @thangtd90
Feb 18th, 5:35 AM

@1111

các phương thức trên chia ra làm 2 loại

Post bao gồm put Delete PATCH

Mình thấy cách trả lời của bạn mới là đang cố gắng làm hỏng cả một thế hệ ý 😂

Bạn có thể tìm hiểu thêm về các HTTP Method được dùng trong REST tại link này, https://restfulapi.net/http-methods/ . Không có cái định nghĩa nào là method này "bao gồm" method kia, hay "PUT DELETE PATCH đều là POST" đâu 😅

+2
| Reply
Share
Cùi Bắp @euclid
Feb 18th, 5:41 AM

@thangtd90 Để đỡ confuse thì nên dùng POST hết trong tất cả các trường hợp có thể

+3
| Reply
Share
hi ha @1111
Feb 18th, 6:45 AM

@thangtd90 https://www.w3schools.com/tags/ref_httpmethods.asp Bạn nên đọc lại về http method. Restfulapi chỉ là cách quy định và sử dụng chứ ko nói lên bản chất. giống như bh ông có thể quy định post dùng để delete put để tạo mới và delete để update vậy. Nhưng mà ông lại hiểu quy định chung để lý giải bản chất là sai hoàn toán nhá. Với cả việc ông nói là http get có thể dùng thay cho post là sai hoàn toàn vì post luôn cần 1 lượng dữ liệu rất lớn và ko trong suốt với người dùng trong khi get thì chỉ bị giới hạn. ghi tạo dữ liệu ông cần thêm cả tracking về ai là người tạo ra cooke nếu có và 1 tá các quy định về ông dùng tiếng anh hay tiếng việt fomat number là gì. thằng get không thể gửi toàn bộ mà dựa vào người tạo cần thì gưi. Còn post luôn luôn gửi cùng request và là mặc định của trình duyệt nhá.

-5
| Reply
Share
hi ha @1111
Feb 18th, 6:47 AM
Tran Duc Thang @thangtd90
Feb 18th, 7:02 AM

@1111 Thôi bạn đã tự tin rằng mình hiểu rõ "bản chất" rồi thì mình cũng không dám tranh luận nữa 😅 Nhưng mong bạn đừng tự suy diễn xong nhét chữ vào người khác kiểu như

ông @thangtd90 lại bảo get thay thế đc post

nữa nhé 😂

0
| Reply
Share
Feb 18th, 7:05 AM

@1111 Bạn @thangtd90 chỉ nói là có thể dùng get để tạo dữ liệu chứ có nói là cái gì post làm được là get làm được đâu bạn 😄

Mình hiểu ý bạn là về cơ chế thì có 2 loại là loại GET(các parameters hiển thị hết lên trên URL của trình duyệt) và các loại còn lại với cơ chế giống nhau, mà bạn gọi tất cả là POST.

Cách phân loại này về bản chất thì theo mình cũng chả có gì sai trái, chỉ có điều POST mà tất cả mọi nơi chính thống định nghĩa, đứng ngang hàng với GET, PUT, DELETE (với mục đích phân chia cụ thể hơn các mục đích tác động lên dữ liệu). Vì vậy nên nói POST bao gồm tất cả là không đúng (so với những nơi chính thống)

Ngay cả link bạn trích dẫn cũng phân chia như vậy mà.

Nếu là mình thì mình sẽ gọi là GET và ANTI-GET 😄

Còn về lý thuyết thì theo mình bạn @thangtd90 trả lời rất rõ ràng và đầy đủ 😃

+2
| Reply
Share
Tran Duc Thang @thangtd90
Feb 18th, 8:20 AM

@bs90 🤝 Dù thế nào thì PUT và DELETE vẫn tồn tại, tương đương với các method khác, trong tài liệu define về HTTP/1.1 😂

https://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html

Ví dụ như bài này phân tích khá kỹ về sự khác biệt giữa PUT và POST https://restfulapi.net/rest-put-vs-post/ Nhưng có thể trong công việc hàng ngày mình không để ý chăng, nào là PUT là idempotent với POST là NOT idempotent 😂

Cũng có thể bạn ý nghĩa POST bao gồm các method khác là vì khi code web bạn ý không thấy có method PUT/DELETE trong form HTML, mà chỉ có GET với POST thôi chăng 🤔

Nhưng thực tế là Browsers do support PUT and DELETE, but it's HTML that doesn't. 😅

+2
| Reply
Share
hi ha @1111
Feb 18th, 8:29 AM
Tran Duc Thang @thangtd90
Feb 18th, 8:53 AM

@1111

http Bản chất vốn chỉ có 2 phương thức Post Và get.Trong javascript không có put delete lẫn patch

Không biết bạn tìm hiểu và sử dụng HTML với Javascript ở đâu chứ theo những gì mình biết thì lại là khác hẳn. Hệ quy chiếu có vẻ khác nhau rồi nên mình cũng không muốn tranh luận nhiều nữa (^^;)

Bạn có thể tham khảo thêm tài liệu mà mình đã đọc qua ở đây:

tldr: Trong bản define HTTP 1.1, ở phần Method Definitions, có PUT và DELETE, bên cạnh các methods khác. HTML Form chỉ support method GET và POST, nhưng javascript (và browsers) support được hết các methods khác như PUT với DELETE.

Có lẽ mình nên dừng ở đây thôi 😂

+2
| Reply
Share
duongricky @duongricky
Feb 18th, 9:20 AM

@thangtd90 @bs90 @1111 Các bác comment làm e hoang mang theo luôn hihi 😄

0
| Reply
Share
hi ha @1111
Feb 18th, 9:21 AM
Feb 18th, 9:27 AM

@1111 thôi ông sai lè lè ra rồi, tôi nghĩ ông nên ngẫm lại đi đã , và nên tìm hiểu nhiều nguồn tài liệu đã rồi hãy comment.

+8
| Reply
Share
Le Duc @adolf_hittl3r
Feb 18th, 9:46 AM

@1111 Thôi mình nghĩ bạn nên tìm một khóa học về Web Base để nâng cao kiến thức của mình về HTTP Method nhé. Thân ái và chào quyết thắng! Happy Coding

0
| Reply
Share
Phạm Thu Hằng @bunny.pi.green
Feb 18th, 9:52 AM

@duongricky em về hỏi trainer Quốc xem thangtd là ai để có thể yên tâm nhé

+2
| Reply
Share
No Naem @Naem
Feb 18th, 9:56 AM

@thangtd90 nhân tiện câu hỏi cho e hỏi với ạ, với case login thì sẽ sử dụng method nào cho chuẩn ạ =)) và tại sao ạ

0
| Reply
Share
Nguy Minh Tuan @minhtuan.nguy
Feb 18th, 9:57 AM

@Naem Nếu bạn dùng GET thì user và passwd của bạn sẽ nằm trên URL, và tin mình đi, bạn k vui đâu =))

Bạn có thể dùng Del cũng được cho nó ngầu =))

0
| Reply
Share
No Naem @Naem
Feb 18th, 9:58 AM

@minhtuan.nguy ở đây mình đang nói đến api mà :v

0
| Reply
Share
Nguy Minh Tuan @minhtuan.nguy
Feb 18th, 9:59 AM

@Naem Qua khu buzz mình nói chuyện cho rõ ràng nhé :#)

0
| Reply
Share
No Naem @Naem
Feb 18th, 10:01 AM

@minhtuan.nguy mình ko làm ở cty nên ko biết buzz là gì ạ, bạn giải thích cho mình qua đây đc ko trước có các bạn junior hỏi mình mà mình trả lời giờ ngẫm lại ko đúng lắm, ko biết có làm hỏng 1 thế hệ ko nên phải tranh thủ hỏi lại các cao thủ =))

0
| Reply
Share
Tran Duc Thang @thangtd90
Feb 18th, 10:01 AM

@1111 > http 1.1 ra đời sau cả Restful lẫn CRUD

Không biết bạn lấy dữ liệu ở đâu nhưng mà

Roy Fielding defined REST in his 2000 PhD dissertation "Architectural Styles and the Design of Network-based Software Architectures" at UC Irvine. He developed the REST architectural style in parallel with HTTP 1.1 of 1996–1999, based on the existing design of HTTP 1.0 of 1996.

https://en.wikipedia.org/wiki/Representational_state_transfer

+1
| Reply
Share
Nguy Minh Tuan @minhtuan.nguy
Feb 18th, 10:02 AM
Phạm Thu Hằng @bunny.pi.green
Feb 18th, 10:03 AM

@Naem (tat) có ở cty cũng 1 năm mấy lần xuống buzz

0
| Reply
Share
Nguy Minh Tuan @minhtuan.nguy
Feb 18th, 10:06 AM
0
| Reply
Share
Tran Duc Thang @thangtd90
Feb 18th, 10:07 AM

@Naem Khi login thì bản chất là em tạo ra một session mới cho user trên server, tức sẽ là dùng method POST gửi lên server, em có thể dùng url là /login cho thân thiện, nhưng ở phần Controller thì nên là SessionController và action trong controller xử lý việc này nên là store hay create. Ngược lại khi em logout thì bản chất là xoá session trên server, nên method nên là DELETE còn action xử lý phía backend nên là destroy .

Ngày trước hồi từng học về Rails và RESTful anh cũng được dạy như vậy, và cũng học được nó từ trong gem Devise của Rails 😄 https://github.com/heartcombo/devise/blob/master/app/controllers/devise/sessions_controller.rb#L18

+2
| Reply
Share
No Naem @Naem
Feb 18th, 10:40 AM

@thangtd90 Em cảm ơn anh ạ, với api thì liệu nó có đúng ko ạ :-?

0
| Reply
Share
Tran Duc Thang @thangtd90
Feb 19th, 12:59 AM

@Naem à với trường hợp em viết API thì cũng có thể suy nghĩ theo cách tương tự thôi, khi login là em tạo ra AccessToken, còn khi logout là em xoá cái AccessToken đó đi 😄

0
| Reply
Share
SuNH @huusu1996
Feb 19th, 1:12 AM

@thangtd90 Em lại nghĩ bản chất của login là xác thực user vào hệ thống thôi chứ ạ. Vì thực tế chỉ cần so sánh username và pasword trùng trong hệ thống là được. Còn việc tạo ra session chỉ là lưu lại phiên đăng nhập. Thực tế thì làm chức năng login không cần dùng session, cookie cũng được mà anh nhỉ. Chỉ là bất tiện mỗi lần reload trang lại phải đăng nhập 1 lần thôi 😅😅

0
| Reply
Share
Tran Duc Thang @thangtd90
Feb 19th, 1:29 AM

@huusu1996 Đấy là tuỳ em hiểu xem "bản chất" ở đây là gì thôi 😅 Ví dụ như với service bình thường, sau khi so sánh username và password thì khâu cuối cùng được thực hiện cũng là gán cái user_id vào session hiện tại, hay nói cách khác là tạo session cho user đã được xác thực hiện tại, thì người ta có thể đưa ra ý tưởng là xử lý trong SessionController. Với hệ thống login qua API, chứ không dùng session chẳng hạn, thì lúc đó không phải là SessionController nữa, mà có thể là AccessTokenController chẳng hạn 😄

Còn như em đưa ra giải pháp mỗi lần thao tác đều phải nhập username/password thì rõ ràng là không có một url cụ thể cho action đăng nhập rồi, mà việc đăng nhập chỉ là việc làm "phụ" khi người dùng thực hiện một thao tác gì đó. Ví dụ như ở ô comment, em bắt người dùng nhập comment, rồi phải nhập cả user, pass nữa, thì vẫn phải gửi lên url comments, xong ở trong đó sẽ có một cái middleware, hoặc gọi đến một hàm nào đó để verify user, pass chẳng hạn =)) Thành ra cái ví dụ này thì việc đăng nhập không còn là một action trong resource controller nữa, nên nó out of scope rồi, với lại nó cũng hơi xa vời với thực tế em ạ =)) Ở trên là anh đưa ra ý kiến cho việc nếu muốn viết action login/logout theo kiểu restful, thì sẽ diễn giải như thế nào, đặt trên controller hay action trong controller là gì thôi mà 😂

0
| Reply
Share
Feb 19th, 1:29 AM

@1111 ông hạ bớt cái tôi của mình xuống mà tiếp thu thì mới tiến bộ được 🙂

Bản chất là chỉ có POST, GET hả?? Giáo trình PHP cơ bản hay gì? Người ta đã tạo ra từng chuẩn RESTful khác nhau để dành cho các công việc khác nhau, ông thì lại đi thụt lùi so với tiến bộ, cố gộp hết cmnl để chứng minh cái tôi bé như con kiến của ông, thế bây giờ tôi bảo ông về xóa hết cmn code project của ông đi, viết hết lại thành POST api cho thỏa mãn cái tôi của ông, ông có làm không? Nhận sai 1 câu khó thế cơ à?

+1
| Reply
Share
SuNH @huusu1996
Feb 19th, 1:43 AM

@thangtd90 Đúng là bản chất là bản chất là đôi khi lại không là "bản chất" 😅 Em hỏi xem cách mọi người đang nhìn nhận vấn đề như nào thôi ạ. Thực tế thì em thấy thằng Auth của laravel nó vấn để action là login hay logout, quan trọng là khi nhìn vào ai cũng hiểu hàm này có action gì ? làm những công việc gì ?

0
| Reply
Share
Tran Duc Thang @thangtd90
Feb 19th, 2:05 AM

@huusu1996 Uhm đúng rồi. Ở trên chỉ là cách diễn giải cho mọi người khi muốn viết dưới dạng Resful Controller thôi, chứ phần login/logout mọi người cũng không cần thiết cứ phải ép vào restful làm gì cả. Như Laravel thì có cái LoginController, với method đặt tên hẳn là loginlogout, rồi dùng method POST cho cả 2 action này 😄 Cứ đơn giản như thế là dễ hiểu =))

Còn như viết theo kiểu restful như cái gem Devise của Rails thì ngày trước hồi mới tìm hiểu và training về Rails thì anh cũng từng được anh CTO hồi đó của công ty giải thích theo cách ở trên (dùng SessionController với action createdestroy, method lần lượt là POSTDELETE), nghe xong thì Eureka và nhớ cho đến ngày nay =))

+1
| Reply
Share
SuNH @huusu1996
Feb 19th, 2:17 AM

@thangtd90 Vâng ạ. Em cảm ơn anh, em thấy các anh phân tích thành destroycreate hoặc store khá hay. Cũng như cách anh @1111 gom thành 2 cái get và post hay @bs90 gom thành get và anti-get, dù trên lí thuyết đúng là không đúng nhưng khá hợp lí, tùy vào lăng kính của mỗi người

0
| Reply
Share
No Naem @Naem
Feb 19th, 2:28 AM

@thangtd90 @huusu1996 cảm ơn 2 ae ạ, e thì thấy là theo restful thì cái ý nghĩa của url cũng là cái quan trọng, nếu function là login thì ý nghĩa của nó chỉ là để redirect về hệ thống với trạng thái là đăng nhập, cũng như là POST /users/ là để tạo hay PUT /users/1 là để sửa vậy.

Em nghĩ là dù tạo ra cái gì thì nó cũng chỉ là phụ cho việc redirect về hệ thống với trạng thái khác. Giống như tạo users thì mình có thể tạo thêm relate đến các bảng khác thì ý nghĩa chính nó phải thể hiện ra được ở url. Do đó e nghĩ về bản chất dùng GET ở đây vẫn hoàn toàn là hợp lý. Em nghĩ chỉ là do thói quen từ lúc chưa code api nên thường dev vẫn tư tưởng là dùng POST.

Giống như trong link của a về restful có đề cập đó ạ:

Use GET requests to retrieve resource representation/information only – and not to modify it in any way.

việc token tạo ra tại thời điểm nào có lẽ cũng ko quan trọng với việc login vì e thấy bản chất chỉ là login để nhận lại token hoặc để nhận lại SID (ví dụ thậm chí có thể token hoặc SID đó đã tạo ra tư trước trên server nhưng chưa cung cấp cho người dùng mà sau khi đăng nhập ms cung cấp). Tương tự với logout cũng vậy ạ, tên url của nó chỉ là thoát ra khỏi hệ thống thôi chứ ko có mention đến việc là bên trong phải xóa hay làm gì ạ. Em nghĩ là để như vậy thì nó cũng đảm bảo được tính trong suốt với người dùng ạ.

P/S:

Em cũng có tham khảo với wiki và họ có refer đến 1 document giới thiệu của họ ở đoạn đầu (https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm) Đại tỉ họ nói rằng

REST ignores the details of component implementation and protocol syntax in order to focus on the roles of components, the constraints upon their interaction with other components, and their interpretation of significant data elements.

Cá nhân e hiểu thì họ muốn nói đến việc rằng việc biểu diễn của REST là tường minh ở url và không cần bận tâm đến detail bên trong. Do đó e nghĩ mình hoàn toàn có thể dùng GET với cả 2 TH là login và logout ạ. Đó là quan điểm của em ạ.

0
| Reply
Share
duongricky @duongricky
Feb 19th, 3:32 AM

Tks các bác, tính ra 1 câu hỏi mà e hút được cả đống chân kinh về luyện, hihi 😄

0
| Reply
Share
Nguy Minh Tuan @minhtuan.nguy
Feb 19th, 5:58 AM