Làm thế nào để giữ cho các ứng dụng không trạng thái

Đây có thể là một câu hỏi phức tạp, nhưng tôi đang cố gắng để hiểu rõ hơn về tình trạng không quốc tịch.

Dựa trên những gì tôi đã đọc, các ứng dụng web sẽ không trạng thái, nghĩa là mỗi yêu cầu được coi là một giao dịch độc lập. Do đó, nên tránh Phiên và Cookies (vì cả hai đều có trạng thái). Một cách tiếp cận tốt hơn là sử dụng Tokens, không trạng thái vì không có gì được lưu trữ trên máy chủ.

Vì vậy, tôi đang cố gắng để hiểu, làm thế nào các ứng dụng web có thể không trạng thái khi có dữ liệu được lưu giữ cho phiên của tôi (chẳng hạn như các mặt hàng trong giỏ hàng)? Đây có thực sự được lưu trữ trong một cơ sở dữ liệu ở đâu đó và sau đó định kỳ bị thanh trừng? Làm thế nào để nó hoạt động khi bạn đang sử dụng mã thông báo thay vì cookie?

Và sau đó là một câu hỏi liên quan, các trang web lớn (Amazon, Google, Facebook, Twitter, v.v.) có thực sự không trạng thái? Họ có sử dụng mã thông báo hoặc cookie (hoặc cả hai) không?

"Các ứng dụng web nên không trạng thái" nên được hiểu là "các ứng dụng web nên không trạng thái trừ khi có một lý do rất chính đáng để có trạng thái" . Một "giỏ hàng" là một tính năng mang tính trạng thái theo thiết kế và phủ nhận rằng nó khá phản tác dụng. Toàn bộ điểm của mẫu giỏ hàng là duy trì trạng thái của ứng dụng giữa các yêu cầu.

Một thay thế mà tôi có thể tưởng tượng là một trang web không trạng thái thực hiện giỏ hàng sẽ là một ứng dụng một trang giữ cho giỏ hàng hoàn toàn ở phía khách hàng, lấy thông tin sản phẩm bằng các cuộc gọi AJAX và sau đó gửi nó đến máy chủ cùng một lúc người dùng thực hiện kiểm tra Nhưng tôi nghi ngờ tôi đã từng thấy ai đó thực sự làm điều đó, bởi vì nó không cho phép người dùng sử dụng nhiều tab trình duyệt và không giữ trạng thái khi họ vô tình đóng tab. Chắc chắn, có những cách giải quyết như sử dụng localst Storage, nhưng sau đó bạn lại có trạng thái, chỉ trên máy khách thay vì trên máy chủ.

Bất cứ khi nào bạn có một ứng dụng web yêu cầu duy trì dữ liệu giữa các lần xem trang, bạn thường làm điều đó bằng cách giới thiệu các phiên. Phiên yêu cầu thuộc về có thể được xác định bằng cookie hoặc bằng tham số URL bạn thêm vào mỗi liên kết. Cookie nên được ưu tiên vì chúng giữ URL của bạn tiện dụng hơn và ngăn người dùng của bạn vô tình chia sẻ URL với id phiên của họ trong đó. Nhưng việc có mã thông báo URL làm dự phòng cũng rất quan trọng đối với người dùng tắt cookie. Hầu hết các khung phát triển web đều có hệ thống xử lý phiên có thể thực hiện việc này.

Về phía máy chủ, thông tin phiên thường được lưu trữ trong cơ sở dữ liệu. Bộ nhớ đệm phía máy chủ là tùy chọn. Nó có thể cải thiện đáng kể thời gian phản hồi, nhưng sẽ không cho phép bạn chuyển phiên giữa các máy chủ khác nhau. Vì vậy, bạn sẽ cần một cơ sở dữ liệu liên tục như một dự phòng.

các trang web lớn (Amazon, Google, Facebook, Twitter, v.v.) có thực sự không trạng thái? Họ có sử dụng mã thông báo hoặc cookie (hoặc cả hai) không?

Họ có cho phép bạn đăng nhập không? Khi bạn đóng tab và truy cập lại trang web, bạn vẫn đăng nhập chứ? Nếu là bạn thì họ đang sử dụng cookie để giữ danh tính của bạn giữa các phiên.

Đúng là các ứng dụng web nên không trạng thái. Tuy nhiên, các biến phiên, cookie và mã thông báo không vi phạm điều này khi tất cả chúng được lưu trữ trên máy khách (trình duyệt web). Chúng có thể là các tham số trong yêu cầu.

Đây là một mô hình đơn giản hóa:

Web Browser (has state) <-> Web Server (stateless) <-> Database (has state)

Điều này có thể làm việc cho Trao đổi ngăn xếp kỹ thuật phần mềm . Câu trả lời này tôi đang gõ là một phần của trạng thái trình duyệt web của tôi. Chừng nào đó là nơi duy nhất ở đó, thì không ai có thể truy cập được ngoài tôi. Nhưng ngay khi tôi nhấn Post your Answertrình duyệt của tôi sẽ gửi nó đến máy chủ web. Máy chủ web xử lý bài đăng không sử dụng trạng thái của chính nó. Nó học tôi là ai từ trình duyệt của tôi và từ cơ sở dữ liệu. Khi kiểm tra xong bài đăng của tôi và thêm nó vào cơ sở dữ liệu, máy chủ web sẽ nhanh chóng quên tôi.

Đó là những gì không quốc tịch. Máy chủ không chịu trách nhiệm ghi nhớ bất kỳ điều này. Đó không phải là công việc của nó.

Làm điều này có nhiều lợi thế. Nếu máy chủ web bị rò rỉ bộ nhớ thì có thể phát hiện được vì dấu chân bộ nhớ của nó không nên tăng lên. Nếu máy chủ web gặp sự cố, danh tính của tôi không đi cùng với nó. Nếu ai đó cố gắng thực hiện tấn công từ chối dịch vụ, họ không thể sử dụng tài nguyên trạng thái máy chủ web để thực hiện, vì máy chủ web không phân bổ bất kỳ trạng thái nào cho họ giữa các phiên. Đây là tất cả nhằm mục đích làm cho máy chủ web ổn định. Theo cách đó, khi nó bắt đầu chạy, nó vẫn chạy.

Bây giờ chắc chắn, tôi đang tiêu thụ tài nguyên trong cơ sở dữ liệu, nhưng những tài nguyên đó trước tiên đã được kiểm tra dựa trên trợ cấp của tôi bởi một thứ ổn định mà chúng ta có thể tin tưởng để bảo vệ cơ sở dữ liệu khỏi web hoang dã: máy chủ web không thực thi quy tắc.

các ứng dụng web nên không trạng thái

Vô lý. Yêu cầu web nên không trạng thái. Hay chính xác hơn, các yêu cầu web là không trạng thái.

Nhưng, nói rằng toàn bộ ứng dụng nên không trạng thái là hoàn toàn vô nghĩa.

mỗi yêu cầu được coi là một giao dịch độc lập.

Vâng, chính xác . Hay chính xác hơn là có, nhất thiết phải có . Qua HTTP, mỗi yêu cầu vốn đã độc lập với tất cả các yêu cầu khác. Việc thêm "trạng thái" vào HTTP yêu cầu bạn xác định rõ ràng, lưu trữ và truy xuất "trạng thái" cho mỗi yêu cầu "trạng thái". Và điều đó đòi hỏi nỗ lực, giảm hiệu suất và thêm phức tạp.

Và, vì những lý do đó, mỗi yêu cầu có thể không trạng thái "nên" là không trạng thái.

Do đó, nên tránh Phiên và Cookies (vì cả hai đều có trạng thái). Cách tiếp cận tốt hơn là sử dụng Tokens

Một vài điều: Mã thông báo cũng có thể được gắn với lưu trữ phiên. Cookies không cần phải được gắn với lưu trữ phiên. Mã thông báo thường được lưu trữ trong cookie. Và, đôi khi một phiên chỉ đơn giản là công cụ phù hợp cho công việc.

Điều đó có nghĩa là ít nhất , đôi khi , phiên và cookie cũng "tốt hơn" như mã thông báo!

[Mã thông báo] không trạng thái vì không có gì được lưu trữ trên máy chủ.

Vâng, đó là nó. Đó là những gì giáo điều "không quốc tịch" thực sự là về. Mặc dù, rõ ràng, đó không phải là về việc lưu trữ "không có gì" trên máy chủ, mà là về việc không lưu trữ trạng thái phiên trên máy chủ.

Hộp thư đến Gmail của tôi đang ở trạng thái chẳng hạn. Và nó tốt hơn nên được lưu trữ trên máy chủ! Nhưng, đó không phải là trạng thái phiên .

Vì vậy, thay vì có một máy chủ có thể nhận một số nhận dạng nhỏ và tìm ra bạn là ai, các ứng dụng không trạng thái muốn được nhắc nhở bạn là ai và bạn đang làm gì với mọi yêu cầu đẫm máu. Trạng thái ứng dụng vẫn tồn tại, khách hàng chỉ chịu trách nhiệm giữ nó.

Bây giờ, nếu trạng thái đó là nhỏ, điều đó có thể ổn. Trong một số trường hợp, nó rất tốt.

Và sau đó, tất nhiên, có những điều chúng ta chỉ đơn giản mong đợi là trạng thái ...

làm thế nào các ứng dụng web có thể không trạng thái khi có dữ liệu được lưu giữ cho phiên của tôi (chẳng hạn như các mặt hàng trong giỏ hàng)? Đây có thực sự được lưu trữ trong một cơ sở dữ liệu ở đâu đó và sau đó định kỳ bị thanh trừng?

Hai lựa chọn. Hoặc là bạn có một phiên, hoặc bạn đang từ chối!

... Nhưng nghiêm túc đấy. Bạn thường không lưu trữ một giỏ hàng trong một cookie. Một cái gì đó như giỏ hàng sẽ được lưu trữ trong phiên "truyền thống" hoặc nó sẽ được lưu trữ dưới dạng Cartđối tượng, với một số loại ID mà máy chủ sử dụng để kéo nó vào các yêu cầu tiếp theo. Kiểu như một .. uhh ... ... err ... phiên.

Thực sự nghiêm túc: Có một mức độ lớn mà "tính trạng thái" chỉ là cái mà chúng ta gọi nó khi hai tác nhân giao tiếp có thể bối cảnh hóa các tin nhắn trong một cuộc trò chuyện. Và một phiên, theo truyền thống được hiểu, chỉ là những gì chúng ta thường gọi là cơ chế mà điều này xảy ra.

Tôi tranh luận rằng, bất kể bạn sử dụng mã thông báo hay "phiên", cho mỗi yêu cầu máy chủ của bạn xử lý, bạn cần phải bối cảnh hóa yêu cầu đó để thực hiện nó, hoặc bạn không. Nếu bối cảnh không cần thiết, đừng lấy nó. Nếu bối cảnh là cần thiết, tốt hơn bạn nên có nó gần đó!

Và sau đó là một câu hỏi liên quan, các trang web lớn (Amazon, Google, Facebook, Twitter, v.v.) có thực sự không trạng thái? Họ có sử dụng mã thông báo hoặc cookie (hoặc cả hai) không?

Có lẽ là cả hai. Nhưng, nói chung, họ làm chính xác những gì bạn làm: Họ đặt cookie để xác định các bản ghi "trạng thái" trong cơ sở dữ liệu "phiên" lớn.

Khi có thể, tôi nghi ngờ họ chuyển các khiếu nại nhận dạng cơ bản vào các "mã thông báo" ngắn hạn để tránh sự tranh chấp không cần thiết trên bộ lưu trữ tập trung. Nhưng, thực tế là nhiều dịch vụ trong số này cho phép tôi "đăng xuất khỏi tất cả các địa điểm khác" là một chỉ báo tốt cho thấy, nếu họ đang sử dụng mã thông báo, ít nhất họ sẽ được "hỗ trợ" bởi mô hình phiên bán truyền thống .

Trạng thái không nhất thiết là một điều xấu, nhưng bạn cần hiểu sự khác biệt giữa các ứng dụng trạng thái và trạng thái. Nói tóm lại, các ứng dụng trạng thái duy trì thông tin về phiên hiện tại và các ứng dụng không trạng thái thì không. Thông tin được lưu trữ vĩnh viễn như một phần của tài khoản người dùng có thể hoặc không được lưu trữ trong một phiên, nhưng việc lưu trữ thông tin liên quan đến tài khoản người dùng không tự nó làm cho ứng dụng trở nên trạng thái. Tính trạng thái yêu cầu máy chủ duy trì thông tin về phiên của người dùng hiện tại ngoài những gì trình duyệt máy khách đang duy trì. Chẳng hạn, một khách hàng có thể xác thực và được cung cấp một cookie JSESSIONID, sau đó nó sẽ gửi đến máy chủ với mỗi yêu cầu. Nếu máy chủ bắt đầu lưu trữ nội dung trong phạm vi phiên của ứng dụng dựa trên JSESSIONID này, nó sẽ trở thành trạng thái.

Không quốc tịch

Theo trạng thái không trạng thái, chúng tôi có nghĩa là máy chủ và máy khách không duy trì thông tin hiện tại về phiên người dùng. Máy khách và máy chủ có thể sử dụng một số dạng mã thông báo để cung cấp xác thực giữa các yêu cầu, nhưng không có thông tin hiện tại nào khác được lưu trữ. Trường hợp sử dụng thông thường cho giải pháp như vậy có thể là một trang web tin tức nơi hầu hết người dùng (người tiêu dùng mới) sử dụng thông tin nhưng không tạo ra thông tin quay lại trang web. Trong những trường hợp như vậy, trang web không cần duy trì bất kỳ thông tin nào về phiên người dùng hiện tại. Lưu ý rằng trang web vẫn có thể sử dụng cookie để xác định người dùng và lưu trữ thông tin về việc sử dụng trang web của người dùng đó, nhưng điều đó vẫn có thể được coi là không trạng thái vì mọi thứ được ghi có thể là giao dịch, ví dụ như liên kết mà người dùng đã nhấp, có thể được ghi lại bởi máy chủ, nhưng không được duy trì trong phiên người dùng.

Trạng thái trên máy chủ

Trên máy chủ, một ứng dụng trạng thái lưu thông tin trạng thái về người dùng hiện tại. Cách tiếp cận này thường liên quan đến việc sử dụng cookie để xác định hệ thống của người dùng để trạng thái có thể được duy trì trên máy chủ giữa các yêu cầu. Các phiên có thể hoặc không thể được xác thực, tùy thuộc vào ngữ cảnh của ứng dụng. Các ứng dụng máy chủ trạng thái cung cấp lợi thế của bộ nhớ đệm thông tin trạng thái người dùng trên máy chủ, tăng tốc độ tra cứu và thời gian phản hồi trang. Về mặt trái, việc lưu trữ thông tin trong phạm vi phiên là tốn kém, và ở quy mô, nó trở nên rất tốn tài nguyên. Nó cũng tạo ra một vectơ tấn công tiềm năng cho tin tặc thử và chiếm quyền điều khiển phiên định danh và đánh cắp phiên của người dùng. Các ứng dụng máy chủ trạng thái cũng có thách thức trong việc bảo vệ các phiên của người dùng trước các gián đoạn dịch vụ không mong muốn, ví dụ như lỗi máy chủ.

Trạng thái của khách hàng

Sử dụng JavaScript và các công nghệ trình duyệt hiện đại như sessionStorage, giờ đây, ứng dụng có thể dễ dàng lưu trữ thông tin trạng thái về phiên người dùng trên thiết bị của người dùng đó. Nhìn chung, ứng dụng có thể vẫn được coi là trạng thái, nhưng công việc duy trì trạng thái đã được chuyển sang máy khách. Cách tiếp cận này có một lợi thế lớn (đối với người duy trì ứng dụng Web) so với việc duy trì trạng thái trên máy chủ trong đó mỗi người dùng, trên thực tế, duy trì trạng thái của riêng họ và không có gánh nặng nào đối với cơ sở hạ tầng máy chủ. Ở quy mô web, loại lựa chọn kiến ​​trúc đó có tác động rất lớn đối với chi phí phần cứng và điện. Nó có thể có giá hàng triệu đô la một năm để duy trì trạng thái trên máy chủ. Chuyển sang trạng thái duy trì hệ thống trên máy khách sau đó có thể tiết kiệm hàng triệu đô la mỗi năm.

Mã thông báo v. Cookies

Cookies hoạt động như định danh cho các thiết bị / trình duyệt của khách hàng. Chúng có thể được sử dụng để lưu trữ tất cả mọi thứ, nhưng nhìn chung chúng lưu trữ một số dạng định danh, như CFID / CFTOKEN trong các ứng dụng CFML. Cookies có thể được thiết lập để tồn tại trong trình duyệt của người dùng trong một thời gian dài, giúp bạn có thể thực hiện những việc như duy trì xác thực trên một ứng dụng giữa các phiên trình duyệt. Cookies cũng có thể được đặt thành chỉ bộ nhớ để chúng hết hạn khi người dùng đóng trình duyệt.

Mã thông báo nói chung là một số loại thông tin nhận dạng về người dùng được tạo trên máy chủ (sử dụng mã hóa để xáo trộn thông tin), chuyển đến máy khách và trả lại cho máy chủ với yêu cầu tiếp theo. Chúng có thể được chuyển trong tiêu đề của yêu cầu và phản hồi, đây là một mẫu phổ biến trong các ứng dụng trang đơn. Lý tưởng nhất là mỗi yêu cầu / phản hồi dẫn đến việc tạo ra một mã thông báo mới, do đó, các mã thông báo không thể bị chặn và sử dụng sau đó bởi kẻ tấn công.

Ứng dụng trang đơn và trạng thái máy khách

Với các SPA, thông tin trạng thái được tải vào trình duyệt máy khách và được duy trì ở đó. Khi trạng thái thay đổi, ví dụ: bạn đăng cập nhật lên tài khoản truyền thông xã hội của mình, khách hàng sẽ chuyển tiếp giao dịch mới đó đến máy chủ. Trong trường hợp này, máy chủ lưu bản cập nhật đó vào kho lưu trữ dữ liệu liên tục như cơ sở dữ liệu và chuyển tiếp bất kỳ thông tin nào trở lại máy khách mà nó cần để đồng bộ hóa với máy chủ dựa trên bản cập nhật (ví dụ: ID cho bản cập nhật).

Lưu ý rằng mô hình trạng thái lưu trữ này trên máy khách mang lại lợi thế cho trải nghiệm trực tuyến / ngoại tuyến ở chỗ bạn có thể bị ngắt kết nối với máy chủ trong khi vẫn có một ứng dụng có thể sử dụng được. Twitter là một ví dụ điển hình cho trường hợp này, nơi bạn có thể xem lại mọi thứ được tải về phía máy khách trong nguồn cấp dữ liệu Twitter của mình ngay cả khi bạn bị ngắt kết nối với ứng dụng máy chủ Twitter. Mẫu này cũng tạo ra sự phức tạp trong đồng bộ hóa giữa máy chủ và máy khách, là một chủ đề của riêng nó. Sự phức tạp của giải pháp là một sự đánh đổi để có thể duy trì trạng thái trên máy khách.

Tính trạng thái trên máy khách làm cho các ứng dụng web cảm thấy và hoạt động giống như các ứng dụng máy tính để bàn truyền thống. Không giống như các ứng dụng trên máy tính để bàn, thông thường bạn sẽ không tải tất cả thông tin tài khoản của mình vào phiên khách trong trình duyệt. Làm như vậy trong nhiều trường hợp là không thực tế và tạo ra trải nghiệm xấu. Bạn có thể tưởng tượng việc cố gắng tải toàn bộ hộp Gmail vào trình duyệt không? Thay vào đó, khách hàng duy trì thông tin như nhãn / thư mục bạn đang xem và vị trí trong danh sách email trong thư mục mà bạn đang tìm kiếm. Cân bằng những thông tin trạng thái cần duy trì và những gì cần yêu cầu là một thách thức kỹ thuật khác của mẫu này, và một lần nữa, nó thể hiện sự đánh đổi giữa thực tiễn và cung cấp trải nghiệm người dùng tốt.

Giỏ hàng và những thứ tương tự

Đối với các chi tiết cụ thể như giỏ hàng, nó thực sự phụ thuộc vào giải pháp. Một giỏ hàng có thể được lưu trữ trong cơ sở dữ liệu trên máy chủ, nó chỉ có thể được lưu trữ trong phạm vi phiên trên máy chủ hoặc thậm chí có thể được lưu trữ trong máy khách. Amazon có các giỏ mua hàng liên tục cho người dùng đã đăng nhập và giỏ hàng "tạm thời" cho người dùng ẩn danh, mặc dù các giỏ hàng này vẫn tồn tại ở một mức độ nào đó.

Khi bạn nói về một cái gì đó giống như Google, thực sự là một loạt các ứng dụng khác nhau sống dưới cùng một thương hiệu, chúng có thể không chia sẻ một kiến ​​trúc chung và mỗi ứng dụng được xây dựng theo cách đáp ứng tốt nhất nhu cầu của người dùng. Nếu bạn muốn tìm hiểu cách xây dựng một trang web, hãy mở các công cụ dành cho nhà phát triển trong trình duyệt của bạn và xem xét nó. Kiểm tra cookie, xem lưu lượng truy cập mạng và xem cách nó chạy.

Xin lỗi nếu câu trả lời này lan man một chút, nhưng trạng thái là một chủ đề phức tạp.

Phiên và cookie không phải tránh. Bạn vẫn có thể có chúng với các ứng dụng web phi trạng thái.

Có một sự khác biệt lớn giữa Java và Ruby on Rails. Các ứng dụng Java sẽ lưu trữ phiên trong bộ nhớ bằng khóa phiên được lưu trữ trong cookie. Điều này là nhanh chóng để lấy trạng thái người dùng và giỏ hàng. Tuy nhiên, bạn phải luôn nhấn cùng một máy chủ với phiên của bạn.

Ứng dụng Rails lưu trữ id người dùng trong một cookie được mã hóa, đã ký. Nó không thể bị giả mạo. Khi bạn tải một trang, ứng dụng web sẽ tìm nạp trạng thái, người dùng và giỏ hàng của bạn từ cơ sở dữ liệu. Điều này chậm hơn, nhưng điều quan trọng là, bạn có thể nhấn bất kỳ trường hợp nào ! Điều này cho phép bạn khởi động lại, chia tỷ lệ, tắt các trường hợp tùy ý. Rât thuận tiện. Nó cũng có thể được thực hiện nhanh hơn với cơ sở dữ liệu bộ nhớ cache được chia sẻ, trong bộ nhớ, như Redis. Hoặc bạn có thể lưu trữ giỏ hàng trong cookie, miễn là nó đủ nhỏ.

Vì vậy, bạn có thể đạt được trạng thái không trạng thái, thông qua các kỹ thuật thông minh và thêm khả năng mở rộng theo ý muốn.

Các giao thức là quốc tịch.

Nhưng từ đó, nó không nhất thiết phải tuân theo các ứng dụng sử dụng giao thức nên không trạng thái.

Dưới đây là một số câu trả lời StackOverflow liên quan giải thích rõ sự khác biệt:

• https://stackoverflow.com/questions/34675027/statless-web-application-an-urban-legend/34678600#34678600
• https://stackoverflow.com/questions/34675027/statless-web-application-an-urban-legend/34677668#34677668

Khi đề cập đến trạng thái không trạng thái - ví dụ: trong Dịch vụ HTTP RESTful - điều đó sẽ tránh việc lưu trữ trạng thái ở phía máy chủ. Tốt nhất, điều đó cũng bao gồm tránh lưu trữ bất kỳ trạng thái nào trong cơ sở dữ liệu hoặc các kho lưu trữ liên tục khác trên phụ trợ. Để làm rõ, tôi đang nói về một trạng thái không phải là dữ liệu nói chung. Có vẻ như một số kẻ đang trộn lẫn mọi thứ.

Một giao tiếp phi trạng thái có một số lợi ích đặc biệt là về khả năng mở rộng và tính sẵn sàng.

Một cách tiếp cận tốt hơn là sử dụng Tokens, không trạng thái vì không có gì được lưu trữ trên máy chủ.

Điều đó đúng (đối với các giao thức xác thực và ủy quyền nhất định). Mã thông báo có thể (nhưng không phải mỗi lần) cung cấp tất cả thông tin trong yêu cầu cần thiết để xác thực người dùng hoặc ủy quyền cho một hành động. Để biết ví dụ, hãy xem JWT .

Vì vậy, tôi đang cố gắng để hiểu, làm thế nào các ứng dụng web có thể không trạng thái khi có dữ liệu được lưu giữ cho phiên của tôi (chẳng hạn như các mặt hàng trong giỏ hàng)? Đây có thực sự được lưu trữ trong một cơ sở dữ liệu ở đâu đó và sau đó định kỳ bị thanh trừng? Làm thế nào để nó hoạt động khi bạn đang sử dụng mã thông báo thay vì cookie?

Về ví dụ giỏ hàng. Không có vấn đề gì khi lưu trữ tất cả các mục trong giỏ hàng mà không cần sử dụng phiên hoặc cookie. Bạn có thể tìm thấy một ví dụ trên smashingmagazine.com . Nhưng bạn cũng có thể nhận ra một giỏ mua hàng không trạng thái với cookie (ít nhất là nếu loại của bạn không quá lớn và dung lượng 4kb là đủ cho bạn).

Đừng hiểu sai ý tôi, điều đó không có nghĩa là bạn nên triển khai giỏ hàng không trạng thái với bất kỳ giá nào. Amazon hoặc các nền tảng mua sắm trực tuyến lớn khác đang sử dụng các triển khai giỏ hàng có trạng thái vì trải nghiệm người dùng và khả năng sử dụng là quan trọng đối với họ hơn là phù hợp với các yêu cầu phi chức năng kỹ thuật như khả năng mở rộng.

Nói chung, mã thông báo không được sử dụng để lưu trữ thông tin như các mặt hàng trong giỏ hàng. Chúng được sử dụng để xác thực và ủy quyền không quốc tịch.

Và sau đó là một câu hỏi liên quan, các trang web lớn (Amazon, Google, Facebook, Twitter, v.v.) có thực sự không trạng thái? Họ có sử dụng mã thông báo hoặc cookie (hoặc cả hai) không?

Nếu bạn đang hỏi liệu họ có đang sử dụng cookie hoặc mã thông báo để xác thực hay không, câu trả lời là họ sử dụng cả hai. Đối với người dùng, phần lớn cookie cho khách hàng kỹ thuật, phần lớn mã thông báo được sử dụng.

OK, quy tắc bạn trích dẫn là không chính xác về mặt kỹ thuật. Tất cả các lớp của một ứng dụng web có trạng thái.

Mục đích của quy tắc là "không giữ phía máy chủ trạng thái mỗi phiên".

Tức là, các biến phiên trong ASP , thường được sử dụng để làm những việc như các mục trong giỏ / tên người dùng, v.v.

Lý do là bạn sẽ hết bộ nhớ trên máy chủ khi ứng dụng của bạn có được nhiều người dùng hơn. Di chuyển bộ lưu trữ vào cơ sở dữ liệu hoặc bộ đệm chia sẻ không giải quyết được vấn đề vì bạn vẫn còn một nút cổ chai.

Để duy trì trạng thái ứng dụng cho mỗi người dùng mà không gặp phải sự cố này, hãy chuyển trạng thái sang phía máy khách. Ví dụ: đặt các mục trong giỏ vào cookie hoặc bộ lưu trữ phía máy khách nâng cao hơn.

Bởi vì số lượng khách hàng chia tỷ lệ với số lượng người dùng, toàn bộ ứng dụng của bạn sẽ không có nút cổ chai và sẽ mở rộng tốt.