a

Câu hỏi Chính xác là lập trình RESTful là gì?


Chính xác là lập trình RESTful là gì?


3630
2018-03-22 14:45


gốc


xem thêm câu trả lời tại liên kết sau stackoverflow.com/a/37683965/3762855 - Ciro Corvino
REST có thể đang nhận được một chút cũ;) youtu.be/WQLzZf34FJ8 - Vlady Veselinov
Ngoài ra, hãy tham khảo liên kết này để biết thêm thông tin news.ycombinator.com/item?id=3538585 - Ashraf.Shk786
Sửa chữa câu trả lời được chấp nhận ở đây. stackoverflow.com/questions/19843480/…  Hay ở đây roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven  Hay ở đây web.archive.org/web/20130116005443/http://tomayko.com/writings/… - kushalvm
@ OLIVER.KOO quan sát tốt đẹp. Nó chỉ là tôi đã hỏi nó vào một thời điểm khi nó là một loại mới. Nó đã được ném xung quanh rất nhiều nhưng không nhiều người biết nó là gì. Ít nhất là tôi không, và có vẻ như tôi hỏi điều này đã giúp họ vì họ cũng muốn biết. - hasen


Các câu trả lời:


An phong cách kiến ​​trúc gọi là REST (Chuyển trạng thái đại diện) ủng hộ các ứng dụng web nên sử dụng HTTP vì nó ban đầu được hình dung. Tra cứu nên sử dụng GET yêu cầu. PUT, POSTDELETE yêu cầu nên được sử dụng cho đột biến, tạo và xóa tương ứng.

Những người ủng hộ REST có xu hướng ưu tiên các URL, chẳng hạn như

http://myserver.com/catalog/item/1729

nhưng kiến ​​trúc REST không yêu cầu những "URL đẹp" này. Yêu cầu GET có tham số

http://myserver.com/catalog?item=1729

là mỗi bit như RESTful.

Hãy nhớ rằng các yêu cầu GET sẽ không bao giờ được sử dụng để cập nhật thông tin. Ví dụ: yêu cầu GET để thêm mục vào giỏ hàng

http://myserver.com/addToCart?cart=314159&item=1729

sẽ không phù hợp. Yêu cầu GET phải là NULL. Tức là, việc phát hành một yêu cầu hai lần sẽ không khác với việc phát hành nó một lần. Đó là những gì làm cho các yêu cầu có thể lưu trữ được. Yêu cầu "thêm vào giỏ hàng" không phải là idempotent — phát hành hai lần thêm hai bản sao của mặt hàng vào giỏ hàng. Yêu cầu POST rõ ràng là phù hợp trong ngữ cảnh này. Do đó, ngay cả một Ứng dụng web RESTful cần chia sẻ các yêu cầu POST.

Điều này được lấy từ cuốn sách tuyệt vời Mặt JavaServer chính cuốn sách của David M. Geary.


541
2018-04-15 11:26



Các hoạt động không có sẵn của Lisiting: GET (Safe), PUT & DELETE (Ngoại lệ được đề cập trong liên kết này restapitutorial.com/lessons/idempotency.html). Tham khảo bổ sung cho các phương pháp an toàn & Idempotent w3.org/Protocols/rfc2616/rfc2616-sec9.html - Abhijeet
a) điểm quan trọng về GET là sự an toàn, không phải là tính ngẫu nhiên, b) @Abhijeet: RFC 2616 đã bị lỗi thời vào năm 2014; xem RF 7230ff. - Julian Reschke
Cái này sai. Đọc điều này để giải thích chính xác REST roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven  hay cái này stackoverflow.com/questions/19843480/… - kushalvm
@ kushalvm Định nghĩa học thuật của REST đó không được sử dụng trong thực tế. - Elliott Beach
REST không bao giờ có ý định được sử dụng cho các API web, chỉ dành cho các tài nguyên tĩnh và chúng là siêu hướng. Tuy nhiên, Fielding, trong tất cả sự ngây thơ học tập của mình, nghĩ rằng họ sẽ được duy trì với sự trợ giúp của tất cả các động từ HTTP này trực tiếp từ một trình duyệt, điều này không thực tế ở bất kỳ tỷ lệ hoặc hình thức nào. REST là gì, nhưng một loạt các buzzwords vô ích và nên bị bỏ rơi càng sớm càng tốt. - Vadim Ferderer


NGHỈ NGƠI là nguyên tắc kiến ​​trúc cơ bản của web. Điều tuyệt vời về web là thực tế là các máy khách (trình duyệt) và các máy chủ có thể tương tác theo những cách phức tạp mà không cần máy khách biết trước về máy chủ và các tài nguyên mà máy chủ lưu trữ. Ràng buộc chính là máy chủ và máy khách phải đồng ý về phương tiện truyền thông được sử dụng, trong trường hợp của web là HTML.

API tuân thủ các nguyên tắc của NGHỈ NGƠI không yêu cầu khách hàng biết bất cứ điều gì về cấu trúc của API. Thay vào đó, máy chủ cần cung cấp bất kỳ thông tin nào mà khách hàng cần để tương tác với dịch vụ. An Biểu mẫu HTML là một ví dụ về điều này: Máy chủ chỉ định vị trí của tài nguyên và các trường bắt buộc. Trình duyệt không biết trước nơi gửi thông tin và không biết trước thông tin nào cần gửi. Cả hai hình thức thông tin đều được cung cấp hoàn toàn bởi máy chủ. (Nguyên tắc này được gọi là HATEOAS: Hypermedia là động cơ của trạng thái ứng dụng.)

Vậy, điều này áp dụng như thế nào HTTPvà làm thế nào nó có thể được thực hiện trong thực tế? HTTP được định hướng xung quanh động từ và tài nguyên. Hai động từ trong sử dụng chính là GET và POST, mà tôi nghĩ mọi người sẽ nhận ra. Tuy nhiên, tiêu chuẩn HTTP định nghĩa một số khác như PUT và DELETE. Các động từ này sau đó được áp dụng cho các tài nguyên, theo các hướng dẫn được cung cấp bởi máy chủ.

Ví dụ, Hãy tưởng tượng rằng chúng ta có một cơ sở dữ liệu người dùng được quản lý bởi một dịch vụ web. Dịch vụ của chúng tôi sử dụng siêu dữ liệu tùy chỉnh dựa trên JSON, mà chúng tôi chỉ định mimetype ứng dụng / json + userdb (Cũng có thể có một application / xml + userdb và ứng dụng / bất cứ điều gì + userdb - nhiều loại phương tiện có thể được hỗ trợ). Máy khách và máy chủ đều được lập trình để hiểu định dạng này, nhưng chúng không biết gì về nhau. Như Roy Fielding chỉ ra:

REST API nên dành hầu như tất cả các nỗ lực mô tả của nó trong   xác định loại phương tiện được sử dụng để biểu diễn tài nguyên và lái xe   trạng thái ứng dụng hoặc xác định tên quan hệ mở rộng và / hoặc   đánh dấu cho phép siêu văn bản cho các loại phương tiện chuẩn hiện có.

Yêu cầu cho tài nguyên cơ sở / có thể trả về một cái gì đó như thế này:

Yêu cầu

GET /
Accept: application/json+userdb

Phản ứng

200 OK
Content-Type: application/json+userdb

{
    "version": "1.0",
    "links": [
        {
            "href": "/user",
            "rel": "list",
            "method": "GET"
        },
        {
            "href": "/user",
            "rel": "create",
            "method": "POST"
        }
    ]
}

Chúng tôi biết từ mô tả về phương tiện truyền thông của chúng tôi rằng chúng tôi có thể tìm thấy thông tin về các tài nguyên có liên quan từ các phần được gọi là "liên kết". Cái này được gọi là Điều khiển Hypermedia. Trong trường hợp này, chúng ta có thể nói từ một phần như vậy mà chúng ta có thể tìm thấy một danh sách người dùng bằng cách thực hiện một yêu cầu khác cho /user:

Yêu cầu

GET /user
Accept: application/json+userdb

Phản ứng

200 OK
Content-Type: application/json+userdb

{
    "users": [
        {
            "id": 1,
            "name": "Emil",
            "country: "Sweden",
            "links": [
                {
                    "href": "/user/1",
                    "rel": "self",
                    "method": "GET"
                },
                {
                    "href": "/user/1",
                    "rel": "edit",
                    "method": "PUT"
                },
                {
                    "href": "/user/1",
                    "rel": "delete",
                    "method": "DELETE"
                }
            ]
        },
        {
            "id": 2,
            "name": "Adam",
            "country: "Scotland",
            "links": [
                {
                    "href": "/user/2",
                    "rel": "self",
                    "method": "GET"
                },
                {
                    "href": "/user/2",
                    "rel": "edit",
                    "method": "PUT"
                },
                {
                    "href": "/user/2",
                    "rel": "delete",
                    "method": "DELETE"
                }
            ]
        }
    ],
    "links": [
        {
            "href": "/user",
            "rel": "create",
            "method": "POST"
        }
    ]
}

Chúng tôi có thể nói rất nhiều từ phản hồi này. Ví dụ, bây giờ chúng ta biết chúng ta có thể tạo một người dùng mới bằng cách POST tới /user:

Yêu cầu

POST /user
Accept: application/json+userdb
Content-Type: application/json+userdb

{
    "name": "Karl",
    "country": "Austria"
}

Phản ứng

201 Created
Content-Type: application/json+userdb

{
    "user": {
        "id": 3,
        "name": "Karl",
        "country": "Austria",
        "links": [
            {
                "href": "/user/3",
                "rel": "self",
                "method": "GET"
            },
            {
                "href": "/user/3",
                "rel": "edit",
                "method": "PUT"
            },
            {
                "href": "/user/3",
                "rel": "delete",
                "method": "DELETE"
            }
        ]
    },
    "links": {
       "href": "/user",
       "rel": "list",
       "method": "GET"
    }
}

Chúng tôi cũng biết rằng chúng tôi có thể thay đổi dữ liệu hiện có:

Yêu cầu

PUT /user/1
Accept: application/json+userdb
Content-Type: application/json+userdb

{
    "name": "Emil",
    "country": "Bhutan"
}

Phản ứng

200 OK
Content-Type: application/json+userdb

{
    "user": {
        "id": 1,
        "name": "Emil",
        "country": "Bhutan",
        "links": [
            {
                "href": "/user/1",
                "rel": "self",
                "method": "GET"
            },
            {
                "href": "/user/1",
                "rel": "edit",
                "method": "PUT"
            },
            {
                "href": "/user/1",
                "rel": "delete",
                "method": "DELETE"
            }
        ]
    },
    "links": {
       "href": "/user",
       "rel": "list",
       "method": "GET"
    }
}

Lưu ý rằng chúng ta đang sử dụng các động từ HTTP khác nhau (GET, PUT, POST, DELETE, vv) để thao tác các tài nguyên này, và kiến ​​thức duy nhất mà chúng ta giả định trên phần máy khách là định nghĩa phương tiện của chúng ta.

Đọc thêm:

(Câu trả lời này đã là chủ đề của một số tiền công bằng của những lời chỉ trích vì thiếu điểm. Đối với hầu hết các phần, đó đã là một phê bình công bằng.Tôi đã mô tả ban đầu là phù hợp hơn với cách REST thường được thực hiện một vài năm trước đây khi tôi đầu tiên đã viết điều này, thay vì ý nghĩa thực sự của nó. Tôi đã sửa đổi câu trả lời để thể hiện tốt hơn ý nghĩa thực sự.)


2788
2018-03-22 19:37



Không. REST không chỉ bật lên như một từ thông dụng khác. Nó đến như là một phương tiện mô tả một sự thay thế cho trao đổi dữ liệu dựa trên SOAP. Thuật ngữ REST giúp khung thảo luận về cách chuyển và truy cập dữ liệu. - tvanfosson
Tuy nhiên, trái tim của REST (trong ứng dụng thực tế) là "không sử dụng GET để thực hiện thay đổi, sử dụng POST / PUT / DELETE", đó là lời khuyên tôi đã nghe (và sau) từ lâu trước khi SOAP xuất hiện. NGHỈ NGƠI có luôn luôn ở đó, nó chỉ không nhận được một tên vượt quá "con đường để làm điều đó" cho đến gần đây. - Dave Sherohman
Đừng quên "Siêu văn bản là công cụ của trạng thái ứng dụng". - Hank Gay
Câu trả lời này bỏ lỡ điểm. HTTP hầu như không được đề cập trong luận án của Fielding. - user359996
Câu trả lời này không đề cập đến mục đích của REST, và làm cho nó có vẻ như là tất cả về các URI sạch. Mặc dù điều này có thể là nhận thức phổ biến về REST, câu trả lời của D.Shawley và oluies chính xác hơn - đó là về việc có thể tận dụng các tính năng được xây dựng trong kiến ​​trúc, như bộ nhớ đệm, bằng cách làm việc với nó thay vì chống lại nó. URI đẹp hơn chủ yếu là tác dụng phụ thường gặp. - T.R.


Lập trình RESTful là về:

  • tài nguyên được xác định bằng số nhận dạng liên tục: URI là sự lựa chọn phổ biến của số nhận dạng những ngày này
  • các tài nguyên được điều khiển bằng cách sử dụng một tập hợp các động từ thông thường: các phương thức HTTP là trường hợp thường thấy - đáng kính Create, Retrieve, Update, Delete trở thành POST, GET, PUTDELETE. Nhưng REST không bị giới hạn ở HTTP, nó chỉ là phương tiện được sử dụng phổ biến nhất hiện nay.
  • đại diện thực tế được truy xuất cho tài nguyên phụ thuộc vào yêu cầu và không phải là số nhận dạng: sử dụng Chấp nhận tiêu đề để kiểm soát xem bạn có muốn XML, HTTP hoặc thậm chí đối tượng Java đại diện cho tài nguyên hay không
  • duy trì trạng thái trong đối tượng và biểu diễn trạng thái trong biểu diễn
  • đại diện cho các mối quan hệ giữa các nguồn lực trong việc biểu diễn tài nguyên: các liên kết giữa các đối tượng được nhúng trực tiếp vào biểu diễn
  • các biểu diễn tài nguyên mô tả cách biểu diễn có thể được sử dụng và trong hoàn cảnh nào nó nên được loại bỏ / được nạp lại một cách nhất quán: sử dụng các tiêu đề Kiểm soát bộ nhớ cache HTTP

Người cuối cùng có lẽ là quan trọng nhất về hậu quả và hiệu quả tổng thể của REST. Nhìn chung, hầu hết các cuộc thảo luận RESTful dường như tập trung vào HTTP và cách sử dụng nó từ trình duyệt và những gì không. Tôi hiểu rằng R. Fielding đã đặt ra thuật ngữ khi ông mô tả kiến ​​trúc và các quyết định dẫn đến HTTP. Luận án của ông là nhiều hơn về kiến ​​trúc và khả năng bộ nhớ cache của tài nguyên hơn là về HTTP.

Nếu bạn thực sự quan tâm đến kiến ​​trúc RESTful là gì và tại sao nó hoạt động, hãy đọc luận án của mình một vài lần và đọc tất cả mọi thứ không chỉ Chương 5! Tiếp theo nhìn vào tại sao DNS hoạt động. Đọc về tổ chức phân cấp DNS và cách hoạt động của các giới thiệu. Sau đó đọc và xem xét cách hoạt động của bộ nhớ đệm DNS. Cuối cùng, đọc các đặc tả HTTP (RFC2616 và RFC3040 đặc biệt) và xem xét cách thức và lý do bộ nhớ đệm hoạt động theo cách của nó. Cuối cùng, nó sẽ chỉ cần nhấp. Điều mặc khải cuối cùng đối với tôi là khi tôi thấy sự giống nhau giữa DNS và HTTP. Sau đó, sự hiểu biết tại sao SOA và thông điệp giao diện truyền thông có thể mở rộng bắt đầu bấm.

Tôi nghĩ rằng thủ thuật quan trọng nhất để hiểu tầm quan trọng kiến ​​trúc và ý nghĩa hiệu suất của một RESTful và Không chia sẻ kiến trúc là để tránh bị treo lên trên công nghệ và chi tiết thực hiện. Tập trung vào những người sở hữu tài nguyên, người chịu trách nhiệm tạo / duy trì chúng, vv Sau đó, suy nghĩ về các biểu diễn, giao thức và công nghệ.


500
2017-07-04 05:47



Câu trả lời cung cấp một danh sách đọc rất thích hợp cho câu hỏi này. - ellisbben
Cảm ơn các cập nhật. PUT và POST không thực sự bản đồ một-với-một với cập nhật và tạo ra. PUT có thể được sử dụng để tạo ra nếu máy khách đang đọc chính xác URI sẽ là gì. POST tạo ra nếu máy chủ được gán URI mới. - D.Shawley
Đừng quên PATCH. - epitka
URN là URI sử dụng urn: kế hoạch. Khái niệm không có sự khác biệt; tuy nhiên, URN yêu cầu bạn phải có phương pháp xác định riêng để "định vị" tài nguyên được URN xác định (có tên). Cần phải cẩn thận để đảm bảo rằng bạn không giới thiệu khớp nối ngầm khi liên quan đến các nguồn tài nguyên có tên và vị trí của chúng. - D.Shawley
@ellisbben Đồng ý. Nếu tôi hiểu chính xác đây là luận án đã làm nảy sinh REST: ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm - Philip Couling


Đây là những gì nó có thể trông giống như.

Tạo một người dùng với ba thuộc tính:

POST /user
fname=John&lname=Doe&age=25

Máy chủ phản hồi:

200 OK
Location: /user/123

Trong tương lai, bạn có thể truy xuất thông tin người dùng:

GET /user/123

Máy chủ phản hồi:

200 OK
<fname>John</fname><lname>Doe</lname><age>25</age>

Để sửa đổi bản ghi (lname và age sẽ vẫn không thay đổi):

PATCH /user/123
fname=Johnny

Để cập nhật bản ghi (và do đó lname và age sẽ là NULL):

PUT /user/123
fname=Johnny

392
2017-11-18 20:46



Đối với tôi câu trả lời này đã nắm bắt được bản chất của câu trả lời mong muốn. Đơn giản và thực dụng. Cấp có rất nhiều tiêu chí khác, nhưng ví dụ được cung cấp là một bệ phóng tuyệt vời. - CyberFonic
Trong ví dụ cuối cùng, @pbreitenbach sử dụng PUT fname=Jonny. Điều này sẽ thiết lập lname và age thành các giá trị mặc định (có thể là NULL hoặc chuỗi rỗng và số nguyên 0), bởi vì PUT  ghi đè toàn bộ tài nguyên với dữ liệu từ biểu diễn được cung cấp. Đây không phải là những gì được ngụ ý bởi "cập nhật", để thực hiện cập nhật thực, hãy sử dụng PATCH phương pháp vì điều này không làm thay đổi các trường không được chỉ định trong biểu diễn. - Nicholas Shanks
Nicholas nói đúng. Ngoài ra, URI cho POST đầu tiên tạo người dùng nên được gọi là người dùng vì /user/1 không có ý nghĩa và cần có một danh sách tại /users. Câu trả lời phải là 201 Created và không chỉ OK trong trường hợp đó. - DanMan
Nicholas và DanMan đúng. Câu trả lời này ngắn gọn nhưng có một số sai sót. - leslie.zhang
Đây chỉ là một ví dụ về một API không nhất thiết là một api RESTful. Một RESTful có những ràng buộc mà nó tuân theo. Kiến trúc Client-Server, Stateless, Cache-ability, Layered System, Uniform Interface. - Radmation


Một cuốn sách tuyệt vời trên REST là REST trong thực tế.

Phải đọc là Chuyển trạng thái đại diện (REST) và API REST phải được định hướng siêu văn bản 

Xem Martin Fowlers viết bài Richardson Maturity Người mẫu (RMM) cho một lời giải thích về một dịch vụ RESTful là gì.

Richardson Maturity Model

Để được RESTful một Dịch vụ cần phải hoàn thành Hypermedia là Công cụ của Nhà nước ứng dụng. (HATEOAS), có nghĩa là, nó cần đạt đến cấp độ 3 trong RMM, đọc bài báo để biết chi tiết hoặc trang trình bày từ cuộc hội thoại qcon.

Ràng buộc HATEOAS là từ viết tắt   cho Hypermedia là Engine của   Trạng thái ứng dụng. Nguyên tắc này là   sự khác biệt chính giữa một REST   và hầu hết các dạng máy khách khác   hệ thống.

...

Một khách hàng của một ứng dụng RESTful cần   chỉ biết một URL cố định duy nhất để truy cập   nó. Tất cả các hành động trong tương lai nên   có thể khám phá được từ   liên kết hypermedia có trong   đại diện cho các tài nguyên   được trả lại từ URL đó.   Các loại phương tiện được chuẩn hóa cũng   dự kiến ​​sẽ được hiểu bởi bất kỳ   khách hàng có thể sử dụng API RESTful.   (Từ Wikipedia, bách khoa toàn thư miễn phí)

Thử nghiệm REST Litmus cho các khung web là một thử nghiệm trưởng thành tương tự cho các khung công tác web.

Tiếp cận REST thuần túy: Học cách yêu HATEOAS là một tập hợp các liên kết tốt.

REST so với SOAP cho Đám mây công cộng thảo luận về mức sử dụng REST hiện tại.

REST và phiên bản thảo luận về khả năng mở rộng, phiên bản, Evolvability, vv  thông qua khả năng thay đổi


170
2018-03-22 15:20



Tôi nghĩ câu trả lời này chạm vào điểm mấu chốt của sự hiểu biết REST: từ đó là gì đại diện nghĩa là. Cấp 1 - Tài nguyên nói về tiểu bang. Cấp 2 - Các động từ HTTP nói về chuyển khoản (đọc thay đổi). Cấp độ 3 - HATEOAS cho biết việc chuyển giao trong tương lai thông qua biểu diễn (JSON / XML / HTML được trả về), có nghĩa là bạn đã biết cách nói vòng tiếp theo của cuộc trò chuyện với thông tin được trả về. Vì vậy, REST đọc: "(representational (state transfer))", thay vì "((representational state) transfer)". - lcn
Sự khác biệt giữa REST và POX - nobar


REST là gì?

REST là viết tắt của Representational State Transfer. (Thỉnh thoảng   đánh vần "ReST".) Nó dựa trên một máy chủ không khách, không trạng thái, có thể lưu trữ được   giao thức truyền thông - và trong hầu như tất cả các trường hợp, HTTP   giao thức được sử dụng.

REST là một kiểu kiến ​​trúc để thiết kế các ứng dụng mạng.   Ý tưởng là, thay vì sử dụng các cơ chế phức tạp như CORBA,   RPC hoặc SOAP để kết nối giữa các máy, HTTP đơn giản được sử dụng để tạo   cuộc gọi giữa các máy.

Theo nhiều cách, bản thân World Wide Web, dựa trên HTTP, có thể được xem   như một kiến ​​trúc dựa trên REST. Các ứng dụng RESTful sử dụng các yêu cầu HTTP   để đăng dữ liệu (tạo và / hoặc cập nhật), đọc dữ liệu (ví dụ: tạo truy vấn),   và xóa dữ liệu. Do đó, REST sử dụng HTTP cho tất cả bốn CRUD   (Tạo / Đọc / Cập nhật / Xóa) hoạt động.

REST là một thay thế nhẹ cho các cơ chế như RPC (Remote   Các cuộc gọi thủ tục) và các dịch vụ Web (SOAP, WSDL, et al.). Sau đó, chúng tôi sẽ   xem REST đơn giản hơn bao nhiêu.

Mặc dù đơn giản, REST là đầy đủ tính năng; về cơ bản   bạn không thể làm gì trong các Dịch vụ Web không thể thực hiện được với một RESTful   kiến trúc. REST không phải là "chuẩn". Sẽ không bao giờ có W3C   đề nghị cho REST, ví dụ. Và trong khi có REST   các khung lập trình, làm việc với REST rất đơn giản mà bạn có thể   thường "cuộn của riêng bạn" với các tính năng thư viện chuẩn bằng các ngôn ngữ như   Perl, Java hoặc C #.

Một trong những tài liệu tham khảo tốt nhất tôi tìm thấy khi tôi cố gắng tìm ra ý nghĩa thực sự đơn giản của phần còn lại.

http://rest.elkstein.org/


128
2018-03-22 14:53





REST đang sử dụng các phương thức HTTP khác nhau (chủ yếu là GET / PUT / DELETE) để thao tác dữ liệu.

Thay vì sử dụng URL cụ thể để xóa phương thức (giả sử, /user/123/delete), bạn sẽ gửi yêu cầu DELETE tới /user/[id] URL, để chỉnh sửa người dùng, để truy xuất thông tin về người dùng bạn gửi yêu cầu GET tới /user/[id]

Ví dụ: thay vào đó, một tập hợp các URL có thể trông giống như một số điều sau đây ..

GET /delete_user.x?id=123
GET /user/delete
GET /new_user.x
GET /user/new
GET /user?id=1
GET /user/id/1

Bạn sử dụng "động từ" HTTP và có ..

GET /user/2
DELETE /user/2
PUT /user

85
2017-07-12 16:33



Đó là "sử dụng HTTP đúng", không giống như "yên tĩnh" (mặc dù nó liên quan đến nó) - Julian Reschke
Bạn cũng có thể sử dụng / user / del / 2 và / user / remove / 2 hoặc ... GET / DELETE / PUT / POST chỉ là cách chuẩn hóa, "thích hợp" để làm những việc như vậy (và như Julian nói, đó không phải là tất cả có là REST) - dbr
Chắc chắn, nhưng đó là không có lý do để tránh chúng .. REST chỉ giúp bạn phát minh lại bánh xe mỗi lần. Đối với một API, REST là tuyệt vời (nhất quán!), Nhưng để cấu trúc một trang web ngẫu nhiên nó không thực sự quan trọng tôi muốn nói (nó có thể phức tạp hơn nó có giá trị) - dbr
Vadim, đó sẽ đơn giản là RPC. Cũng rất nguy hiểm khi sử dụng GET để sửa đổi dữ liệu vì (trong số các lý do khác) một công cụ tìm kiếm có thể làm gián đoạn các liên kết xóa của bạn và truy cập tất cả chúng. - aehlke
@aehlke - Tôi nghĩ câu hỏi thực sự sẽ là "Tại sao một người dùng ẩn danh có khả năng xóa các bản ghi khỏi hệ thống của bạn?" - Spencer Ruport


Đó là lập trình mà kiến ​​trúc của hệ thống của bạn phù hợp với Kiểu REST đặt ra bởi Roy Fielding trong luận án của mình. Vì đây là phong cách kiến ​​trúc mô tả web (nhiều hay ít), nhiều người quan tâm đến nó.

Trừ phi bạn đang học về kiến ​​trúc phần mềm như một dịch vụ web học thuật hay thiết kế, thực sự không có lý do gì để nghe thuật ngữ đó.


64
2018-03-23 17:11



nhưng không thẳng về phía trước .. làm cho nó phức tạp hơn mà nó cần phải được. - hasen
Ngoài ra, mặc dù các thuật ngữ REST và RESTful được sử dụng gần như độc quyền trong lĩnh vực ứng dụng web ngay bây giờ, về mặt kỹ thuật không có gì liên kết REST với HTTP. - Hank Gay
Blog của Fielding có một số bài viết tốt, dễ hiểu hơn về REST và quan niệm sai lầm phổ biến: roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven - aehlke
@ HankGay Tôi nghĩ rằng lý do nó không bí truyền hơn là hầu hết các nhà phát triển dịch vụ web xem REST như một sự đơn giản hóa tuyệt vời so với các lựa chọn thay thế như SOAP. Họ không nhất thiết phải tuân thủ tất cả các kỹ thuật REST chính xác - và điều đó có thể khiến các fan cuồng nhiệt của REST trở nên điên rồ - nhưng trong hầu hết các trường hợp, họ có thể không cần phải lo lắng về những thứ như đảm bảo kết quả của họ là "hypermedia-enabled". - moodboom


Tôi sẽ nói lập trình RESTful sẽ là về việc tạo ra các hệ thống (API) theo kiểu kiến ​​trúc REST.

Tôi đã tìm thấy hướng dẫn tuyệt vời, ngắn gọn và dễ hiểu này về REST của Tiến sĩ M. Elkstein và trích dẫn phần quan trọng sẽ trả lời câu hỏi của bạn cho hầu hết các phần:

Tìm hiểu REST: Hướng dẫn

REST là một phong cách kiến ​​trúc để thiết kế các ứng dụng mạng.   Ý tưởng là, thay vì sử dụng các cơ chế phức tạp như CORBA,   RPC hoặc SOAP để kết nối giữa các máy, HTTP đơn giản được sử dụng để tạo   cuộc gọi giữa các máy.

  • Theo nhiều cách, bản thân World Wide Web, dựa trên HTTP, có thể được xem như là một kiến ​​trúc dựa trên REST.

Các ứng dụng RESTful sử dụng các yêu cầu HTTP để đăng dữ liệu (tạo và / hoặc   cập nhật), đọc dữ liệu (ví dụ: thực hiện truy vấn) và xóa dữ liệu. Do đó, REST   sử dụng HTTP cho tất cả bốn hoạt động CRUD (Tạo / Đọc / Cập nhật / Xóa).

Tôi không nghĩ rằng bạn nên cảm thấy ngu ngốc vì không nghe về REST bên ngoài Stack Overflow ..., tôi sẽ ở trong tình huống tương tự !; câu trả lời cho câu hỏi SO khác này Tại sao REST lại lớn lên bây giờ có thể giảm bớt cảm xúc.


43
2017-07-25 09:05