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

tks bác ẹp zai hay sp e

@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

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

@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á.

@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é

@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 đủ

@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.

@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:

• https://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html
• https://stackoverflow.com/a/16812862
• https://www.quora.com/Why-are-PUT-and-DELETE-no-longer-supported-in-HTML5-forms/answer/Alexandre-Morgaut

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

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

@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.

@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

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

@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 ạ

@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 =))

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

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

@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ủ =))

@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

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

@Naem

@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

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

@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

@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

@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à

@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ơ à?

@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ì ?

@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à login và logout, 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 create và destroy, method lần lượt là POST và DELETE), nghe xong thì Eureka và nhớ cho đến ngày nay =))

@thangtd90 Vâng ạ. Em cảm ơn anh, em thấy các anh phân tích thành destroy và create 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

@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 ạ.

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

oé bài này lên top 1 google search với keyword "put va patch viblo" luôn