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

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

Chuyển code Python xong quay về chỉ em với nhé

À, vậy mình hiểu nhầm nó là 1 tool cơ.

(clap8)

@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

@Naem

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

@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

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

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

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