REST là gì?

Chào mừng bạn tới với website Blogchiaseaz, Hôm nay blogchiaseaz.com sẽ giới thiệu tới bạn về bài viết REST là gì?, Hãy cùng chúng tôi tìm hiểu rõ hơn về bài viết REST là gì? bên dưới

REST là gì?


Nội dung bài viết:


Bạn đang đọc: REST là gì?

1. REST là gì ?
2. Những ràng buộc chung của REST
3. Phần tử REST
4. RESTful triển khai
5. REST và HTTP
6. RESTful APIs

1. REST là gì?

– REST là một khái niệm kiểu kiến trúc ( Architecture Style ) được vận dụng cho những ứng dụng được nối mạng ( Networked Applications ). Nó sống sót như một loạt những ràng buộc ( Constraints ) được vận dụng cho việc tiến hành những thành phần mạng, được cho phép ngữ nghĩa giao diện thống nhất, thay vì những tiến hành và cú pháp dành riêng cho ứng dụng.

– REST là một kiến trúc mạng lần trước tiên được ghi lại bởi Roy Fielding trong luận án tiến sĩ của ông mang tiêu đề “Architectural Styles and the Design of Network-based Software Architectures”, được xuất bản vào năm 2000. REST cho phép máy khách (Clients) tương tác với dữ liệu được lưu trữ trên máy chủ (Servers) mà ko cần phải mang bất kỳ tri thức trước nào về máy chủ hoặc những gì tồn tại trên đó.


 

REST là viết tắt của gì?


REST là viết tắt của từ “ Representational State Transfer ”, trong tiếng Việt mang tức là “ Chuyển trạng thái trình diễn ”. Những người theo chủ nghĩa thuần túy viết tắt thường viết nó là ReST, vì chữ E trong REST ko thực sự đại diện thay mặt cho bất kể điều gì. Nó chỉ là vần âm thứ hai của từ “ Representational ”. Điều này tránh những tranh cãi về cách phát âm nó, giống như yếu tố đã gây khó khăn vất vả cho GIF trong những năm sắp đây. Với chữ E gồm mang, ko mang sự nhầm lẫn lúc phát âm từ viết tắt đúng mực hơn của RST là cổ tay “ wrist ” hoặc thậm chí còn là R-S-T.

2. Những ràng buộc chung của REST

– Ko mang khái niệm hoặc tiêu chuẩn đơn cử về REST là gì. Là một khái niệm về kiến trúc – Architecture, REST xác lập cách những thành phần khác nhau được link trải qua những trình liên kết và cách tài liệu được trao đổi qua những giao diện. REST là một loạt những ràng buộc hoặc nhu yếu mà lúc tuân theo, sẽ tạo ra việc tiến hành kiểu kiến trúc REST .

– Kiến trúc REST Architecture ko khuyến khích việc tạo ra những giải pháp bổ trợ, theo trường hợp đơn cử. Ví dụ, một kiến trúc REST Architecture sẽ sử dụng phương pháp GET để truy xuất tài liệu trong mọi trường hợp. Thay đổi duy nhất so với những loại tài liệu khác nhau sẽ là những thông số khác nhau. trái lại điều này với việc tạo một chiêu thức mới để lấy thông tin về người sử dụng ( getUser ) và một chiêu thức khác để lấy thông tin về Ngân sách chi tiêu ( getPricing ), v.v.

Client server ( Yêu cầu so với sever và máy khách )

  • Giao diện người sử dụng trên máy khách (Clients) tách biệt và độc lập với việc lưu trữ dữ liệu trên máy chủ (Servers). Điều này cho phép máy khách được triển khai và sửa đổi bất kể điều gì đang xảy ra trên máy chủ. Tương tự tương tự, dữ liệu trên máy chủ mang thể được sử dụng và sửa đổi bất kể máy khách đang truy cập bằng cách nào. Thiết kế tương tự cho phép cả hệ thống máy khách và máy chủ phát triển với tốc độ riêng của chúng, độc lập với nhau.

Stateless ( Ko trạng thái )

  • Ko mang dữ liệu phiên (Session Data) nào được lưu trữ trên máy chủ giữa những yêu cầu từ máy khách. Nói cách khác, mọi giao dịch phải mang theo khả năng hiểu yêu cầu hoàn toàn mà ko cần truy cập vào bất kỳ văn cảnh hoặc dữ liệu bổ sung nào được lưu trữ trên máy chủ. Tất cả dữ liệu phiên phải nằm độc quyền trên máy khách.
  • Ràng buộc này cho phép đơn thuần hóa việc thăng bằng tải (Load Balancing) hoặc khả năng chịu lỗi (Fault Tolerance). Một máy chủ khác mang thể đáp ứng từng và mọi yêu cầu từ máy khách và trả về cùng một dữ liệu mà máy chủ gốc sẽ mang, miễn sao cả hai máy chủ đều mang cùng dữ liệu gốc. Ko cần phải chuyển bất kỳ loại dữ liệu phiên cụ thể nào giữa những máy chủ thăng bằng tải tương tự. Những phiên ko phải là ko trạng thái (Stateless) mang thể dẫn tới những phản hồi khác nhau nếu yêu cầu được xử lý bởi một máy chủ khác, vì chỉ máy chủ trước đó mới mang dữ liệu cụ thể cho phiên đó với máy khách.

Cacheable data ( Dữ liệu hoàn toàn mang thể lưu vào bộ nhớ cache )

  • Trong mọi trao đổi, dữ liệu phải được đánh dấu là dữ liệu mang thể lưu vào bộ nhớ cache hoặc ko thể lưu trong bộ nhớ cache. Dữ liệu mang thể lưu vào bộ nhớ cache mang thể được máy khách lưu trữ và sử dụng lại. Ko mang dữ liệu nào được lưu trữ trên máy chủ vì điều này sẽ vi phạm ràng buộc nguyên tắc ko trạng thái (Stateless) ở trên. Khả năng lưu trữ dữ liệu vào bộ nhớ cache làm giảm băng thông vì ko cần băng thông để duy trì một phiên truy cập máy chủ – máy khách.

Uniform interface ( Giao diện thống nhất )

  • Để đạt được khả năng tương tác đầy đủ, giao diện được tách biệt khỏi loại dữ liệu miễn sao tất cả những tương tác hoạt động theo cùng một cách. Bốn ràng buộc phụ đảm bảo giao diện thống nhất: Định danh tài nguyên (Identification of Resources), Thao khống tài nguyên thông qua biểu tả (Manipulation of Resources via Representations), Thông điệp tự mô tả (Self-descriptive Messages) và Siêu phương tiện đóng vai trò Engine của ứng dụng HATEOAS “Hypermedia as The Engine Of the Application State (HATEOAS)”.

Định danh những tài nguyên ( Identification of Resources )

Bất kỳ thông tin nào mang thể được đặt tên đều là tài nguyên. Một tài nguyên mang thể là bất kỳ dạng dữ liệu nào. Định danh tài nguyên là một cách để tham chiếu tới một tài nguyên cụ thể tại một thời khắc cụ thể. Những tài nguyên đó mang thể được cập nhật trên máy chủ mà khách hàng ko cần phải mang tri thức trước vì mỗi yêu cầu đều được mô tả và trả lời đầy đủ.


 

Thao khống trải qua biểu tả ( Manipulation via representations )

Một biểu tả “Representation” là trạng thái hiện tại của tài nguyên, cùng với siêu dữ liệu (Metadata) đi kèm cho phép hiểu biểu tả đó. Định dạng dữ liệu (data format) của biểu tả xác định loại đa phương tiện (Media Type) của nó. Do đó, máy khách mang thể yêu cầu một tài nguyên, chẳng hạn như hình ảnh, từ một máy chủ bằng cách sử dụng mã định danh tài nguyên của tài nguyên đó (mang thể là URI) và bản trình bày hình ảnh đó bao gồm những byte tạo nên hình ảnh, cùng với siêu dữ liệu xác định định dạng dữ liệu như một loại phương tiện JPG sẽ được trả lại cho máy khách, sau đó mang thể hiển thị hình ảnh cho người sử dụng.


 

Thông điệp tự diễn đạt ( Self-descriptive messages )


Mọi thông tin từ máy khách tới máy chủ phải chứa tất cả những thông tin cần thiết để xử lý thông tin. Trong trường hợp bảo mật và xác thực, mã thông tin bảo mật phải được trao đổi trong mỗi tin nhắn.


Cookie rất phổ biến trên internet. Hành động rà soát cookie so với tất cả dữ liệu trong mọi thư sẽ là một ví dụ về thông điệp ko tự mô tả và do đó ko phải là RESTful về mặt kỹ thuật.


Siêu phương tiện đi lại là Engine của trạng thái ứng dụng ( HATEOAS )


Khái niệm siêu phương tiện (Hypermedia): Siêu phương tiện tương tự như khái niệm siêu văn bản (hypertext), hay siêu liên kết (hyperlink), ngoại trừ việc nó bao gồm tất cả những dạng phương tiện chứ ko chỉ văn bản hoặc liên kết. Đó là một cách phi tuyến tính để sản xuất thông tin hoặc dữ liệu thường thông qua việc theo một liên kết hoặc điểm đánh dấu khác trong tài nguyên đã xuất bản, chẳng hạn như một trang web. Siêu phương tiện mang thể là văn bản, đồ họa, video hoặc những dạng dữ liệu khác.


Theo HATEOAS, khách hàng tương tác qua mạng thông qua siêu phương tiện.


Máy khách tương tác với máy chủ chỉ sử dụng siêu phương tiện. Siêu phương tiện tương tự đó được máy chủ phân phối động theo yêu cầu RESTful request. Do đó, ko cần biết trước về dữ liệu trên máy chủ, cấu trúc của nó, cũng như cách dữ liệu đó được lưu trữ. Thay vào đó, chỉ cần sử dụng cấu trúc và phương pháp siêu phương tiện được xác định rõ ràng.

Layered system ( Hệ thống phân lớp )

  • Trong hệ thống những lớp phân cấp, ko thành phần nào mang thể tương tác với hoặc xem bất kỳ dữ liệu hoặc giao diện nào ngoại trừ trên lớp hiện tại của chính nó. Do đó, máy khách ko cần biết cách, thậm chí ko cần thiết phải kết nối với bất kỳ máy chủ, proxy, tường lửa, bộ định tuyến hoặc điểm cuối bổ sung nào. Thay vào đó, bất kỳ trung gian (intermediary) nào sẽ tiếp tục kết nối với những máy chủ tiếp theo theo những ràng buộc REST và kết quả là phản hồi cho bất kỳ yêu cầu nào được trả lại qua trung gian cho máy khách cũng sẽ tuân thủ REST. Do đó, những thay đổi hoặc gián đoạn đối với hệ thống trung gian là vô hình đối với máy khách cho phép những hệ thống trung gian đó sản xuất thăng bằng tải, bảo mật hoặc những chức năng khác.

Code on demand ( Code theo nhu yếu )

  • Mặc dù về mặt kỹ thuật được gắn nhãn là tùy chọn, những máy khách trong kiến trúc REST sẽ mang thể tải xuống và thực thi những tập lệnh. Điều này cho phép mở rộng những chức năng và hệ thống phức tạp hơn, trong lúc vẫn sản xuất giao tiếp kiểu REST giống nhau giữa máy khách và máy chủ. Như với những yêu cầu và phản hồi cơ bản, toàn bộ hướng dẫn chạy mã đã tập lệnh (scripted code) phải độc lập và ko yêu cầu triển khai trước trên máy khách.
  • Ví dụ: một ứng dụng khách web (web client) mang thể thực thi JavaScript mà nó nhận được từ máy chủ. Mặc dù Code nằm trên máy chủ, nhưng nó ko được thực thi ở đó. Thay vào đó, bản thân Code được gửi tới máy khách như một phần của yêu cầu và code đó được máy khách thực thi theo cách triển khai của nó. Đây là lý do vì sao việc triển khai những tiêu chuẩn thích hợp trong những ứng dụng khách web là rất quan yếu; nếu ko, cùng một mã từ máy chủ mang thể được thực thi với những kết quả khác nhau trên những máy khách khác nhau.


 

3. Những thành phần của REST


Data elements ( Những thành phần của tài liệu )

  • Những thành phần của hệ thống REST giao tiếp thông qua đặc tả tài nguyên ở một trong số những định dạng tiêu chuẩn hóa đã thống nhất như định dạng đồ họa (graphic formats), định dạng tài liệu (document formats) và những định dạng web (web formats) khác nhau. Một lần nữa, để trở thành một hệ thống REST thực sự, mỗi giao dịch phải mang khả năng truy xuất và diễn giải tài nguyên mong muốn.

 

Xem thêm: Tổng tổng giám đốc – Wikipedia tiếng Việt

Resource ( Tài nguyên )

  • Resource (Tài nguyên) là bất cứ thứ gì mang thể được đặt tên. Tài nguyên được lưu trữ trên máy chủ được máy khách yêu cầu. Tài nguyên mang thể là tệp tĩnh (static file), tài liệu (document), cơ sở vật chất dữ liệu (database), ảnh (picture) hoặc bất kỳ định dạng nào khác mang thể được yêu cầu.
  • Mặc dù hiện tại là một khái niệm phổ biến, nhưng ý tưởng ban sơ về tài nguyên như một phần tử thời khắc chung, mang thể thay đổi, là đặc điểm chính của REST và web nói chung. Tài nguyên là bất kỳ dữ liệu mang thể đặt tên nào trên máy chủ. Dữ liệu đó ko chỉ mang thể thay đổi thành phiên bản mới hơn của cùng một dữ liệu, mà thậm chí thành một loại dữ liệu hoàn toàn khác. Điều này cho phép dữ liệu trên máy chủ được cập nhật bất kỳ lúc nào mà ko cần bất kỳ máy khách nào biết trước về nó, một tính năng chính của khả năng tương tác và tính khả dụng.

Resource identifier ( Định danh tài nguyên )

  • Resource identifier (Định danh tài nguyên) là vị trí cụ thể của tài nguyên được yêu cầu. Trong trường hợp hệ thống dựa trên HTTP, định danh tài nguyên là URL hoặc URI. Định danh tài nguyên chỉ định một tài nguyên. Một mã định danh tài nguyên duy nhất mang thể tham chiếu tới dữ liệu hoặc tài nguyên khác nhau vào những thời khắc khác nhau. Trong một hệ thống tuân thủ REST, máy khách ko cần biết trước loại tài nguyên mà định danh tài nguyên đang yêu cầu. Phản hồi sẽ bao gồm siêu dữ liệu mô tả cách diễn giải dữ liệu nhận được.
  • Ví dụ: ngay cả lúc yêu cầu URL mang trạng thái là “/server/index.html”, nếu tài nguyên tại liên hệ đó trả về trình diễn dưới dạng tệp hình ảnh, cùng với siêu dữ liệu tương ứng, tệp hình ảnh sẽ vẫn được hiển thị chuẩn xác bất kể tài nguyên là gì, định danh tài nguyên sẽ cho biết.

Representations ( Biểu tả )

  • Biểu tả nói tới dữ liệu được gửi tới máy khách. Như đã nói ở trên, biểu tả phải là một trong những định dạng dữ liệu được chuẩn hóa. Dữ liệu ko được xử lý trên máy chủ mà được máy khách thông dịch. Ví dụ: một ứng dụng khách yêu cầu một tài liệu HTML ko nhận được một đồ họa để hiển thị trên màn hình, mà là một tập hợp mã HTML code sau đó được diễn giải và hiển thị trên ứng dụng khách. Những ví dụ biểu tả khác bao gồm những tệp đồ họa như ảnh JPEG và GIF.

Representation metadata ( Siêu dữ liệu biểu tả )

  • Representation metadata (Siêu dữ liệu biểu ta) sản xuất thông tin trình bày cho hệ thống. Cũng giống như với hầu hết những siêu dữ liệu, siêu dữ liệu biểu tả thường ko phải là một phần của những gì được hiển thị cho người sử dụng cuối. Siêu dữ liệu biểu tả mang thể bao gồm thông tin về loại phương tiện (media type), ngày tạo (created date) và sửa đổi (modified date) cũng như số phiên bản (version number).

Resource metadata ( Siêu dữ liệu tài nguyên )

  • Siêu dữ liệu tài nguyên là thông tin bổ sung được sản xuất cho hệ thống về tài nguyên tồn tại trên máy chủ chứ ko phải là thông tin trình bày về tài nguyên được hiển thị trên máy khách. Ví dụ về siêu dữ liệu tài nguyên bao gồm liên kết nguồn (source links), hiển thị thay thế (alternates) và thông tin về tài nguyên. Ví dụ: siêu dữ liệu tài nguyên mang thể bao gồm văn bản thay thế được hiển thị trong trường hợp ko thể hiển thị trình diễn hình ảnh vì một số lý do (ví dụ: văn bản hình ảnh ALT trong HTML).

Control data ( Dữ liệu trấn áp )

  • Dữ liệu kiểm soát chủ yếu quan tâm tới tính hợp thức của tài nguyên và sự thể hiện trình bày của nó trên máy khách. Dữ liệu kiểm soát bao gồm việc dữ liệu mang thể lưu vào bộ nhớ cache hay ko, cũng như thời kì hết hạn tuyệt đối (Expiry Time) hoặc sản xuất giới hạn về thời lượng dữ liệu được sử dụng. Dữ liệu kiểm soát cũng mang thể bao gồm Checksum hoặc những phương tiện khác để đảm bảo tính toàn vẹn.

 

4. Triển khai RESTful (RESTful implementation)

– Lúc tích hợp với nhau, kiến trúc REST Architecture tạo ra một khung đồng nhất ( gọi là Framework ) mang năng lực lan rộng ra cao, trọn vẹn sáng tỏ và hoàn toàn mang thể tái sử dụng, trong đó những máy khách được tách ra khỏi việc cấy ghép những nhà sản xuất trên sever. Nó độc lập với nền tảng, cho cả máy khách và sever. Nó là ngôn từ và cấu trúc độc lập. Sẽ ko mang yếu tố gì nếu tài liệu sống sót trong cơ sở vật chất tài liệu, được truy xuất bởi những tiến trình của sever Java Server và được gửi tới một chương trình cục bộ – ví dụ tiêu biểu như trình duyệt – được code bằng một trong 1 số ít phiên bản ngôn từ lập trình C .

– Trên những website tân tiến, REST được tiến hành bằng cách sử dụng một bảng từ vựng tiêu chuẩn chung giữa máy khách và sever được gọi là Giao thức truyền siêu văn bản ( Hypertext Transfer Protocol ), hoặc HTTP. Tuy nhiên, bất kể tiến hành nào tương thích với tổng thể những đối tượng người sử dụng thuê ( tenant ) của kiến trúc REST đều được coi là tiến hành RESTful. HTTP ko phải là năng lực duy nhất .

5. REST và HTTP

– Mặc dù HTTP và REST ko giống nhau, nhưng HTTP là dạng khởi đầu và là một tiến hành của REST. Điều này ko mang gì đáng quá bất thần lúc Roy Fielding đang thao tác trên giao thức HTTP 1.1, đồng thời tăng trưởng kiến trúc REST Architecture .

Identification of resources in HTTP ( Nhận dạng tài nguyên trong HTTP )

  • Mỗi tài nguyên được xác định bởi một Mã Định Danh Tài Nguyên Duy Nhất URI (URI – Uniform Resource Identifier). Thông thường, điều này được triển khai dưới dạng URL trong trình duyệt web. URI xác định một tài nguyên. Ko mang tri thức trước về hệ thống nơi tài nguyên nằm trên máy chủ là đề nghị. Ngoài ra, URI (hoặc URL) mang thể chỉ định đại diện của một tài nguyên mà ko cần biết về cấu trúc tệp của tài nguyên đó.

Representation of resources ( Biểu tả những tài nguyên )

  • Trong HTTP, việc trình bày tài nguyên được thực hiện thông qua tương trợ cho nhiều loại tệp khác nhau trong trình duyệt HTTP. Do đó, siêu dữ liệu đi kèm với tài nguyên xác định một trong số những định dạng tệp được tương trợ rộng rãi như HTML, CSS, JPG, GIF, v.v.

HTTP methods ( Phương thức HTTP )

  • Việc triển khai REST thuần túy của HTTP yêu cầu sử dụng bốn phương thức cốt lõi (Core Methods) là GET, POST, PUT và DELETE. Mỗi phương thức phải được sử dụng một cách rõ ràng và được ánh xạ tới một trong từng hành động cốt lõi XÁC LẬP DỮ LIỆU (RETRIEVE DATA), TẠO TÀI NGUYÊN (CREATE RESOURCE), CẬP NHẬT TÀI NGUYÊN (UPDATE RESOURCE) và XÓA TÀI NGUYÊN (DELETE RESOURCE).

Idempotence ( Lý tưởng )

  • Một số phương thức HTTP method nhất định phải là lý tưởng. Lý tưởng mang tức là việc thực thi cùng một phương thức với những thông số giống nhau sẽ luôn trả về cùng một kết quả. Để điều này hoạt động, phương thức (method) được nói ko thể gây ra bất kỳ sửa đổi nào trên máy chủ làm cho kết quả khác được trả về cho cùng một yêu cầu. Trong những khía cạnh thực tế, một yêu cầu ko nên thay đổi dữ liệu dựa trên máy chủ.

GET, POST, PUT, DELETE

  • Được sử dụng để lấy một tài nguyên hoặc thông tin về tài nguyên đó. Mặc dù hầu hết những triển khai HTTP sẽ xử lý những thông số (parameters) với yêu cầu GET để sửa đổi (modify) hoặc tạo (create) tài nguyên, nhưng hành động tương tự sẽ ko tuân thủ triển khai RESTful. Yêu cầu GET phải là lý tưởng.
  • Yêu cầu POST tạo dữ liệu mới trên máy chủ. Theo khái niệm, một yêu cầu POST sẽ KHÔNG phải là lý tưởng. Với mỗi lần thực thi, một yêu cầu POST sẽ tạo ra nhiều dữ liệu hơn.
  • Tương tự như yêu cầu POST, yêu cầu PUT sửa đổi dữ liệu hiện mang. Ví dụ: thay đổi họ của người sử dụng hiện tại. Những yêu cầu PUT ko phải là lý tưởng. Mặc dù một yêu cầu PUT thực hiện thay đổi dữ liệu, nhưng nó thực hiện theo cùng một cách mọi lúc. Do đó, việc chạy một yêu cầu PUT thay đổi họ của người sử dụng sẽ luôn tạo ra cùng một kết quả miễn sao tất cả những thông số đều nhất quán.
  • Yêu cầu DELETE gỡ bỏ hoặc xóa dữ liệu, đúng như tên của yêu cầu này. Yêu cầu DELETE cũng rất quan yếu ở chỗ việc chạy lặp lại một yêu cầu sẽ luôn dẫn tới cùng một trạng thái cuối cùng với dữ liệu được nói ko còn tồn tại trên máy chủ. Tuy nhiên, đối với máy khách, mang thể mang sự khác biệt ở chỗ lúc tài nguyên bị xóa, yêu cầu mang thể được trả lời với một thông tin lỗi chẳng hạn như ko tìm thấy tệp. Tuy nhiên, phương thức (method) này vẫn được coi là ko lý tưởng, bởi vì bất kể lỗi nào được gửi trong quá trình giao dịch, trạng thái kết thúc của một yêu cầu tương tự vẫn giống như lần trước tiên nó được yêu cầu.

6. RESTful APIs

– Những nhu yếu so với một RESTful API

  • Trong một bài đăng trên blog hiện đã bị bỏ rơi của mình, Roy Fielding đã thảo luận về những tiêu chí mà một API phải đáp ứng để được coi là thực sự RESTful. Dựa trên luận điểm đã xuất bản trước đây của Roy Fielding, bài đăng này mô tả những khái niệm kiến trúc REST Architecture giống như chúng nên vận dụng cho những API.
  • Do đó, một API RESTful là một API mà nó CHỈ sử dụng kiến trúc REST Architecture mà ko cần thêm tài liệu hoặc phương thức ngoài những thứ thích hợp với mô phỏng. Fielding sản xuất những điểm sau để làm rõ điều gì làm cho REST API tuân thủ.

Independence of protocol ( Tính độc lập của giao thức )


Một RESTful API thực sự ko nên phụ thuộc vào bất kỳ giao thức nào và phải mang thể tương trợ bất kỳ giao thức nào sử dụng URI để nhận dạng. Nếu ko, nhận dạng ko tách rời khỏi tương tác.


 

Support of protocols as standardized (Tương trợ những giao thức được tiêu chuẩn hóa)


RESTful API ko nên yêu cầu thay đổi những giao thức được chuẩn hóa, đặc thù là việc bổ sung những tính năng bổ sung. Bất cứ lúc nào mang thể, bất kỳ giải pháp thay thế đề nghị nào phải được xác định riêng với mục tiêu loại bỏ chúng hoàn toàn lúc những giải pháp thay thế ko còn cần thiết nữa.


 

Does not define fixed resources (Ko xác định tài nguyên khăng khăng)


Ko gian tên máy chủ phải độc lập với khái niệm và yêu cầu API. Nói cách khác, API phải hoạt động với bất kỳ máy chủ nào mang khả năng REST, ko chỉ những máy chủ tuân theo một đặc tả API cụ thể.

 


 

Xem thêm: Cùng Tìm Hiểu Những Chức Danh Giám Đốc Trong Công Ty

Dịch : N.V.Hùng

Source: https://blogchiaseaz.com
Category: Hỏi Đáp

Tham khảo thêm: REST là gì?

Related Posts