Quá hay

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

Mình cũng đồng ý với bạn rằng tác giả nên điều chỉnh phần này, Docker sinh ra không phải để ảo hóa, không thay thế cho các giải pháp ảo hóa. Nó cung cấp tính năng đóng gói, cách ly, khả chuyển các dịch vụ, và nó chạy chung kernel với hệ điều hành chủ.

bài viết hữu ích, thanks bạn nhiều

@buivansaobg bạn hoàn toàn có thể. như tiêu đề là mình sẽ hướng đến PURE JAVASCRIPT

chị ơi chị có thêm bài viết về các scenario còn lại chưa ạ

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

Ổn áp đấy anh

@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

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

window.url e hay viết như sau.

<label>Avatar</label>
<label for="avatar" class="btn btn-success">Upload</label>
<input id="avatar" style="visibility:hidden;" type="file" name="avatar">
<div id="preview"></div>

$('#avatar').on('change', function () {
        let img = `<img style="width: 120px; border-radius: 50%" src="' + URL.createObjectURL(event.target.files[0]) + '">`;
        $('#preview').html(img);
})

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

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

@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

@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

Ừ, trước đấy thì a sắp chuyển xang làm ca xũy rồi . https://soundcloud.com/hieukulee/girl-u-make-ur-dance-thuot-tha

dạ em cảnh ơn anh rất nhiều ạ

@tungtv khả năng đây là thuyết âm mưu, fshare dụ để block account của mọi người. Tại sao lại có repo github kia, và khi thử vẫn hoạt động, api key kia đâu được cấp phát công khai, thông thường theo chính sách người sở hữu api key kia đã bị vô hiệu hóa rồi chứ nhỉ.

À mình hiểu vấn đề bạn đang nói . Mình cảm ơn bạn . Các bài viết sao mình cố đổi cách tiếp cận