การเขียนโปรแกรม RESTful คืออะไร?

การเขียนโปรแกรม RESTful คืออะไร?

รูปแบบสถาปัตยกรรมที่เรียกว่าREST (Representational รัฐ Transfer)สนับสนุนการใช้งานเว็บที่ควรใช้ HTTP ขณะที่มันกำลังสร้างสรรค์จินตนาการ การค้นหาควรใช้GETคำขอ PUT, POSTและDELETEการร้องขอควรจะใช้สำหรับการกลายพันธุ์, การสร้างและลบตามลำดับ

ผู้เสนอ REST มักจะชอบ URL เช่น

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

แต่สถาปัตยกรรม REST ไม่ต้องการ "URL ที่น่าสนใจ" เหล่านี้ คำขอ GET พร้อมพารามิเตอร์

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

เป็นบิตทุกอย่างสงบ

โปรดทราบว่าไม่ควรใช้คำขอ GET เพื่ออัปเดตข้อมูล ตัวอย่างเช่นคำขอ GET สำหรับการเพิ่มรายการลงในรถเข็น

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

จะไม่เหมาะสม รับคำขอควรจะidempotent นั่นคือการออกคำขอสองครั้งไม่ควรแตกต่างจากการออกคำขอเพียงครั้งเดียว นั่นคือสิ่งที่ทำให้การร้องขอแคช คำขอ "สั่งซื้อในตะกร้า" ไม่ใช่ idempotent โดยการออกสองครั้งจะเพิ่มรายการสองชุดลงในรถเข็น คำขอ POST มีความเหมาะสมอย่างชัดเจนในบริบทนี้ ดังนั้นแม้แต่แอปพลิเคชันเว็บที่สงบจึงต้องใช้คำขอ POST ร่วมกัน

สิ่งนี้นำมาจากหนังสือCore JavaServer ที่ยอดเยี่ยมโดย David M. Geary

RESTเป็นหลักการสถาปัตยกรรมพื้นฐานของเว็บ สิ่งที่น่าทึ่งเกี่ยวกับเว็บคือความจริงที่ว่าลูกค้า (เบราว์เซอร์) และเซิร์ฟเวอร์สามารถโต้ตอบในรูปแบบที่ซับซ้อนโดยที่ลูกค้าไม่รู้อะไรเลยเกี่ยวกับเซิร์ฟเวอร์และทรัพยากรที่โฮสต์อยู่ ข้อ จำกัด ที่สำคัญคือการที่เซิร์ฟเวอร์และไคลเอ็นต์ทั้งสองจะต้องเห็นด้วยกับสื่อที่ใช้ซึ่งในกรณีของเว็บเป็นHTML

API ที่ยึดตามหลักการของRESTไม่ต้องการให้ไคลเอ็นต์รู้อะไรเกี่ยวกับโครงสร้างของ API แต่เซิร์ฟเวอร์ต้องการให้ข้อมูลอะไรก็ตามที่ลูกค้าต้องการในการโต้ตอบกับบริการ รูปแบบ HTMLเป็นเช่นนี้: เซิร์ฟเวอร์ระบุตำแหน่งของทรัพยากรและสาขาที่กำหนด เบราว์เซอร์ไม่ทราบล่วงหน้าว่าจะส่งข้อมูลไปที่ใดและไม่รู้ล่วงหน้าว่าจะส่งข้อมูลใด ข้อมูลทั้งสองรูปแบบนั้นมาจากเซิร์ฟเวอร์ทั้งหมด (หลักการนี้เรียกว่าHATEOAS : Hypermedia เป็นเครื่องมือของสถานะแอปพลิเคชัน )

ดังนั้นสิ่งนี้นำไปใช้กับHTTP ได้อย่างไรและจะนำไปใช้ในทางปฏิบัติอย่างไร HTTP เน้นคำกริยาและทรัพยากร คำกริยาสองคำในการใช้งานหลักคือGETและPOSTซึ่งฉันคิดว่าทุกคนจะรับรู้ อย่างไรก็ตามมาตรฐาน HTTP กำหนดอื่น ๆ อีกหลายอย่างเช่นและPUT DELETEคำกริยาเหล่านี้จะถูกนำไปใช้กับทรัพยากรตามคำแนะนำของเซิร์ฟเวอร์

ตัวอย่างเช่นสมมติว่าเรามีฐานข้อมูลผู้ใช้ที่จัดการโดยบริการบนเว็บ บริการของเราใช้สื่อสิ่งพิมพ์ที่กำหนดเองตาม JSON ซึ่งเรากำหนดประเภทสื่อapplication/json+userdb(อาจมีapplication/xml+userdbและapplication/whatever+userdb- สื่อหลายประเภทอาจได้รับการสนับสนุน) ทั้งไคลเอนต์และเซิร์ฟเวอร์ได้รับการตั้งโปรแกรมให้เข้าใจรูปแบบนี้ แต่พวกเขาไม่รู้อะไรเกี่ยวกับกันและกัน ตามที่Roy Fieldingชี้ให้เห็น:

REST API ควรใช้ความพยายามเกือบทั้งหมดในการกำหนดประเภทสื่อที่ใช้สำหรับการแสดงทรัพยากรและการขับเคลื่อนสถานะของแอปพลิเคชันหรือในการกำหนดชื่อความสัมพันธ์เพิ่มเติมและ / หรือไฮเปอร์เท็กซ์ที่เปิดใช้งานการมาร์คสำหรับประเภทสื่อมาตรฐานที่มีอยู่

คำขอทรัพยากรฐาน/อาจส่งคืนสิ่งนี้:

ขอร้อง

GET /
Accept: application/json+userdb

คำตอบ

200 OK
Content-Type: application/json+userdb

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

เรารู้จากคำอธิบายของสื่อของเราว่าเราสามารถค้นหาข้อมูลเกี่ยวกับแหล่งข้อมูลที่เกี่ยวข้องจากส่วนที่เรียกว่า "ลิงก์" นี้เรียกว่าการควบคุม Hypermedia ในกรณีนี้เราสามารถบอกได้จากส่วนที่เราสามารถค้นหารายชื่อผู้ใช้โดยทำการร้องขออื่นสำหรับ/user:

ขอร้อง

GET /user
Accept: application/json+userdb

คำตอบ

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"
        }
    ]
}

เราสามารถบอกได้มากมายจากคำตอบนี้ ตัวอย่างเช่นตอนนี้เรารู้แล้วว่าเราสามารถสร้างผู้ใช้ใหม่ได้โดยPOSTไปที่/user:

ขอร้อง

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

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

คำตอบ

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"
    }
}

เรารู้ด้วยว่าเราสามารถเปลี่ยนข้อมูลที่มีอยู่:

ขอร้อง

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

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

คำตอบ

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"
    }
}

ขอให้สังเกตว่าเราจะใช้คำกริยา HTTP ที่แตกต่างกัน ( GET, PUT, POST, DELETEฯลฯ ) ในการจัดการทรัพยากรเหล่านี้และที่มีความรู้เพียง แต่เราเข้าใจในส่วนของลูกค้าคือความหมายสื่อของเรา

อ่านเพิ่มเติม:

• คำตอบที่ดีกว่านี้มากมายในหน้านี้
• ฉันอธิบายภรรยาของฉันได้อย่างไร
• ฉันอธิบายภรรยาของฉันได้อย่างไร
• ความคิดของ Martin Fowler
• API ของ PayPal มีการควบคุมสื่อหลายมิติ

(คำตอบนี้เป็นหัวข้อของการวิพากษ์วิจารณ์อย่างเป็นธรรมสำหรับประเด็นที่ขาดหายไปส่วนใหญ่เป็นคำวิจารณ์ที่ยุติธรรมสิ่งที่ฉันอธิบายไว้ในตอนแรกนั้นสอดคล้องกับวิธีที่ REST มักใช้งานเมื่อไม่กี่ปีที่ผ่านมา ก่อนอื่นเขียนสิ่งนี้มากกว่าความหมายที่แท้จริงฉันได้แก้ไขคำตอบเพื่อแสดงความหมายที่แท้จริงให้ดีขึ้น)

การเขียนโปรแกรม RESTful เป็นเรื่องเกี่ยวกับ:

• ทรัพยากรที่มีการระบุโดยตัวระบุถาวร: URIs เป็นตัวเลือกที่แพร่หลายของตัวระบุในทุกวันนี้
• ทรัพยากรถูกครอบงำโดยใช้ชุดทั่วไปของคำกริยา: http วิธีการเป็นกรณีที่เห็นบ่อย - เคารพCreate, Retrieve, Update, Deleteกลายเป็นPOST, GET, และPUT DELETEแต่ส่วนที่เหลือไม่ได้ จำกัด อยู่ที่ HTTP มันเป็นเพียงการขนส่งที่ใช้กันมากที่สุดในขณะนี้
• การเป็นตัวแทนจริงที่ดึงมาสำหรับทรัพยากรนั้นขึ้นอยู่กับคำขอและไม่ใช่ตัวระบุ: ใช้ส่วนหัวยอมรับเพื่อควบคุมว่าคุณต้องการ XML, HTTP หรือแม้กระทั่งวัตถุ Java แทนทรัพยากร
• การบำรุงรักษาสถานะในวัตถุและเป็นตัวแทนของรัฐในการเป็นตัวแทน
• แสดงถึงความสัมพันธ์ระหว่างทรัพยากรในการเป็นตัวแทนของทรัพยากร: การเชื่อมโยงระหว่างวัตถุจะถูกฝังโดยตรงในการเป็นตัวแทน
• การเป็นตัวแทนทรัพยากรอธิบายถึงวิธีการใช้งานการเป็นตัวแทนและภายใต้สถานการณ์ที่มันควรจะทิ้ง / ดึงข้อมูลในลักษณะที่สอดคล้องกัน: การใช้งานส่วนหัว HTTP แคชควบคุม

สุดท้ายน่าจะเป็นสิ่งสำคัญที่สุดในแง่ของผลที่ตามมาและประสิทธิภาพโดยรวมของ REST โดยรวมแล้วการสนทนา RESTful ส่วนใหญ่ดูเหมือนจะอยู่กึ่งกลาง HTTP และการใช้งานจากเบราว์เซอร์และสิ่งที่ไม่ ฉันเข้าใจว่า R. Fielding เป็นผู้กำหนดคำศัพท์เมื่อเขาอธิบายสถาปัตยกรรมและการตัดสินใจที่นำไปสู่ ​​HTTP วิทยานิพนธ์ของเขาเกี่ยวกับสถาปัตยกรรมและความสามารถในการแคชของทรัพยากรมากกว่าเกี่ยวกับ HTTP

หากคุณสนใจจริงๆว่าสถาปัตยกรรม RESTful คืออะไรและทำไมจึงใช้งานได้ให้อ่านวิทยานิพนธ์ของเขาสองสามครั้งและอ่านทั้งหมดไม่ใช่แค่บทที่ 5! มองหาสาเหตุที่ DNS ทำงานต่อไป อ่านเกี่ยวกับการจัดลำดับชั้นองค์กรของ DNS และการทำงานของการอ้างอิง จากนั้นอ่านและพิจารณาว่าการแคช DNS ทำงานอย่างไร สุดท้ายอ่านข้อกำหนดของ HTTP ( RFC2616และโดยเฉพาะอย่างยิ่ง RFC3040 ) และพิจารณาว่าทำไมแคชจึงใช้งานได้ตามปกติ ในที่สุดมันก็จะคลิก การเปิดเผยขั้นสุดท้ายสำหรับฉันคือเมื่อฉันเห็นความคล้ายคลึงกันระหว่าง DNS และ HTTP หลังจากนี้ทำความเข้าใจว่าเหตุใด SOA และ Message Passing Interfaces จึงเริ่มปรับขนาดได้เพื่อเริ่มคลิก

ฉันคิดว่าเคล็ดลับที่สำคัญที่สุดในการทำความเข้าใจความสำคัญทางสถาปัตยกรรมและผลกระทบด้านประสิทธิภาพของสถาปัตยกรรมRESTful and Shared ไม่มีสิ่งใดที่จะหลีกเลี่ยงการวางสายบนเทคโนโลยีและรายละเอียดการใช้งาน มุ่งเน้นไปที่ผู้ที่เป็นเจ้าของทรัพยากรที่มีหน้าที่รับผิดชอบในการสร้าง / บำรุงรักษาพวกเขา ฯลฯ จากนั้นคิดเกี่ยวกับการเป็นตัวแทนโปรโตคอลและเทคโนโลยี

นี่คือสิ่งที่มันดูเหมือน

สร้างผู้ใช้ที่มีสามคุณสมบัติ:

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

เซิร์ฟเวอร์ตอบสนอง:

200 OK
Location: /user/123

ในอนาคตคุณสามารถดึงข้อมูลผู้ใช้ได้:

GET /user/123

เซิร์ฟเวอร์ตอบสนอง:

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

หากต้องการแก้ไขบันทึก ( lnameและageจะไม่เปลี่ยนแปลง):

PATCH /user/123
fname=Johnny

หากต้องการอัปเดตระเบียน (และจะตามมาlnameและageจะเป็น NULL):

PUT /user/123
fname=Johnny

เป็นหนังสือที่ดีในส่วนที่เหลือเป็นส่วนที่เหลือในการปฏิบัติ

ต้องอ่านคือRepresentational State Transfer (REST)และREST API ต้องเป็นไฮเปอร์เท็กซ์ขับเคลื่อน

ดูบทความ Martin Fowlers โมเดล Richardson Maturity (RMM) สำหรับคำอธิบายเกี่ยวกับบริการ RESTful

เพื่อให้บริการสงบจำเป็นต้องเติมHypermedia ให้เป็นเอ็นจิ้นการใช้งานของรัฐ (HATEOAS)นั่นคือจะต้องไปถึงระดับ 3 ใน RMM ที่อ่านบทความสำหรับรายละเอียดหรือภาพนิ่งจากการพูดคุย qcon

ข้อ จำกัด HATEOAS เป็นตัวย่อสำหรับ Hypermedia เป็น Engine ของ Application State หลักการนี้เป็นความแตกต่างที่สำคัญระหว่าง REST และรูปแบบอื่น ๆ ของระบบเซิร์ฟเวอร์ลูกค้า

...

ไคลเอนต์ของแอปพลิเคชัน RESTful ต้องการทราบ URL คงที่เดียวเท่านั้นในการเข้าถึง การดำเนินการในอนาคตทั้งหมดสามารถค้นพบได้แบบไดนามิกจากลิงก์ไฮเปอร์มีเดียที่รวมอยู่ในการรับรองทรัพยากรที่ส่งคืนจาก URL นั้น สื่อชนิดมาตรฐานนั้นคาดว่าจะสามารถเข้าใจได้โดยไคลเอนต์ใด ๆ ที่อาจใช้ RESTful API (จากวิกิพีเดียสารานุกรมเสรี)

การทดสอบสารสีน้ำเงินส่วนที่เหลือสำหรับ Web Frameworksเป็นการทดสอบวุฒิภาวะที่คล้ายกันสำหรับกรอบงานเว็บ

การเข้าใกล้ REST บริสุทธิ์: เรียนรู้ที่จะรัก HATEOASเป็นคอลเล็กชั่นลิงค์ที่ดี

REST กับ SOAP สำหรับ Public Cloudกล่าวถึงระดับปัจจุบันของการใช้ REST

REST และการกำหนดเวอร์ชันอธิบายถึงความสามารถในการขยาย, การกำหนดเวอร์ชัน, การเปลี่ยนแปลงได้และอื่น ๆ ผ่านการปรับเปลี่ยนได้

REST คืออะไร

REST ย่อมาจาก Representational State Transfer (บางครั้งสะกดว่า "ReST") ขึ้นอยู่กับสถานะการสื่อสารไร้สายไคลเอนต์เซิร์ฟเวอร์โปรโตคอลการสื่อสารที่แคชได้และในเกือบทุกกรณีโปรโตคอล HTTP จะถูกใช้

REST เป็นรูปแบบสถาปัตยกรรมสำหรับการออกแบบแอปพลิเคชันเครือข่าย แนวคิดคือแทนที่จะใช้กลไกที่ซับซ้อนเช่น CORBA, RPC หรือ SOAP เพื่อเชื่อมต่อระหว่างเครื่องใช้ HTTP ธรรมดาเพื่อโทรระหว่างเครื่อง

ในหลาย ๆ ทางเวิลด์ไวด์เว็บนั้นสามารถดูได้จาก HTTP ซึ่งเป็นสถาปัตยกรรมที่ใช้ REST แอปพลิเคชัน RESTful ใช้คำขอ HTTP เพื่อโพสต์ข้อมูล (สร้างและ / หรืออัปเดต) อ่านข้อมูล (เช่นสร้างข้อความค้นหา) และลบข้อมูล ดังนั้น REST ใช้ HTTP สำหรับการดำเนินการ CRUD (สร้าง / อ่าน / อัพเดต / ลบ) ทั้งสี่รายการ

REST เป็นทางเลือกที่มีน้ำหนักเบาสำหรับกลไกเช่น RPC (Remote Procedure Calls) และ Web Services (SOAP, WSDL, et al.) ต่อมาเราจะเห็นว่า REST นั้นง่ายกว่านี้มากแค่ไหน

แม้จะใช้งานง่าย REST ก็มีคุณสมบัติครบถ้วน โดยทั่วไปไม่มีอะไรที่คุณสามารถทำได้ใน Web Services ที่ไม่สามารถทำได้ด้วยสถาปัตยกรรม RESTful REST ไม่ใช่ "มาตรฐาน" จะไม่มีการแนะนำ W3C สำหรับ REST ตัวอย่างเช่น และในขณะที่มีเฟรมเวิร์กการเขียนโปรแกรม REST การทำงานกับ REST นั้นง่ายมากที่คุณสามารถ "ม้วนของคุณเอง" ด้วยคุณสมบัติไลบรารีมาตรฐานในภาษาเช่น Perl, Java หรือ C #

หนึ่งในการอ้างอิงที่ดีที่สุดที่ฉันพบเมื่อพยายามค้นหาความหมายที่แท้จริงที่เรียบง่ายของการพักผ่อน

http://rest.elkstein.org/

REST ใช้เมธอด HTTP ต่างๆ (ส่วนใหญ่เป็น GET / PUT / DELETE) เพื่อจัดการข้อมูล

แทนที่จะใช้ URL ที่เฉพาะเจาะจงเพื่อลบวิธีการ (พูด, /user/123/delete) คุณจะส่งคำขอ DELETE ไปยัง/user/[id]URL เพื่อแก้ไขผู้ใช้เพื่อดึงข้อมูลเกี่ยวกับผู้ใช้ที่คุณส่งคำขอ GET ไป/user/[id]

ตัวอย่างเช่นแทนที่จะเป็นชุด URL ซึ่งอาจมีลักษณะดังนี้

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

คุณใช้ HTTP "กริยา" และมี ..

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

มันเป็นโปรแกรมที่สถาปัตยกรรมของระบบของคุณเหมาะกับสไตล์ RESTออกมาวางโดยรอยฟีลดิงในวิทยานิพนธ์ของเขา เนื่องจากนี่คือรูปแบบสถาปัตยกรรมที่อธิบายถึงเว็บ (มากหรือน้อย) ผู้คนจำนวนมากจึงสนใจ

คำตอบโบนัส: ไม่ยกเว้นว่าคุณกำลังศึกษาสถาปัตยกรรมซอฟต์แวร์ในฐานะนักวิชาการหรือออกแบบเว็บเซอร์วิสก็ไม่มีเหตุผลที่จะได้ยินคำนี้

ฉันจะบอกว่าการเขียนโปรแกรม RESTful จะเกี่ยวกับการสร้างระบบ (API) ที่เป็นไปตามรูปแบบสถาปัตยกรรม REST

ฉันพบบทเรียนการสอนสั้น ๆ และเข้าใจง่ายเกี่ยวกับ REST โดย Dr. M. Elkstein และกล่าวถึงส่วนสำคัญที่จะตอบคำถามของคุณเป็นส่วนใหญ่:

Learn REST: บทช่วยสอน

REST เป็นรูปแบบสถาปัตยกรรมสำหรับการออกแบบแอปพลิเคชันเครือข่าย แนวคิดคือแทนที่จะใช้กลไกที่ซับซ้อนเช่น CORBA, RPC หรือ SOAP เพื่อเชื่อมต่อระหว่างเครื่องใช้ HTTP ธรรมดาเพื่อโทรระหว่างเครื่อง

• ในหลาย ๆ ทางเวิลด์ไวด์เว็บนั้นสามารถดูได้จาก HTTP ซึ่งเป็นสถาปัตยกรรมที่ใช้ REST

แอปพลิเคชัน RESTful ใช้คำขอ HTTP เพื่อโพสต์ข้อมูล (สร้างและ / หรืออัปเดต) อ่านข้อมูล (เช่นสร้างข้อความค้นหา) และลบข้อมูล ดังนั้น REST ใช้ HTTP สำหรับการดำเนินการ CRUD (สร้าง / อ่าน / อัพเดต / ลบ) ทั้งสี่รายการ

ฉันไม่คิดว่าคุณควรจะรู้สึกโง่ที่ไม่ได้ยินเรื่อง REST นอก Stack Overflow ... ฉันจะอยู่ในสถานการณ์เดียวกัน!; คำตอบของคำถาม SO อื่น ๆ เกี่ยวกับเหตุใดส่วนที่เหลือของ REST จึงใหญ่ขึ้นในขณะนี้สามารถบรรเทาความรู้สึกบางอย่างได้

ฉันขอโทษถ้าฉันไม่ตอบคำถามโดยตรง แต่มันง่ายกว่าที่จะเข้าใจทั้งหมดนี้ด้วยตัวอย่างที่ละเอียดยิ่งขึ้น ฟีลดิงไม่ใช่เรื่องง่ายที่จะเข้าใจเนื่องจากสิ่งที่เป็นนามธรรมและคำศัพท์

มีตัวอย่างที่ดีพอสมควรที่นี่:

อธิบาย REST และ Hypertext: Spam-E หุ่นยนต์ทำความสะอาดสแปม

และยิ่งกว่านั้นมีคำอธิบายที่ชัดเจนพร้อมตัวอย่างง่าย ๆ ที่นี่ (PowerPoint มีความครอบคลุมมากขึ้น แต่คุณสามารถได้รับประโยชน์มากที่สุดในรุ่น html):

http://www.xfront.com/REST.pptหรือhttp://www.xfront.com/REST.html

หลังจากอ่านตัวอย่างฉันเห็นได้ว่าทำไมเคนถึงพูดว่า REST นั้นเป็นตัวขับเคลื่อนไฮเปอร์เท็กซ์ ฉันไม่แน่ใจจริงๆว่าเขาพูดถูกเพราะ / ผู้ใช้ / 123 เป็น URI ที่ชี้ไปที่ทรัพยากรและไม่ชัดเจนสำหรับฉันว่ามันไม่น่าพอใจเพียงเพราะลูกค้ารู้เกี่ยวกับเรื่องนี้ "นอกวง"

เอกสาร xfront นั้นอธิบายความแตกต่างระหว่าง REST และ SOAP และสิ่งนี้ก็มีประโยชน์เช่นกัน เมื่อฟีลดิงพูดว่า " นั่นคือ RPC มันกรีดร้อง RPC " เป็นที่ชัดเจนว่า RPC นั้นไม่สงบดังนั้นจึงมีประโยชน์ที่จะเห็นเหตุผลที่แน่นอนสำหรับสิ่งนี้ (SOAP เป็นประเภทของ RPC)

REST คืออะไร

ส่วนที่เหลือในคำพูดอย่างเป็นทางการ, ส่วนที่เหลือเป็นรูปแบบสถาปัตยกรรมที่สร้างขึ้นบนหลักการบางอย่างโดยใช้พื้นฐาน "เว็บ" ในปัจจุบัน มีพื้นฐาน 5 ขั้นพื้นฐานของเว็บซึ่งใช้เพื่อสร้างบริการ REST

• หลักการที่ 1: ทุกอย่างเป็นทรัพยากรในรูปแบบสถาปัตยกรรม REST ข้อมูลและการทำงานถือเป็นทรัพยากรและเข้าถึงได้โดยใช้ Uniform Resource Identifiers (URIs) ซึ่งโดยทั่วไปจะเชื่อมโยงกับเว็บ
• หลักการที่ 2: ทรัพยากรทุกอย่างได้รับการระบุโดย Unique Identifier (URI)
• หลักการที่ 3: ใช้การเชื่อมต่อที่ง่ายและสม่ำเสมอ
• หลักการที่ 4: การสื่อสารจะกระทำโดยการเป็นตัวแทน
• หลักการที่ 5: ไร้สัญชาติ

ฉันเห็นคำตอบมากมายที่บอกว่าการใส่ทุกอย่างเกี่ยวกับผู้ใช้ 123 ที่ทรัพยากร "/ user / 123" นั้นสงบ

รอยฟีลดิงใครเป็นคนบัญญัติคำกล่าวว่าAPI ของ REST จะต้องเป็นไฮเปอร์ขับเคลื่อน โดยเฉพาะ "REST API ต้องไม่กำหนดชื่อหรือลำดับชั้นของทรัพยากรคงที่"

ดังนั้นหากเส้นทาง "/ user / 123" ของคุณถูกฮาร์ดโค้ดบนไคลเอนต์ก็จะไม่สงบ การใช้ HTTP ที่ดีอาจจะไม่ใช่ แต่ไม่สงบ มันต้องมาจากไฮเปอร์เท็กซ์

คำตอบนั้นง่ายมากมีวิทยานิพนธ์ที่เขียนโดย Roy Fielding] 1ในวิทยานิพนธ์ที่เขากำหนดหลักการ REST หากแอปพลิเคชันปฏิบัติตามหลักการเหล่านี้ทั้งหมดแสดงว่าเป็นแอปพลิเคชัน REST

คำว่า RESTful ถูกสร้างขึ้นเนื่องจาก ppl ใช้คำว่า REST จนหมดโดยเรียกแอปพลิเคชันที่ไม่ใช่ REST เป็น REST หลังจากนั้นคำว่า RESTful ก็ถูกใช้จนหมดเช่นกัน ทุกวันนี้เรากำลังพูดถึง Web APIs และ Hypermedia APIเพราะแอพพลิเคชั่น REST ที่เรียกว่าส่วนใหญ่นั้นไม่ได้ตอบสนองส่วน HATEOAS ของข้อ จำกัด ด้านอินเตอร์เฟสที่เหมือนกัน

ข้อ จำกัด REST มีดังต่อไปนี้:

1. สถาปัตยกรรมไคลเอนต์เซิร์ฟเวอร์

   ดังนั้นจึงไม่สามารถใช้งานได้กับซ็อกเก็ต PUB / SUB ตัวอย่างเช่นใช้ REQ / REP

2. การสื่อสารไร้สัญชาติ

   ดังนั้นเซิร์ฟเวอร์จะไม่รักษาสถานะของลูกค้า ซึ่งหมายความว่าคุณไม่สามารถใช้เซิร์ฟเวอร์ที่เก็บข้อมูลเซสชันด้านข้างและคุณต้องตรวจสอบสิทธิ์ทุกคำขอ ลูกค้าของคุณอาจส่งส่วนหัวรับรองความถูกต้องขั้นพื้นฐานผ่านการเชื่อมต่อที่เข้ารหัส (โดยแอปพลิเคชันขนาดใหญ่เป็นการยากที่จะรักษาหลายครั้ง)

3. การใช้แคชหากคุณสามารถ

   ดังนั้นคุณไม่ต้องทำตามคำขอเดิมซ้ำแล้วซ้ำอีก

4. อินเตอร์เฟซที่เหมือนกันเป็นสัญญาทั่วไประหว่างลูกค้าและเซิร์ฟเวอร์

   สัญญาระหว่างลูกค้าและเซิร์ฟเวอร์ไม่ได้รับการดูแลโดยเซิร์ฟเวอร์ กล่าวอีกนัยหนึ่งลูกค้าจะต้องแยกออกจากการใช้บริการ คุณสามารถเข้าถึงสถานะนี้ได้โดยใช้โซลูชันมาตรฐานเช่นมาตรฐาน IRI (URI) เพื่อระบุทรัพยากรมาตรฐาน HTTP ในการแลกเปลี่ยนข้อความประเภท MIME มาตรฐานเพื่ออธิบายรูปแบบการทำให้เป็นอนุกรมของร่างกายเมทาดาทา (อาจเป็น RDF vocabs ไมโครฟอร์แมต ฯลฯ ) เพื่อ อธิบายความหมายของส่วนต่างๆของเนื้อหาข้อความ ในการแยกโครงสร้าง IRI ออกจากไคลเอนต์คุณต้องส่งไฮเปอร์ลิงก์ไปยังไคลเอนต์ในรูปแบบไฮเปอร์มีเดียเช่น (HTML, JSON-LD, HAL และอื่น ๆ ) ดังนั้นลูกค้าสามารถใช้ข้อมูลเมตา (อาจเป็นความสัมพันธ์ของลิงก์, คำศัพท์ RDF) ที่กำหนดให้กับไฮเปอร์ลิงก์เพื่อนำทางเครื่องสถานะของแอปพลิเคชันผ่านการเปลี่ยนสถานะที่เหมาะสมเพื่อให้บรรลุเป้าหมายปัจจุบัน

   ตัวอย่างเช่นเมื่อลูกค้าต้องการส่งคำสั่งซื้อไปยังร้านค้าทางเว็บนั้นจะต้องตรวจสอบการเชื่อมโยงหลายมิติในการตอบสนองที่ส่งโดยเว็บช็อป โดยการตรวจสอบการเชื่อมโยงมัน founds หนึ่งอธิบายกับhttp://schema.org/OrderAction ลูกค้าทราบคำศัพท์ schema.org ดังนั้นจึงเข้าใจได้ว่าการเปิดใช้งานไฮเปอร์ลิงก์นี้จะเป็นการส่งคำสั่งซื้อ ดังนั้นจึงเปิดใช้งานการเชื่อมโยงหลายมิติและส่งPOST https://example.com/api/v1/orderข้อความที่มีเนื้อหาที่เหมาะสม หลังจากนั้นบริการจะประมวลผลข้อความและตอบกลับด้วยผลลัพธ์ที่มีส่วนหัวสถานะ HTTP ที่เหมาะสมตัวอย่างเช่น201 - createdจากความสำเร็จ ในการใส่คำอธิบายประกอบข้อความที่มีข้อมูลเมตาโดยละเอียดโซลูชันมาตรฐานเพื่อใช้รูปแบบ RDF ตัวอย่างเช่นJSON-LD ที่มีคำศัพท์ REST เช่นHydraและคำศัพท์เฉพาะโดเมนเช่นschema.orgหรือคำศัพท์อื่น ๆ ที่เชื่อมโยงข้อมูลและอาจเป็นคำศัพท์เฉพาะสำหรับแอปพลิเคชันที่กำหนดเองหากจำเป็น ตอนนี้ไม่ใช่เรื่องง่ายนั่นเป็นเหตุผลว่าทำไมคนส่วนใหญ่จึงใช้ HAL และรูปแบบง่าย ๆ อื่น ๆ ซึ่งมักจะให้เฉพาะคำศัพท์ REST แต่ไม่มีการสนับสนุนข้อมูลที่เชื่อมโยง

5. สร้างระบบชั้นเพื่อเพิ่มความยืดหยุ่น

   ระบบ REST ประกอบด้วยเลเยอร์แบบลำดับชั้น แต่ละชั้นมีส่วนประกอบที่ใช้บริการของส่วนประกอบที่อยู่ในชั้นถัดไปด้านล่าง ดังนั้นคุณสามารถเพิ่มเลเยอร์และส่วนประกอบใหม่ได้อย่างง่ายดาย

   ตัวอย่างเช่นมีชั้นลูกค้าที่มีลูกค้าและด้านล่างว่ามีชั้นบริการที่มีบริการเดียว ตอนนี้คุณสามารถเพิ่มแคชฝั่งไคลเอ็นต์ระหว่างพวกเขา หลังจากนั้นคุณสามารถเพิ่มอินสแตนซ์บริการอื่นและตัวโหลดบาลานเซอร์และอื่น ๆ ... รหัสลูกค้าและรหัสบริการจะไม่เปลี่ยนแปลง

6. รหัสตามความต้องการเพื่อขยายการทำงานของลูกค้า

   ข้อ จำกัด นี้เป็นทางเลือก ตัวอย่างเช่นคุณสามารถส่ง parser สำหรับประเภทสื่อเฉพาะไปยังไคลเอนต์และอื่น ๆ ... ในการทำเช่นนี้คุณอาจต้องใช้ระบบตัวโหลดปลั๊กอินมาตรฐานในไคลเอนต์มิฉะนั้นไคลเอนต์ของคุณจะเชื่อมต่อกับปลั๊กอินโหลดเดอร์ .

ข้อ จำกัด REST ส่งผลให้ระบบสามารถปรับขนาดได้อย่างมากในกรณีที่ลูกค้าถูกแยกออกจากการใช้งานบริการ ดังนั้นลูกค้าสามารถนำมาใช้ซ้ำได้เช่นเดียวกับเบราว์เซอร์บนเว็บ ลูกค้าและบริการมีมาตรฐานและคำศัพท์เดียวกันเพื่อให้พวกเขาสามารถเข้าใจซึ่งกันและกันได้แม้ว่าลูกค้าจะไม่ทราบรายละเอียดการใช้งานของบริการ ทำให้สามารถสร้างลูกค้าอัตโนมัติซึ่งสามารถค้นหาและใช้บริการ REST เพื่อให้บรรลุเป้าหมาย ในระยะยาวลูกค้าเหล่านี้สามารถสื่อสารซึ่งกันและกันและไว้วางใจซึ่งกันและกันกับงานเช่นเดียวกับที่มนุษย์ทำ หากเราเพิ่มรูปแบบการเรียนรู้ให้กับลูกค้าเช่นนั้นผลลัพธ์จะเป็น AI อย่างน้อยหนึ่งรายการโดยใช้เว็บของเครื่องแทนที่จะเป็นเซิร์ฟเวอร์เดียว ดังนั้นในตอนท้ายความฝันของเบอร์เกอร์ลี: เว็บความหมายและปัญญาประดิษฐ์จะเป็นจริง ดังนั้นในปี 2030 เราสิ้นสุดโดย Skynet จนกระทั่ง ... ;-)

การเขียนโปรแกรม API RESTful (Representational state Transfer) กำลังเขียนเว็บแอปพลิเคชันในภาษาการเขียนโปรแกรมใด ๆ โดยทำตามหลักการสไตล์สถาปัตยกรรมซอฟต์แวร์พื้นฐาน 5 ประการ:

1. ทรัพยากร (ข้อมูลข้อมูล)
2. ตัวระบุทั่วโลกที่ไม่ซ้ำกัน (ทรัพยากรทั้งหมดเป็นเอกลักษณ์ที่ระบุโดยURI )
3. Uniform interface - ใช้อินเตอร์เฟสที่ง่ายและมาตรฐาน (HTTP)
4. การเป็นตัวแทน - การสื่อสารทั้งหมดกระทำโดยการเป็นตัวแทน (เช่นXML / JSON )
5. ไร้สัญชาติ (การร้องขอทุกอย่างเกิดขึ้นในการแยกอย่างสมบูรณ์ทำให้แคชและโหลดบาลานซ์ง่ายขึ้น)

กล่าวอีกนัยหนึ่งคุณกำลังเขียนแอพพลิเคชั่นเครือข่ายแบบจุดต่อจุดอย่างง่ายผ่าน HTTP ซึ่งใช้คำกริยาเช่น GET, POST, PUT หรือ DELETE โดยใช้สถาปัตยกรรม RESTful ซึ่งเสนอมาตรฐานของอินเทอร์เฟซที่แต่ละ "ทรัพยากร" เปิดเผย ไม่มีอะไรที่ใช้คุณสมบัติปัจจุบันของเว็บในวิธีที่ง่ายและมีประสิทธิภาพ (สถาปัตยกรรมที่ประสบความสำเร็จพิสูจน์และกระจาย) มันเป็นทางเลือกให้กับกลไกที่ซับซ้อนมากขึ้นเช่นสบู่ , CORBAและRPC

การเขียนโปรแกรม RESTful นั้นสอดคล้องกับการออกแบบสถาปัตยกรรมเว็บและหากนำไปใช้อย่างเหมาะสมจะช่วยให้คุณสามารถใช้ประโยชน์จากโครงสร้างพื้นฐานเว็บที่ปรับขนาดได้อย่างสมบูรณ์

ถ้าฉันต้องลดการทำวิทยานิพนธ์ต้นฉบับให้เหลือเพียงประโยคสั้น ๆ 3 ประโยคฉันคิดว่าสิ่งต่อไปนี้รวบรวมสาระสำคัญของมัน:

1. ขอทรัพยากรผ่านทาง URL
2. โปรโตคอลถูก จำกัด ไว้ที่สิ่งที่คุณสามารถสื่อสารโดยใช้ URL
3. ข้อมูลเมตาถูกส่งเป็นคู่ค่าชื่อ (โพสต์ข้อมูลและพารามิเตอร์สตริงแบบสอบถาม)

หลังจากนั้นก็เป็นเรื่องง่ายที่จะตกอยู่ในการอภิปรายเกี่ยวกับการปรับตัวการเขียนโปรแกรมการประชุมและแนวทางปฏิบัติที่ดีที่สุด

ที่น่าสนใจคือไม่มีการกล่าวถึงการดำเนินงาน HTTP POST, GET, DELETE หรือ PUT ในการทำวิทยานิพนธ์ นั่นจะต้องเป็นการตีความ "การปฏิบัติที่ดีที่สุด" ของใครบางคนในภายหลังสำหรับ

เมื่อพูดถึงบริการบนเว็บดูเหมือนว่าเราต้องการวิธีแยกความแตกต่างของสถาปัตยกรรมแบบ WSDL และ SOAP ซึ่งเพิ่มค่าใช้จ่ายจำนวนมากและความซับซ้อนที่ไม่จำเป็นในเนื้อหา พวกเขายังต้องการกรอบเพิ่มเติมและเครื่องมือสำหรับนักพัฒนาเพื่อนำไปใช้ ฉันไม่แน่ใจว่า REST เป็นคำที่ดีที่สุดในการแยกความแตกต่างระหว่างอินเทอร์เฟซสามัญสำนึกและอินเทอร์เฟซที่ได้รับการออกแบบมากเกินไปเช่น WSDL และ SOAP แต่เราต้องการบางสิ่ง

REST เป็นรูปแบบสถาปัตยกรรมและสไตล์ของการเขียนแอพพลิเคชั่นแบบกระจาย มันไม่ใช่สไตล์การเขียนโปรแกรมในความหมายที่แคบ

การบอกว่าคุณใช้รูปแบบ REST คล้ายกับว่าคุณสร้างบ้านในรูปแบบเฉพาะ: ตัวอย่างเช่นทิวดอร์หรือวิคตอเรีย ทั้งส่วนที่เหลือเป็นรูปแบบซอฟต์แวร์และทิวดอร์หรือวิคตอเรียเป็นรูปแบบบ้านสามารถกำหนดโดยคุณสมบัติและข้อ จำกัด ที่ทำให้พวกเขา ตัวอย่างเช่น REST ต้องมีการแยกไคลเอนต์เซิร์ฟเวอร์โดยที่ข้อความอธิบายตนเอง บ้านสไตล์ทิวดอร์มีหน้าจั่วซ้อนทับและหลังคาที่แหลมสูงชันด้วยหน้าจั่ว คุณสามารถอ่านวิทยานิพนธ์ของ Roy เพื่อเรียนรู้เพิ่มเติมเกี่ยวกับข้อ จำกัด และคุณสมบัติที่เป็นส่วนที่เหลือ

ส่วนที่เหลือซึ่งแตกต่างจากสไตล์บ้านมีช่วงเวลาที่ยากลำบากที่ถูกนำมาใช้อย่างต่อเนื่องและในทางปฏิบัติ สิ่งนี้อาจมีเจตนา ออกจากการใช้งานจริงจนถึงนักออกแบบ ดังนั้นคุณมีอิสระที่จะทำสิ่งที่คุณต้องการตราบใดที่คุณมีข้อ จำกัด ตามที่ระบุไว้ในวิทยานิพนธ์ที่คุณกำลังสร้างระบบส่วนที่เหลือ

โบนัส:

ทั้งเว็บอ้างอิงจาก REST (หรือ REST อ้างอิงจากเว็บ) ดังนั้นในฐานะนักพัฒนาเว็บคุณอาจต้องการทราบว่าถึงแม้จะไม่จำเป็นต้องเขียนเว็บแอปที่ดี

นี่คือโครงร่างพื้นฐานของ REST ฉันพยายามแสดงให้เห็นถึงความคิดที่อยู่เบื้องหลังแต่ละองค์ประกอบในสถาปัตยกรรม RESTful เพื่อให้การทำความเข้าใจแนวคิดนั้นง่ายขึ้น หวังว่านี่จะช่วยให้เข้าใจอย่างชัดเจนว่า REST สำหรับบางคน!

REST (Representational State Transfer) เป็นสถาปัตยกรรมการออกแบบที่กำหนดวิธีการที่ทรัพยากรเครือข่าย (เช่นโหนดที่แบ่งปันข้อมูล) ได้รับการออกแบบและแก้ไข โดยทั่วไปแล้วสถาปัตยกรรม RESTful สร้างขึ้นเพื่อให้ไคลเอนต์ (เครื่องร้องขอ) และเซิร์ฟเวอร์ (เครื่องตอบสนอง) สามารถร้องขอการอ่านเขียนและอัปเดตข้อมูลโดยที่ไคลเอ็นต์ไม่จำเป็นต้องทราบว่าเซิร์ฟเวอร์ทำงานอย่างไรและเซิร์ฟเวอร์สามารถส่งผ่านได้ มันกลับมาโดยไม่จำเป็นต้องรู้อะไรเกี่ยวกับลูกค้า โอเคเยี่ยม ... แต่เราจะทำเช่นนี้ในทางปฏิบัติได้อย่างไร?

• ความต้องการที่ชัดเจนที่สุดคือต้องมีภาษาสากลของการเรียงลำดับบางอย่างเพื่อให้เซิร์ฟเวอร์สามารถบอกไคลเอ็นต์ว่ากำลังพยายามทำอะไรกับคำขอและเพื่อให้เซิร์ฟเวอร์ตอบสนอง

• แต่เพื่อค้นหาทรัพยากรที่ได้รับและจากนั้นบอกลูกค้าว่าทรัพยากรนั้นอยู่ที่ใดจำเป็นต้องมีวิธีการชี้ทรัพยากรที่เป็นสากล นี่คือสิ่งที่ Universal Resource Identifier (URIs) เข้ามา โดยทั่วไปจะเป็นที่อยู่เฉพาะเพื่อค้นหาทรัพยากร

แต่สถาปัตยกรรม REST นั้นไม่ได้จบเพียงแค่นั้น! ในขณะที่ข้างต้นตอบสนองความต้องการขั้นพื้นฐานของสิ่งที่เราต้องการเรายังต้องการสถาปัตยกรรมที่รองรับปริมาณการรับส่งข้อมูลสูงเนื่องจากเซิร์ฟเวอร์ที่ให้มักจะจัดการการตอบสนองจากลูกค้าจำนวนมาก ดังนั้นเราไม่ต้องการให้เซิร์ฟเวอร์ครอบงำโดยให้จำข้อมูลเกี่ยวกับคำขอก่อนหน้า

• ดังนั้นเราจึงกำหนดข้อ จำกัด ว่าแต่ละคู่ตอบสนองคำขอระหว่างลูกค้าและเซิร์ฟเวอร์มีความเป็นอิสระซึ่งหมายความว่าเซิร์ฟเวอร์ไม่จำเป็นต้องจดจำสิ่งใดเกี่ยวกับคำขอก่อนหน้า (สถานะก่อนหน้าของการโต้ตอบระหว่างไคลเอ็นต์กับเซิร์ฟเวอร์) เพื่อตอบสนองต่อสิ่งใหม่ ขอร้อง ซึ่งหมายความว่าเราต้องการให้การโต้ตอบของเราไร้สัญชาติ

• เพื่อลดความตึงเครียดบนเซิร์ฟเวอร์ของเราจากการคำนวณซ้ำที่ทำไปแล้วเมื่อเร็ว ๆ นี้สำหรับลูกค้าที่ได้รับ REST ยังอนุญาตให้ทำการแคช โดยพื้นฐานแล้วการแคชหมายถึงการถ่ายภาพการตอบสนองเริ่มต้นที่มีให้กับลูกค้า หากไคลเอ็นต์ทำการร้องขอเดียวกันอีกครั้งเซิร์ฟเวอร์สามารถจัดเตรียมไคลเอ็นต์ด้วยสแน็ปช็อตแทนที่จะทำการคำนวณใหม่ทั้งหมดที่จำเป็นในการสร้างการตอบกลับเริ่มต้น อย่างไรก็ตามเนื่องจากเป็นสแน็ปช็อตหากสแน็ปช็อตยังไม่หมดอายุ - เซิร์ฟเวอร์จะกำหนดเวลาหมดอายุล่วงหน้า - และการตอบสนองได้รับการอัปเดตตั้งแต่แคชเริ่มต้น (เช่นคำขอจะให้คำตอบที่แตกต่างจากแคชตอบกลับ) ไคลเอ็นต์จะไม่เห็นการอัปเดตจนกว่าแคชจะหมดอายุ (หรือล้างแคช) และการตอบสนองจะถูกแสดงตั้งแต่เริ่มต้นอีกครั้ง

• สิ่งสุดท้ายที่คุณมักจะมาที่นี่เกี่ยวกับสถาปัตยกรรมที่สงบเงียบก็คือพวกมันถูกแบ่งเป็นชั้น ๆ เราได้พูดคุยเกี่ยวกับข้อกำหนดนี้โดยปริยายแล้วในการสนทนาระหว่างลูกค้ากับเซิร์ฟเวอร์ โดยทั่วไปหมายความว่าแต่ละชั้นในระบบของเราโต้ตอบเฉพาะกับชั้นที่อยู่ติดกัน ดังนั้นในการสนทนาของเราเลเยอร์ไคลเอนต์โต้ตอบกับเลเยอร์เซิร์ฟเวอร์ของเรา (และในทางกลับกัน) แต่อาจมีเลเยอร์เซิร์ฟเวอร์อื่น ๆ ที่ช่วยให้เซิร์ฟเวอร์หลักประมวลผลคำขอที่ลูกค้าไม่ได้สื่อสารโดยตรง ค่อนข้างเซิร์ฟเวอร์ผ่านการร้องขอตามความจำเป็น

ทีนี้ถ้าทั้งหมดนี้ฟังดูคุ้น ๆ Hypertext Transfer Protocol (HTTP) ซึ่งกำหนดโปรโตคอลการสื่อสารผ่านเวิลด์ไวด์เว็บเป็นการใช้แนวคิดนามธรรมของสถาปัตยกรรม RESTful (หรืออินสแตนซ์ของคลาส REST ถ้าคุณเป็น OOP คลั่งเหมือนฉัน) ในการติดตั้ง REST นี้ไคลเอ็นต์และเซิร์ฟเวอร์จะโต้ตอบผ่าน GET, POST, PUT, DELETE และอื่น ๆ ซึ่งเป็นส่วนหนึ่งของภาษาสากลและทรัพยากรสามารถชี้ไปที่การใช้ URL

ผมคิดว่าจุดของการพักผ่อนคือการแยกของ statefulness เข้าไปในชั้นที่สูงขึ้นในขณะที่การใช้อินเทอร์เน็ต (Protocol) เป็นชั้นของการขนส่งไร้สัญชาติ วิธีการอื่น ๆ ส่วนใหญ่ผสมกัน

เป็นวิธีปฏิบัติที่ดีที่สุดในการจัดการกับการเปลี่ยนแปลงพื้นฐานของการเขียนโปรแกรมในยุคอินเทอร์เน็ต เกี่ยวกับการเปลี่ยนแปลงขั้นพื้นฐาน, เอริคเมย์เยอร์มีการอภิปรายเกี่ยวกับการแสดงที่นี่: http://www.infoq.com/interviews/erik-meijer-programming-language-design-effects-purity#view_93197 เขาสรุปว่ามันเป็นเอฟเฟกต์ห้าอย่างและนำเสนอโซลูชันโดยการออกแบบโซลูชันเป็นภาษาการเขียนโปรแกรม การแก้ปัญหาสามารถทำได้ในแพลตฟอร์มหรือระดับระบบโดยไม่คำนึงถึงภาษา การพักผ่อนอาจถูกมองว่าเป็นหนึ่งในวิธีการแก้ปัญหาที่ประสบความสำเร็จอย่างมากในการปฏิบัติในปัจจุบัน

ด้วยสไตล์ที่ผ่อนคลายคุณจะได้รับและจัดการสถานะของแอปพลิเคชั่นผ่านอินเทอร์เน็ตที่ไม่น่าเชื่อถือ หากการดำเนินการปัจจุบันล้มเหลวในการรับสถานะที่ถูกต้องและเป็นปัจจุบันจำเป็นต้องมีหลักการตรวจสอบความถูกต้องเป็นศูนย์เพื่อช่วยให้แอปพลิเคชันดำเนินการต่อ หากล้มเหลวในการจัดการกับรัฐก็มักจะใช้การยืนยันหลายขั้นตอนเพื่อให้สิ่งที่ถูกต้อง ในแง่นี้การพักผ่อนไม่ใช่โซลูชันทั้งหมดมันต้องการฟังก์ชั่นในส่วนอื่น ๆ ของเว็บแอปพลิเคชันสแต็กเพื่อรองรับการทำงานของมัน

เมื่อพิจารณาจากมุมมองนี้สไตล์การพักผ่อนนั้นไม่ได้เชื่อมโยงกับอินเทอร์เน็ตหรือเว็บแอปพลิเคชันจริงๆ มันเป็นทางออกพื้นฐานสำหรับสถานการณ์การเขียนโปรแกรมจำนวนมาก มันไม่ง่ายอย่างใดอย่างหนึ่งเพียงแค่ทำให้อินเทอร์เฟซง่าย ๆ จริง ๆ และ copes กับเทคโนโลยีอื่น ๆ ได้อย่างน่าอัศจรรย์

แค่ 2c ของฉัน

แก้ไข: อีกสองด้านที่สำคัญ:

• การไร้สัญชาติกำลังทำให้เข้าใจผิด เป็นเรื่องเกี่ยวกับ API ที่เงียบสงบไม่ใช่แอปพลิเคชันหรือระบบ ระบบจะต้องมีสถานะ การออกแบบที่เงียบสงบนั้นเกี่ยวกับการออกแบบระบบแบบรัฐโดยใช้ API ไร้สัญชาติ บางคำพูดจาก QA อื่น :

  • REST ดำเนินการแทนทรัพยากรแต่ละอันระบุโดย URL เหล่านี้มักจะไม่ได้ข้อมูลวัตถุ แต่วัตถุนามธรรมที่ซับซ้อน
  • REST ย่อมาจาก "Representational State Transfer" ซึ่งหมายถึงการสื่อสารและแก้ไขสถานะของทรัพยากรบางอย่างในระบบ

• Idempotence : ส่วนที่มักถูกมองข้ามของ REST คือ idempotency ของคำกริยาส่วนใหญ่ นำไปสู่การที่ระบบที่มีประสิทธิภาพและพึ่งพาน้อยของการตีความที่แน่นอนของความหมาย

นี่คือ "การสนทนา" ที่ยาวอย่างน่าอัศจรรย์และค่อนข้างสับสนที่จะพูดน้อยที่สุด

IMO:

1) ไม่มีสิ่งที่เป็นโปรแกรมการพักผ่อนโดยไม่มีข้อต่อใหญ่และเบียร์มากมาย :)

2) รัฐ Representational โอนเงิน (REST) เป็นรูปแบบสถาปัตยกรรมที่ระบุไว้ในวิทยานิพนธ์ของรอยฟีลดิง มันมีข้อ จำกัด มากมาย หากบริการ / ลูกค้าของคุณเคารพสิ่งเหล่านั้นก็จะสงบ นี่ไง.

คุณสามารถสรุปข้อ จำกัด ในการ:

• การสื่อสารไร้สัญชาติ
• เคารพรายละเอียด HTTP (ถ้าใช้ HTTP)
• สื่อสารรูปแบบเนื้อหาที่ส่งอย่างชัดเจน
• ใช้สื่อสิ่งพิมพ์เป็นเครื่องมือของรัฐแอปพลิเคชัน

มีอีกโพสต์ที่ดีมากซึ่งอธิบายสิ่งต่าง ๆ อย่างดี

คำตอบจำนวนมากคัดลอก / วางข้อมูลที่ถูกต้องผสมและเพิ่มความสับสน ผู้คนพูดถึงระดับต่าง ๆ เกี่ยวกับ RESTFul URIs (ไม่มีสิ่งนั้น!) ใช้วิธี HTTP GET, POST, PUT ... REST ไม่เกี่ยวกับสิ่งนั้นหรือไม่เพียงแค่นั้น

ตัวอย่างเช่นลิงก์ - เป็นเรื่องดีที่มี API ที่สวยงาม แต่ท้ายที่สุดไคลเอนต์ / เซิร์ฟเวอร์ไม่สนใจลิงค์ที่คุณได้รับ / ส่งเป็นเนื้อหาที่สำคัญ

ในที่สุดลูกค้า RESTful ใด ๆ ควรสามารถใช้บริการ RESTful ใด ๆ ตราบใดที่รูปแบบเนื้อหาเป็นที่รู้จัก

คำถามเก่า ๆ วิธีการใหม่ในการตอบ มีความเข้าใจผิดมากมายเกี่ยวกับแนวคิดนี้ ฉันพยายามจำเสมอ:

1. URL ที่มีโครงสร้างและเมธอด Http / คำกริยาไม่ใช่คำจำกัดความของการเขียนโปรแกรมที่สงบ
2. JSON ไม่ใช่โปรแกรมพักผ่อน
3. การเขียนโปรแกรม RESTful ไม่ได้มีไว้สำหรับ API

ฉันกำหนดโปรแกรมพักผ่อนเป็น

แอปพลิเคชันนั้นสงบถ้าจัดหาทรัพยากร (เป็นการรวมกันของการควบคุมข้อมูล + สถานะการเปลี่ยนผ่าน) ในประเภทสื่อที่ลูกค้าเข้าใจ

ในการเป็นโปรแกรมเมอร์ที่สงบคุณต้องพยายามสร้างแอปพลิเคชั่นที่อนุญาตให้นักแสดงทำสิ่งต่างๆ ไม่เพียง แต่เปิดเผยฐานข้อมูล

การเปลี่ยนสถานะจะควบคุมได้ก็ต่อเมื่อไคลเอนต์และเซิร์ฟเวอร์ยอมรับการแสดงประเภทสื่อของทรัพยากร มิฉะนั้นจะไม่มีทางรู้ว่าตัวควบคุมคืออะไรและอะไรที่ไม่ได้และวิธีการควบคุม IE หากเบราว์เซอร์ไม่ทราบ<form>แท็กใน html ดังนั้นจะไม่มีอะไรให้คุณส่งไปยังสถานะการเปลี่ยนแปลงในเบราว์เซอร์ของคุณ

ผมไม่ได้มองตัวเองส่งเสริม แต่ผมขยายความคิดเหล่านี้ที่ระดับความลึกที่ดีในการพูดคุยของฉันhttp://techblog.bodybuilding.com/2016/01/video-what-is-restful-200.html

ข้อความที่ตัดตอนมาจากคำปราศรัยของฉันเป็นเรื่องเกี่ยวกับรูปแบบวุฒิภาวะของริชาร์ดสันที่ฉันมักไม่เชื่อในระดับคุณเป็น RESTful (ระดับ 3) หรือคุณไม่ได้ แต่สิ่งที่ฉันชอบเรียกออกมาเกี่ยวกับมันคือแต่ละระดับ ทำเพื่อคุณในทางของคุณเพื่อสงบ

REST กำหนดข้อ จำกัด ทางสถาปัตยกรรม 6 ข้อซึ่งทำให้บริการเว็บใด ๆ เป็นRESTful API ที่แท้จริง

1. ชุดอินเตอร์เฟส
2. ไคลเอนต์เซิร์ฟเวอร์
3. ไร้สัญชาติ
4. แคชได้
5. ระบบเลเยอร์
6. รหัสตามต้องการ (ไม่บังคับ)

https://restfulapi.net/rest-architectural-constraints/

REST === การเปรียบเทียบ HTTP นั้นไม่ถูกต้องจนกว่าคุณจะไม่เครียดกับความจริงที่ว่า "ต้อง" แรงผลักดันHATEOAS

รอยตัวเองเคลียร์ที่นี่นี่

ควรป้อน REST API โดยไม่ต้องมีความรู้มาก่อนนอกเหนือจาก URI เริ่มต้น (บุ๊กมาร์ก) และชุดของประเภทสื่อมาตรฐานที่เหมาะสมสำหรับผู้ชมที่ต้องการ (เช่นคาดว่าจะเข้าใจโดยลูกค้าที่อาจใช้ API) จากจุดนั้นการเปลี่ยนสถานะแอปพลิเคชันทั้งหมดจะต้องขับเคลื่อนโดยการเลือกไคลเอ็นต์ของตัวเลือกที่เซิร์ฟเวอร์จัดเตรียมไว้ซึ่งมีอยู่ในการรับรองที่ได้รับหรือโดยนัยโดยการจัดการของผู้ใช้ในการเป็นตัวแทนเหล่านั้น ช่วงการเปลี่ยนภาพอาจถูกกำหนด (หรือ จำกัด โดย) ความรู้ของลูกค้าเกี่ยวกับประเภทสื่อและกลไกการสื่อสารทรัพยากรซึ่งทั้งสองอย่างนี้อาจได้รับการปรับปรุงให้ดีขึ้น (เช่นรหัสตามความต้องการ)

[ความล้มเหลวที่นี่หมายถึงว่าข้อมูลนอกวงกำลังผลักดันการมีปฏิสัมพันธ์แทนที่จะเป็นไฮเปอร์เท็กซ์]

RESTเป็นรูปแบบสถาปัตยกรรมซึ่งใช้มาตรฐานเว็บและโปรโตคอล HTTP (เปิดตัวในปี 2000)

ในสถาปัตยกรรมแบบ REST ทุกอย่างเป็นทรัพยากร (ผู้ใช้คำสั่งความคิดเห็น) ทรัพยากรเข้าถึงได้ผ่านทางอินเตอร์เฟสทั่วไปตามวิธีมาตรฐาน HTTP (GET, PUT, PATCH, DELETE ฯลฯ )

ในสถาปัตยกรรมแบบ REST คุณมีเซิร์ฟเวอร์ REST ซึ่งให้การเข้าถึงทรัพยากร ไคลเอ็นต์ REST สามารถเข้าถึงและแก้ไขรีซอร์ส REST

ทรัพยากรทุกคนควรสนับสนุนการดำเนินงานทั่วไปของ HTTP ทรัพยากรถูกระบุโดยรหัสส่วนกลาง (ซึ่งโดยทั่วไปคือ URIs)

REST อนุญาตให้ทรัพยากรมีการแสดงต่าง ๆ เช่นข้อความ, XML, JSON เป็นต้นไคลเอนต์ REST สามารถขอการแสดงเฉพาะผ่านโปรโตคอล HTTP (การเจรจาต่อรองเนื้อหา)

วิธี HTTP:

วิธี PUT, GET, POST และ DELETE เป็นวิธีที่ใช้กันโดยทั่วไปในสถาปัตยกรรมที่ใช้ REST ตารางต่อไปนี้ให้คำอธิบายเกี่ยวกับการดำเนินการเหล่านี้

• GET กำหนดการเข้าถึงการอ่านของทรัพยากรโดยไม่มีผลข้างเคียง ทรัพยากรจะไม่เปลี่ยนแปลงผ่านการร้องขอ GET เช่นคำขอไม่มีผลข้างเคียง (idempotent)
• PUT สร้างทรัพยากรใหม่ มันจะต้องเป็น idempotent
• ลบลบทรัพยากร การดำเนินการ idempotent พวกเขาสามารถทำซ้ำได้โดยไม่นำไปสู่ผลลัพธ์ที่แตกต่าง
• POST อัปเดตทรัพยากรที่มีอยู่หรือสร้างทรัพยากรใหม่

ส่วนที่เหลือยืนสำหรับการถ่ายโอนรัฐ Representational

มันขึ้นอยู่กับไร้สัญชาติลูกค้า - เซิร์ฟเวอร์โปรโตคอลการสื่อสารที่แคชได้ - และในเกือบทุกกรณีโปรโตคอล HTTP จะใช้

REST มักใช้ในแอปพลิเคชันมือถือเว็บไซต์เครือข่ายสังคมออนไลน์เครื่องมือตอบโต้กับผู้ใช้ได้และกระบวนการทางธุรกิจอัตโนมัติ รูปแบบ REST เน้นว่าการโต้ตอบระหว่างลูกค้าและบริการนั้นได้รับการปรับปรุงโดยมีจำนวนการดำเนินการที่ จำกัด (คำกริยา) ความยืดหยุ่นมีให้โดยการกำหนดทรัพยากร (คำนาม) ตัวบ่งชี้ทรัพยากรสากลที่เป็นเอกลักษณ์ของตัวเอง (URIs)

คำแนะนำเกี่ยวกับส่วนที่เหลือ

การพูดคุยเป็นมากกว่าเพียงแค่การแลกเปลี่ยนข้อมูล โปรโตคอลได้รับการออกแบบจริง ๆ เพื่อไม่ให้เกิดการพูดคุย แต่ละฝ่ายรู้ว่างานเฉพาะของพวกเขาคืออะไรเพราะมีการระบุไว้ในโปรโตคอล โปรโตคอลอนุญาตให้มีการแลกเปลี่ยนข้อมูลบริสุทธิ์โดยมีค่าใช้จ่ายในการเปลี่ยนแปลงใด ๆ ในการดำเนินการที่เป็นไปได้ ในอีกด้านหนึ่งการพูดคุยอนุญาตให้ฝ่ายหนึ่งถามถึงการดำเนินการเพิ่มเติมจากฝ่ายอื่น พวกเขาสามารถถามคำถามเดียวกันสองครั้งและได้คำตอบที่ต่างกันสองคำเนื่องจากรัฐของอีกฝ่ายอาจมีการเปลี่ยนแปลงในระหว่างกาล การพูดคุยเป็นสถาปัตยกรรมสงบ วิทยานิพนธ์ของฟีลดิงระบุว่าสถาปัตยกรรมจะต้องทำตามอย่างใดอย่างหนึ่งหากต้องการอนุญาตให้เครื่องพูดคุยกับคนอื่นมากกว่าเพียงแค่สื่อสาร

ไม่มีความคิดเช่น "การเขียนโปรแกรมสงบ" ต่อ se มันจะดีกว่าที่เรียกว่ากระบวนทัศน์สงบหรือสถาปัตยกรรมสงบยิ่งขึ้น มันไม่ใช่ภาษาโปรแกรม มันเป็นกระบวนทัศน์

จาก Wikipedia :

ในการคำนวณ, Representational State Transfer (REST) ​​เป็นรูปแบบสถาปัตยกรรมที่ใช้สำหรับการพัฒนาเว็บ

จุดพักคือถ้าเราตกลงที่จะใช้ภาษาทั่วไปสำหรับการดำเนินงานขั้นพื้นฐาน (คำกริยา http), โครงสร้างพื้นฐานสามารถกำหนดค่าให้เข้าใจและปรับให้เหมาะสมตัวอย่างเช่นโดยใช้ส่วนหัวแคชเพื่อใช้แคชเลย ระดับ

ด้วยการดำเนินการ GET ที่สงบถูกนำมาใช้อย่างเหมาะสมไม่สำคัญว่าข้อมูลนั้นมาจากฐานข้อมูลของเซิร์ฟเวอร์ของคุณ memcache ของเซิร์ฟเวอร์ CDN แคชของพร็อกซีแคชของเบราว์เซอร์หรือที่เก็บข้อมูลในเบราว์เซอร์ของคุณ สามารถใช้แหล่งข้อมูลที่ทันสมัยและรวดเร็วพร้อมใช้งานได้มากที่สุด

การบอกว่าส่วนที่เหลือเป็นเพียงการเปลี่ยนแปลงทางวากยสัมพันธ์จากการใช้คำขอ GET พร้อมพารามิเตอร์การดำเนินการเป็นการใช้คำกริยา http ที่มีอยู่ทำให้ดูเหมือนว่าไม่มีประโยชน์และเป็นเครื่องสำอางอย่างหมดจด ประเด็นคือการใช้ภาษาที่สามารถเข้าใจและปรับให้เหมาะสมโดยทุกส่วนของห่วงโซ่ หากการดำเนินการ GET ของคุณมีการดำเนินการที่มีผลข้างเคียงคุณต้องข้ามการแคช HTTP ทั้งหมดหรือคุณจะจบด้วยผลลัพธ์ที่ไม่สอดคล้องกัน

การทดสอบ APIคืออะไร

การทดสอบ API ใช้การเขียนโปรแกรมเพื่อส่งการเรียกไปยัง API และรับผลตอบแทน มันทดสอบเกี่ยวกับเซ็กเมนต์ภายใต้การทดสอบเป็นกล่องดำ วัตถุประสงค์ของการทดสอบ API คือเพื่อยืนยันการดำเนินการที่ถูกต้องและการปฏิบัติที่ผิดพลาดของส่วนที่นำหน้าการประสานงานของแอปพลิเคชัน

REST API

REST: การโอนย้ายสถานะผู้แทน

• มันคือการจัดเรียงของฟังก์ชั่นที่ผู้ทดสอบทำการร้องขอและรับการตอบกลับ ในการโต้ตอบ REST API จะทำผ่านโปรโตคอล HTTP
• ส่วนที่เหลือยังอนุญาตให้มีการสื่อสารระหว่างคอมพิวเตอร์กับแต่ละอื่น ๆ ผ่านเครือข่าย
• สำหรับการส่งและรับข้อความมันเกี่ยวข้องกับการใช้วิธีการ HTTP และไม่ต้องการคำจำกัดความของข้อความที่เข้มงวดซึ่งแตกต่างจากบริการเว็บ
• ข้อความ REST มักจะยอมรับรูปแบบทั้งในรูปแบบของ XML หรือสัญลักษณ์วัตถุ JavaScript (JSON)

4 วิธี API ที่ใช้กันทั่วไป: -

1. GET: - ให้การเข้าถึงทรัพยากรแบบอ่านอย่างเดียว
2. โพสต์: - มันถูกใช้เพื่อสร้างหรือปรับปรุงทรัพยากรใหม่
3. วาง: - มันถูกใช้เพื่ออัปเดตหรือแทนที่ทรัพยากรที่มีอยู่หรือสร้างทรัพยากรใหม่
4. ลบ: - มันถูกใช้เพื่อลบทรัพยากร

ขั้นตอนในการทดสอบ API ด้วยตนเอง: -

หากต้องการใช้ API ด้วยตนเองเราสามารถใช้ปลั๊กอิน REST API ที่เป็นเบราว์เซอร์

1. ติดตั้งปลั๊กอิน POSTMAN (Chrome) / REST (Firefox)
2. ป้อน URL API
3. เลือกวิธีการ REST
4. เลือก content-Header
5. ป้อนคำขอ JSON (POST)
6. คลิกที่ส่ง
7. มันจะกลับมาตอบสนองการส่งออก

ขั้นตอนในการทำให้ REST API เป็นแบบอัตโนมัติ

สิ่งนี้ถูกกล่าวถึงน้อยมากในทุกที่ แต่โมเดล Maturity ของ Richardsonเป็นหนึ่งในวิธีที่ดีที่สุดในการตัดสินว่า API ของ Restful นั้นเป็นอย่างไร เพิ่มเติมเกี่ยวกับที่นี่:

รูปแบบการครบกำหนดของ Richardson

/customers/{id}/balanceฉันจะบอกว่าอาคารที่มีความสำคัญในการทำความเข้าใจในส่วนที่เหลือโกหกปลายทางหรือแมปเช่น

คุณสามารถจินตนาการถึงจุดสิ้นสุดดังกล่าวว่าเป็นท่อเชื่อมต่อจากเว็บไซต์ (front-end) ไปยังฐานข้อมูล / เซิร์ฟเวอร์ของคุณ (back-end) การใช้ส่วนหน้าสามารถดำเนินการด้านหลังที่กำหนดไว้ในวิธีการที่สอดคล้องกันของการแมป REST ใด ๆ ในแอปพลิเคชันของคุณ