##Giới thiệu
##Cài đặt
| I recently had to install MySQL 5.6 on Ubuntu 12.04 from a .deb package on the MySQL website. It seems that either the package has been updated recently or nobody uses this method to install so I ended up running into endless problems. Through trial and error I found the following method works for me. | |
| Install libaio-dev: | |
| sudo apt-get install libaio-dev | |
| Now install your package(mine was enterprise edition, community may have a different filename): | |
| sudo dpkg -i mysql-advanced-5.6.10-debian6.0-x86_64.deb | |
| This will install your files to the /opt directory, instead of the more common /etc directory. No worries, all we need to do is point our system at this new directory. |
##5. Session
Trong trong ứng dụng của bạn có một session cho mỗi use mà ở đó bạn có thể lưu trữ một lượng dữ liệu nhỏ mà nó được lưu lại giữa các request. Session cũng được dùng trong controller và view và có thể sử dụng một số cơ chế lưu trữ khác:
* ActionDispatch::Session::CookieStore - lưu trữ mọi thứ trên `client`.
* ActionDispatch::Session::CacheStore - Lưu trữ dữ liệu trên Rails cache.
* ActionDispatch::Session::ActiveRecordStore - Lưu trữ dữ liệu trên db sử dụng Active Record. (require activerecord-session_store gem).
* ActionDispatch::Session::MemCacheStore - Lưu trữ dữ liệu trên `memcached cluster `(Đây là một cách thực thi kế thừa ; hãy xem các sử dụng `CacheStore`). Tất cả session lưu trữ sử dụng cookie để lưu trữ một ID duy nhất cho mỗi session (bạn phải sử dụng một cookie, Rails sẽ không cho phép bạn truyền một session ID tới URL , điều này là kém an toàn).
Hầu hết các lưu trữ, ID được sử dụng để tìm kiếm dữ liệu session trên server, ví dụ như trong bản
##Hiểu về Rails Authenticity Token.
Vấn đề:
Khi người dùng xem một form để tạo, cập nhật hoặc xóa một resource, Rails sẽ tạo ngẫu nhiên một authenticity_token và lưu token này trong session, và đặt nó trong một hidden filed trong form. Khi người dùng submit form, Rails sẽ tìm kiếm authenticity_token, so sánh nó với một cái đã được lưu ở trong session. Nếu chúng phù hợp thì cho phép tiếp tục.
Tại sao lại có điều này:
Khi authenticity token được lưu ở trên session, phía client có thể không biết giá trị của token đó. Điều này ngăn chặn người dùng submit một form tới ứng dụng Rails mà không thông qua form của ứng dụng. Hãy tưởng tượng rằng bạn sử dụng một Services A, bạn đăng nhập vào Service đó, mọi thứ đều thành công. Bây giờ hãy tưởng tượng rằng bạn đã sử dụng Service B và bạn đã xem một bức anh mà bạn thích, và nhấn vào bức ảnh đó để xem với kích cỡ lớn hơn. Bây giờ, nếu có một vài mã ở trong Service B, nó có thể sẽ gửi tới Service A ( với Service mà bạn vừa đăng nhập),
##Routing Concerns
Trong Rails config / routes.rb tập tin đóng gói tất cả các ánh xạ từ các URL tới các action trong controller. Trong những năm qua, một số bổ sung hữu ích đã được thêm vào bởi các nhà phát triển, chúng ta có thể tránh lặp đi lặp lại. Một ví dụ của việc này là routing method resources , nó map 4 tên routes tới 7 action trong controller dựa trên phương thức request của HTTP.
Như của Rails 4, routes concern đã được thêm vào routes. routing concern cho phép bạn khai trong routes như thông thường, có thể được trộn vào các resource khác và routes
Một ví dụ phổ biến của việc lặp lại trong file config / routes.rb sẽ xảy ra khi polymorphic association được đặt trong một resource cha.
Đây là một ví dụ của nhiều resource có cùng comment:
Older::Application.routes.draw do
resources :projects do
resources :comments
##Edge Rails: PATCH là phương thức chính mới của HTTP cho việc cập nhật.
##PATCH là gì?
PUT method trong HTTP là việc tạo ra hay thay thế một resource tại một URL nào đó.
Trong ví dụ này giả sử bạn có nhiều file, nếu bạn upload 1 file vào S3 ở một URL nào đó, bạn muốn hoặc là tạo ra một file tại URL đó hoặc là thay thế một file đã tồn tại. Đó là PUT.
Bây giờ hãy giả sử rằng có một ứng dụng web có một model Invoice với paid một cờ trạng thái chỉ ra rằng khi nào thì hóa đơn (invoice) đã được thanh toán (paid là một trường trong db). Làm thế nào để có thể gán (cập nhật) cờ paid theo cách RESTful? Submit paid=1 thông qua phương thức PUT /invoices/:id không phù hợp với HTTP về mặt ngữ nghĩa bởi vì request không gửi một complete representation của invoice cho việc thay thế resource.
Nhưng giới hạn của các phương thức GET, POST, PUT, DELETE. Câu trả lời truyền thống là định nghĩa paid flag thành một resource riêng, và là một phần của invoice. Bạn định nghĩa
##SƠ LƯỢC VỀ REST Bạn có thể biết hoặc không biết được rằng có một cuộc tranh luận đang xảy ra về một phương pháp chính xác để thực hiện về việc giao tiếp không đồng nhất giữa các ứng dụng: Trong khi xu hướng tập chung vào web services dựa vào SOAP, WSDL và toàn bộ WS-*, Trong tình hình hiện nay co một bộ phận nhỏ đã đưa ra được một phương pháp tốt hơn đó là: REST (Representation State Stranfer). Trong bài viết này, tôi sẽ giới thiều về ứng dụng tương tác REST và RESTful HTTP mà không làm ảnh hưởng tới cuộc tranh luận. Tôi sẽ đi vào chi tiết hơn trong khi giải thích các khía cạnh bằng kinh nghiệm của tôi.
##KEY REST PRINCIPLES
Hầu hết các bài giới thiệu về REST đều bắt đầu theo kiểu định nghĩa và cơ bản, tôi sẽ không đề cập đến việc này trong một thời gian và cung cấp một số một số điều đơn giản, định nghĩa một cách thực tế: REST là một tập các qui tắc, định nghĩa chuẩn Web như HTTP và URI để sử dụng (thường khác một chút so với những gì nhiều người thực sự làm). Nếu bạn sử dụng REST trong quá trình thiết k