RESTful වැඩසටහන්කරණය යනු කුමක්ද?


3983

RESTful වැඩසටහන්කරණය යනු කුමක්ද?


3
පහත දැක්වෙන සබැඳියෙන් පිළිතුර ද බලන්න stackoverflow.com/a/37683965/3762855
Ciro Corvino

3
REST දැන් ටිකක් පරණ විය හැක;) youtu.be/WQLzZf34FJ8
ව්ලැඩි වෙසෙලිනොව්

1
තවද, වැඩි විස්තර සඳහා මෙම සබැඳිය බලන්න news.ycombinator.com/item?id=3538585
අෂ්රෆ්.ෂ්ක් 786

පිළිගත් පිළිතුරට නිවැරදි කිරීම් මෙහි. stackoverflow.com/questions/19843480/… හෝ මෙහි roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven හෝ මෙහි web.archive.org/web/20130116005443/http://tomayko. com /
writing

5
L ඔලිවර්.කූ හොඳ නිරීක්ෂණයක්. එය අලුත් දෙයක් වන මොහොතක මම එය ඇසුවෙමි. එය බොහෝ දුරට විසි වෙමින් පැවතුන නමුත් බොහෝ අය එය කුමක් දැයි දැන සිටියේ නැත. අඩුම තරමින් මම එසේ නොකළ අතර, මා මෙය විමසීම ඔවුන්ට උපකාරවත් වූ බව පෙනේ.
hasen

Answers:


744

ගෘහ නිර්මාණ ශිල්පීය ලෙස බෝපාල් (Representational රාජ්ය ස්ථාන මාරු) වෙනුවෙන් කතා එය කළ ලෙස වෙබ් යෙදුම් HTTP භාවිතා කළ යුතු බව මුලින් බලාපොරොත්තු වූ . විමසුම් GETඉල්ලීම් භාවිතා කළ යුතුය . PUT,, POSTසහ DELETEඉල්ලීම් පිළිවෙලින් විකෘති කිරීම, නිර්මාණය කිරීම සහ මකා දැමීම සඳහා භාවිතා කළ යුතුය .

REST යෝජකයින් වැනි URL වලට කැමති වේ

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

නමුත් REST ගෘහ නිර්මාණ ශිල්පයට මෙම “ලස්සන URL” අවශ්‍ය නොවේ. පරාමිතියක් සහිත GET ඉල්ලීමක්

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

සෑම දෙයක්ම RESTful ලෙස.

GET ඉල්ලීම් කිසි විටෙකත් තොරතුරු යාවත්කාලීන කිරීම සඳහා භාවිතා නොකළ යුතු බව මතක තබා ගන්න. උදාහරණයක් ලෙස, කරත්තයකට අයිතමයක් එක් කිරීම සඳහා GET ඉල්ලීමක්

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

සුදුසු නොවේ. GET ඉල්ලීම් අවිනිශ්චිත විය යුතුය . එනම්, දෙවරක් ඉල්ලීමක් නිකුත් කිරීම එක් වරක් නිකුත් කිරීමට වඩා වෙනස් නොවිය යුතුය. ඉල්ලීම් හැඹිලිගත කළ හැක්කේ එයයි. "කරත්තයට එකතු කරන්න" ඉල්ලීමක් අවිනිශ්චිත නොවේ it එය දෙවරක් නිකුත් කිරීමෙන් අයිතමයේ පිටපත් දෙකක් කරත්තයට එකතු වේ. මෙම සන්දර්භය තුළ POST ඉල්ලීමක් පැහැදිලිවම සුදුසු ය. මේ අනුව, RESTful වෙබ් යෙදුමකට පවා එහි POST ඉල්ලීම්වල කොටස අවශ්‍ය වේ.

ඩේවිඩ් එම්. ජෙරී විසින් රචිත කෝර් ජාවාසර්වර් මුහුණු පොතෙන් මෙය ලබාගෙන ඇත .


2
ලබා ගත හැකි අයිඩම්පොටෙන්ට් මෙහෙයුම්: GET (ආරක්ෂිත), PUT සහ DELETE (ව්‍යතිරේකය මෙම සබැඳියේ සඳහන් කර ඇත restapitutorial.com/lessons/idempotency.html). ආරක්ෂිත සහ Idempotent ක්රම w3.org/Protocols/rfc2616/rfc2616-sec9.html සඳහා අතිරේක විමර්ශන
Abhijeet

5
අ) GET පිළිබඳ වැදගත් කරුණ වන්නේ ආරක්‍ෂාව මිස අනන්‍යතාවය නොවේ, ආ) b අභිජිත්: RFC 2616 2014 දී යල් පැන ගොස් ඇත; RF 7230ff බලන්න.
ජූලියන් රෙස්ච්කේ


4
uskushalvm REST පිළිබඳ ශාස්ත්‍රීය අර්ථ දැක්වීම ප්‍රායෝගිකව භාවිතා නොවේ.
යුධමය චිම්පන්සි

3
සැමට ස්ථායී හා තේරුම්ගත හැකි අර්ථ දැක්වීමක් ලබා දීමට අප අසමත් වන බැවින් සංකල්පයක් ක්‍රියාත්මක වන්නේ
දැයි effectively ලදායී ලෙස අපට සිතිය හැකිය

2918

REST යනු වෙබයේ යටින් පවතින වාස්තු විද්‍යාත්මක මූලධර්මයයි. වෙබයේ ඇති පුදුමාකාර දෙය නම් සේවාදායකයා සහ එය සපයන සත්කාරක සම්පත් පිළිබඳව සේවාදායකයා කලින් කිසිවක් නොදැන සේවාදායකයින්ට (බ්‍රව්සර්) සහ සේවාදායකයන්ට සංකීර්ණ ආකාරවලින් අන්තර්ක්‍රියා කළ හැකි වීමයි. ප්‍රධාන බාධකය නම්, සේවාදායකයා සහ සේවාදායකයා යන දෙදෙනාම භාවිතා කරන මාධ්‍යයට එකඟ විය යුතු අතර , එය වෙබයේ HTML වේ.

REST හි මූලධර්මවලට අනුකූල වන API එකකට සේවාදායකයාගේ API ව්‍යුහය ගැන කිසිවක් දැන ගැනීමට අවශ්‍ය නොවේ. ඒ වෙනුවට, සේවාදායකයාට සේවාව සමඟ අන්තර් ක්‍රියා කිරීමට අවශ්‍ය තොරතුරු සේවාදායකයාට සැපයිය යුතුය. ක HTML ආකෘති පත්රය මේ උදාහරණයක්: මෙම සේවාදායකය සම්පත් හා අවශ්ය ක්ෂේත්ර ස්ථානය දක්වයි. තොරතුරු ඉදිරිපත් කළ යුත්තේ කොතැනදැයි බ්‍රව්සරය කල්තියා නොදන්නා අතර ඉදිරිපත් කළ යුතු තොරතුරු කල්තියා නොදනී. තොරතුරු ආකාර දෙකම මුළුමනින්ම සපයනු ලබන්නේ සේවාදායකයා විසිනි. (මෙම මූලධර්මය HATEOAS ලෙස හැඳින්වේ : යෙදුම් රාජ්‍යයේ එන්ජිම ලෙස හයිපර්මීඩියා .)

ඉතින්, මෙය HTTP සඳහා අදාළ වන්නේ කෙසේද, එය ප්‍රායෝගිකව ක්‍රියාත්මක කරන්නේ කෙසේද? HTTP ක්‍රියාපද හා සම්පත් වටා නැඹුරු වේ. ප්‍රධාන ධාරාවේ භාවිතයේ ඇති ක්‍රියා පද දෙක වන GETඅතර POST, එය සෑම කෙනෙකුම හඳුනා ගනු ඇතැයි මම සිතමි. කෙසේ වෙතත්, HTTP ප්‍රමිතිය PUTසහ වැනි තවත් කිහිපයක් අර්ථ දක්වයි DELETE. සේවාදායකයා විසින් සපයනු ලබන උපදෙස් අනුව මෙම ක්‍රියාපද සම්පත් සඳහා යොදනු ලැබේ.

උදාහරණයක් ලෙස, වෙබ් සේවාවක් මගින් කළමනාකරණය කරනු ලබන පරිශීලක දත්ත ගබඩාවක් අප සතුව ඇතැයි සිතමු. අපගේ සේවා JSON මත පදනම් වූ අභිරුචි hypermedia, එය සඳහා අප mimetype අනුයුක්ත භාවිතා application/json+userdb(ද ඇති විය හැකි application/xml+userdbඅතර application/whatever+userdb- බොහෝ මාධ්ය වර්ග සහාය විය හැක). සේවාදායකයා සහ සේවාදායකයා යන දෙදෙනාම මෙම ආකෘතිය අවබෝධ කර ගැනීම සඳහා වැඩසටහන්ගත කර ඇත, නමුත් ඔවුන් එකිනෙකා ගැන කිසිවක් නොදනිති. ලෙස රෝයි දෝනි පෙන්වා දෙයි:

REST API විසින් එහි විස්තරාත්මක උත්සාහයන් සියල්ලම පාහේ සම්පත් නියෝජනය කිරීම සහ යෙදුම් තත්වය ධාවනය කිරීම සඳහා භාවිතා කරන මාධ්‍ය වර්ගය (ය) නිර්වචනය කිරීමට හෝ දීර් extended සම්බන්ධතා නම් නිර්වචනය කිරීමට සහ / හෝ පවතින සම්මත මාධ්‍ය වර්ග සඳහා අධි-පෙළ සක්‍රීය සලකුණු කිරීම සඳහා වැය කළ යුතුය.

මූලික සම්පත් සඳහා ඉල්ලීමක් /මෙවැනි දෙයක් ආපසු ලබා දිය හැකිය:

ඉල්ලීම

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

"සබැඳි" යනුවෙන් හැඳින්වෙන කොටස් වලින් අදාළ සම්පත් පිළිබඳ තොරතුරු සොයාගත හැකි බව අපගේ මාධ්‍යයේ විස්තරයෙන් අපි දනිමු. මෙය හයිපර්මීඩියා පාලක ලෙස හැඳින්වේ . මෙම අවස්ථාවේදී, අපට එවැනි ඉල්ලීමකින් පරිශීලක ලැයිස්තුවක් සොයාගත හැකි බව එවැනි කොටසකින් අපට පැවසිය හැකිය /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මෙම සම්පත් මෙහෙයවීම සඳහා ආදිය), සහ සේවාදායකයාගේ පැත්තෙන් අපි අනුමාන එකම දැනුම අපගේ මාධ්ය අර්ථ දැක්වීම බව.

වැඩිදුර කීයවීම:

. මුලින්ම මෙය ලිව්වේ එහි සැබෑ අර්ථයට වඩා ය. සැබෑ අර්ථය වඩා හොඳින් නිරූපණය කිරීම සඳහා මම පිළිතුර සංශෝධනය කළෙමි.)


178
REST වෙනත් බස පදයක් ලෙස උත්පතන නොවීය. එය පැමිණියේ SOAP මත පදනම් වූ දත්ත හුවමාරුවට විකල්පයක් විස්තර කිරීමේ මාධ්‍යයක් වශයෙනි. REST යන පදය දත්ත මාරු කරන්නේ කෙසේද සහ ප්‍රවේශ වන්නේ කෙසේද යන්න පිළිබඳ සාකච්ඡාව සැකසීමට උපකාරී වේ.
tvanfosson

111
එසේ වුවද, REST හි හදවත (ප්‍රායෝගික භාවිතයේදී) “වෙනස්කම් කිරීමට GET භාවිතා නොකරන්න, POST / PUT / DELETE භාවිතා කරන්න”, මෙය SOAP දර්ශණය වීමට බොහෝ කලකට පෙර සිට මා අසා ඇති (සහ අනුගමනය කරන) උපදෙස් වේ. බෝපාල් ඇත හැම විටම වී, එය නම "එය කිරීමට මාර්ගය" ඔබ්බට මෑතක් වන තුරු ලබා ගැනීමට නොහැකි විය.
ඩේව් ෂෙරොහ්මන්

37
"යෙදුම් තත්වයේ එන්ජිම ලෙස හයිපර් ටෙක්ස්ට්" අමතක නොකරන්න.
හැන්ක් ගේ

45
මෙම පිළිතුර කාරණය මග හැරේ. ෆීල්ඩින්ගේ නිබන්ධනයේ HTTP යන්තම් සඳහන් නොවේ.
user359996

18
මෙම පිළිතුර REST හි අරමුණ ගැන සඳහන් නොකරන අතර එය පිරිසිදු URIs ගැන පෙනේ. මෙය REST පිළිබඳ ජනප්‍රිය මතය විය හැකි අතර, ඩී. ෂව්ලිගේ සහ ඔලූයිස් පිළිතුරු වඩාත් නිවැරදියි - එය වාස්තු විද්‍යාව තුළ ගොඩනගා ඇති අංගයන්ගෙන් ප්‍රයෝජන ගැනීමට හැකිවීම, හැඹිලි වැනි, එයට එරෙහිව නොව ඒ සමඟ වැඩ කිරීමෙන්. Prettier URIs බොහෝ විට පොදු අතුරු ආබාධයකි.
TR

534

RESTful වැඩසටහන්කරණය ගැන:

  • නොනවතින හඳුනාගැනීමක් මගින් සම්පත් හදුනා ගැනීම: යූආර්අයි යනු මේ දිනවල හඳුනාගැනීමේ සර්ව සම්පූර්ණ තේරීමයි
  • සම්පත් ක්රියාපද පොදු කට්ටලයක් භාවිතා කි්රයාත්මක වෙමින්: HTTP ක්රම බහුලව දක්නට නඩුව ඇත - ගෞරවනීය Create, Retrieve, Update, Deleteබවට පත් වෙයි POST, GET, PUT, සහ DELETE. නමුත් REST HTTP ට පමණක් සීමා නොවේ, එය දැන් බහුලව භාවිතා වන ප්‍රවාහන වේ.
  • සම්පතක් සඳහා ලබාගත් සත්‍ය නිරූපණය රඳා පවතින්නේ ඉල්ලීම මත මිස අනන්‍යතාවය මත නොවේ: ඔබට XML, HTTP හෝ සම්පත නියෝජනය කරන ජාවා වස්තුවක් අවශ්‍යද යන්න පාලනය කිරීමට ශීර්ෂයන් පිළිගන්න.
  • වස්තුව තුළ රාජ්‍යය පවත්වා ගෙන යාම සහ නිරූපණය තුළ රාජ්‍යය නියෝජනය කිරීම
  • සම්පත නිරූපණය කිරීමේදී සම්පත් අතර සම්බන්ධතා නිරූපණය කිරීම: වස්තූන් අතර සම්බන්ධතා සෘජුවම නිරූපණයට කාවැදී ඇත
  • සම්පත් නිරූපණයන් මගින් නිරූපණය භාවිතා කළ හැකි ආකාරය සහ එය නිරන්තරයෙන් බැහැර කළ යුතු / නැවත සකස් කළ යුතු තත්වයන් විස්තර කරයි: HTTP හැඹිලි-පාලන ශීර්ෂ භාවිතය

REST හි ප්‍රතිවිපාක සහ සමස්ත effectiveness ලදායීතාවය අනුව අවසාන එක වඩාත් වැදගත් වේ. සමස්තයක් වශයෙන්, RESTful සාකච්ඡා බොහොමයක් HTTP සහ එය බ්‍රව්සරයකින් භාවිතා කිරීම සහ නොකළ යුතු දේ කෙරෙහි කේන්ද්‍රගත වී ඇති බව පෙනේ. ආර්. ෆීල්ඩින් විසින් HTTP වෙත යොමු වන ගෘහ නිර්මාණ ශිල්පය සහ තීරණ විස්තර කරන විට මෙම යෙදුම භාවිතා කළ බව මට වැටහේ. ඔහුගේ නිබන්ධනය HTTP වලට වඩා සම්පත් වල ගෘහ නිර්මාණ ශිල්පය සහ හැඹිලි හැකියාව ගැන ය.

RESTful ගෘහ නිර්මාණ ශිල්පය යනු කුමක්ද සහ එය ක්‍රියාත්මක වන්නේ ඇයිද යන්න පිළිබඳව ඔබ සැබවින්ම උනන්දු වන්නේ නම්, ඔහුගේ නිබන්ධනය කිහිප වතාවක් කියවා 5 වන පරිච්ඡේදය පමණක් නොව සමස්ත දේම කියවන්න ! ඊළඟට DNS ක්‍රියා කරන්නේ මන්දැයි සොයා බලන්න . ඩීඑන්එස් හි ධූරාවලි සංවිධානය සහ යොමු කිරීම් ක්‍රියාත්මක වන ආකාරය ගැන කියවන්න. ඉන්පසු DNS හැඹිලි ක්‍රියා කරන ආකාරය කියවා සලකා බලන්න. අවසාන වශයෙන්, HTTP පිරිවිතර (විශේෂයෙන් RFC2616 සහ RFC3040 ) කියවා හැඹිලිය ක්‍රියා කරන ආකාරය සහ කෙසේද යන්න සලකා බලන්න. අවසානයේදී, එය ක්ලික් කරනු ඇත. මට අවසාන හෙළිදරව්ව වූයේ ඩීඑන්එස් සහ එච්ටීටීපී අතර සමානකම් දුටු විට ය. මෙයින් පසු, SOA සහ පණිවිඩ යැවීමේ අතුරුමුහුණත් පරිමාණය කළ හැකි වන්නේ මන්දැයි තේරුම් ගැනීම ක්ලික් කිරීමට පටන් ගනී.

RESTful සහ Shared කිසිවක් ගෘහ නිර්මාණ ශිල්පයේ වාස්තු විද්‍යාත්මක වැදගත්කම සහ කාර්යසාධනය පිළිබඳ අවබෝධය ලබා ගැනීම සඳහා ඇති වැදගත්ම උපක්‍රමය වන්නේ තාක්‍ෂණය සහ ක්‍රියාත්මක කිරීමේ තොරතුරු මත රැඳී සිටීම වළක්වා ගැනීමයි. සම්පත් අයිති කාටද, ඒවා නිර්මාණය කිරීමට / නඩත්තු කිරීමට වගකිව යුත්තේ කවුරුන්ද යන්න පිළිබඳව අවධානය යොමු කරන්න. ඉන්පසු නිරූපණයන්, ප්‍රොටෝකෝල සහ තාක්ෂණයන් ගැන සිතන්න.


36
කියවීමේ ලැයිස්තුවක් සපයන පිළිතුරක් මෙම ප්‍රශ්නයට ඉතා යෝග්‍ය වේ.
ellisbben

25
මෙම යාවත්කාලීන සඳහා ස්තුති. PUTහා POSTඇත්තටම එකට එක යාවත් කාලීන සිතියම්ගත සහ නිර්මාණය කරන්නේ නැහැ. PUTසේවාදායකයා යූආර්අයි යනු කුමක්දැයි නියම කරන්නේ නම් නිර්මාණය කිරීමට භාවිතා කළ හැකිය. POSTසේවාදායකය නව URI පවරන්නේ නම් නිර්මාණය කරයි.
ඩී. ෂව්ලි

8
පැච් එක අමතක කරන්න එපා.
epitka

4
යූආර්එන් යනු urn:යෝජනා ක්‍රමය භාවිතා කරන යූආර්අයි ය. සංකල්පමය වශයෙන් වෙනසක් නැත; කෙසේ වෙතත්, යූආර්එන් විසින් හඳුනාගෙන ඇති (නම් කරන ලද) සම්පත් "සොයා ගැනීම" සඳහා වෙනමම අර්ථ දක්වා ඇති ක්‍රමවේදයක් තිබිය යුතුය. නම් කරන ලද සම්පත් සහ ඒවායේ පිහිටීම සම්බන්ධව ඔබ ව්‍යංග සම්බන්ධ කිරීම හඳුන්වා නොදීමට වග බලා ගත යුතුය.
ඩී. ෂව්ලි

2
ඇලිස්බන් එකඟ විය. මා නිවැරදිව වටහා ගන්නේ නම් මෙය REST: ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm
පිලිප් කූලින්ග්

408

මෙය පෙනෙන්නේ මෙයයි.

ගුණාංග තුනක් සහිත පරිශීලකයෙකු සාදන්න:

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හා ageNULL වනු ඇත):

PUT /user/123
fname=Johnny

39
මට නම් මෙම පිළිතුර අපේක්ෂිත පිළිතුරේ සාරය ග්‍රහණය කර ගත්තේය. සරල හා ප්‍රායෝගික. වෙනත් නිර්ණායක රාශියක් ඇති බව පිළිගත යුතුය, නමුත් සපයන ලද උදාහරණය විශිෂ්ට දියත් කිරීමේ දොරටුවකි.
සයිබර් ෆොනික්

92
අවසාන උදාහරණයේ දී brebbreitenbach භාවිතා කරයි PUT fname=Jonny. මෙය සකසා ඇති lnameඅතර ageපෙරනිමි අගයන් (බොහෝ විට NULL හෝ හිස් නූල සහ පූර්ණ සංඛ්‍යා 0) වනු ඇත, මන්දයත් සපයන ලද නිරූපණයෙන් දත්ත සමඟ PUT මුළු සම්පතම නැවත ලියයි . මෙය “යාවත්කාලීනය” මගින් ගම්‍ය වන දෙයක් නොවේ, සැබෑ යාවත්කාලීනයක් කිරීමට,PATCH මෙය නිරූපණයෙහි නිශ්චිතව දක්වා නොමැති ක්ෂේත්‍ර වෙනස් නොකරන බැවින් ක්‍රමය භාවිතා කරන්න .
නිකලස් ෂෑන්ක්ස්

24
නිකලස් හරි. එසේම, පරිශීලකයෙකු නිර්මාණය කරන පළමු පෝස්ට් සඳහා යූආර්අයි පරිශීලකයින් ලෙස හැඳින්විය යුත්තේ /user/1කිසිදු තේරුමක් නැති නිසා සහ ලැයිස්තුවක් තිබිය යුතු බැවිනි /users. ප්‍රතිචාරය විය යුත්තේ 201 Createdඑම අවස්ථාවේ දී පමණක් නොවේ.
ඩෑන්මන්

1
මෙය API සඳහා උදාහරණයක් පමණක් අවශ්‍යයෙන්ම RESTful api නොවේ. RESTful ට එය පිළිපැදීමට බාධා ඇත. සේවාලාභී-සේවාදායක ගෘහ නිර්මාණ ශිල්පය, අස්ථායි, හැඹිලි හැකියාව, ස්ථර පද්ධතිය, ඒකාකාර අතුරුමුහුණත.
විකිරණ

සියලු http සේවාදායක ප්‍රවේශ ක්‍රම ආවරණය කරන ඉතා සංයුක්ත පිළිතුරකි
හිමාන්ෂු අහුජා

181

REST පිළිබඳ විශිෂ්ට පොතක් REST in Practice වේ.

අනිවාර්යයෙන්ම කියවිය යුත්තේ නියෝජිත රාජ්‍ය මාරුව (REST) සහ REST API අධි-පෙළ මත පදනම් විය යුතුය

RESTful සේවාවක් යනු කුමක්ද යන්න පිළිබඳ පැහැදිලි කිරීමක් සඳහා මාටින් ෆෝලර්ස් ලිපිය රිචඩ්සන් පරිණත ආකෘතිය (RMM) බලන්න .

රිචඩ්සන් පරිණත ආකෘතිය

සේවාවක් හයිපර්මීඩියා යෙදුම් රාජ්‍යයේ එන්ජිම ලෙස සපුරාලිය යුතුය . (HATEOAS) , එනම්, එය RMM හි 3 වන මට්ටමට ළඟා විය යුතුය, විස්තර සඳහා ලිපිය කියවන්න හෝ qcon කතාවේ විනිවිදක .

HATEOAS අවහිරතාවය යනු හයිපර්මීඩියා හි යෙදුම් රාජ්‍යයේ එන්ජිමයි. මෙම මූලධර්මය REST සහ වෙනත් බොහෝ සේවාදායක සේවාදායක පද්ධති අතර ප්‍රධාන අවකලනයයි.

...

RESTful යෙදුමක සේවාදායකයෙකුට අවශ්‍ය වන්නේ එයට ප්‍රවේශ වීම සඳහා එක් ස්ථාවර URL එකක් පමණි. එම URL වෙතින් ආපසු ලබා දෙන සම්පත් වල නිරූපණයන්හි ඇතුළත් කර ඇති හයිපර්මීඩියා සබැඳි වලින් අනාගත සියලු ක්‍රියා ගතිකව සොයාගත යුතුය. RESTful API භාවිතා කළ හැකි ඕනෑම සේවාදායකයකු විසින් ප්‍රමිතිගත මාධ්‍ය වර්ග තේරුම් ගනු ඇතැයි අපේක්ෂා කෙරේ. (විකිපීඩියා, නිදහස් විශ්වකෝෂය වෙතින්)

වෙබ් රාමු සඳහා REST Litmus Test යනු වෙබ් රාමු සඳහා සමාන පරිණත පරීක්ෂණයකි.

පිරිසිදු REST වෙත ළඟා වීම: HATEOAS වලට ආදරය කිරීමට ඉගෙන ගැනීම හොඳ සබැඳි එකතුවකි.

පොදු වලාකුළු සඳහා REST හා SOAP අතර වර්තමාන REST භාවිතයේ මට්ටම් සාකච්ඡා කරයි.

REST සහ අනුවාදය නවීකරණය කිරීමේ හැකියාව හරහා විස්තාරණතාව, අනුවාදකරණය, පරිණාමය වීමේ හැකියාව ආදිය සාකච්ඡා කරයි


5
මෙම පිළිතුර REST අවබෝධ කර ගැනීමේ ප්‍රධාන කරුණට ස්පර්ශ වන බව මම සිතමි: නිරූපණය යන වචනයේ තේරුම කුමක්ද? පළමු මට්ටම - සම්පත් රාජ්ය ගැන පවසයි . 2 වන මට්ටම - මාරුවීම ගැන HTTP ක්‍රියාපද පවසයි (කියවීම වෙනස් කිරීම ). තෙවන මට්ටම - HATEOAS පවසන්නේ අනාගත මාරුවීම් නිරූපණය හරහා ධාවනය කිරීම (JSON / XML / HTML ආපසු), එයින් අදහස් කරන්නේ ආපසු ලබා දුන් තොරතුරු සමඟ ඊළඟ වටයේ කථාව පවසන්නේ කෙසේදැයි ඔබ දැනගෙන ඇති බවයි. එබැවින් REST හි මෙසේ කියවේ: "((නියෝජන රාජ්ය) මාරු කිරීම) වෙනුවට" (නියෝජන (රාජ්ය හුවමාරුව)) ".
lcn


136

REST යනු කුමක්ද?

REST යනු නියෝජිත රාජ්‍ය මාරුවයි. (එය සමහර විට "ReST" ලෙස අක්ෂර වින්‍යාසය ඇත.) එය අස්ථායි, සේවාදායක-සේවාදායක, හැඹිලි කළ හැකි සන්නිවේදන ප්‍රොටෝකෝලයක් මත රඳා පවතී - සහ සෑම අවස්ථාවකම පාහේ HTTP ප්‍රොටෝකෝලය භාවිතා කරයි.

REST යනු ජාලගත යෙදුම් සැලසුම් කිරීම සඳහා ගෘහ නිර්මාණ ශෛලියකි. යන්ත‍්‍ර අතර සම්බන්ධ වීමට CORBA, RPC හෝ SOAP වැනි සංකීර්ණ යාන්ත්‍රණ භාවිතා කරනවා වෙනුවට යන්ත්‍ර අතර ඇමතුම් ලබා ගැනීම සඳහා සරල HTTP භාවිතා කරයි.

බොහෝ ආකාරවලින්, HTTP මත පදනම් වූ ලෝක ව්‍යාප්ත වෙබ් අඩවිය REST මත පදනම් වූ ගෘහ නිර්මාණ ශිල්පයක් ලෙස දැකිය හැකිය. RESTful යෙදුම් දත්ත පළ කිරීම (නිර්මාණය කිරීම සහ / හෝ යාවත්කාලීන කිරීම), දත්ත කියවීම (උදා: විමසුම් කරන්න) සහ දත්ත මකා දැමීම සඳහා HTTP ඉල්ලීම් භාවිතා කරයි. මේ අනුව, REST CRUD (Create / Read / Update / Delete) මෙහෙයුම් හතර සඳහාම HTTP භාවිතා කරයි.

REST යනු RPC (දුරස්ථ ක්‍රියා පටිපාටි ඇමතුම්) සහ වෙබ් සේවා (SOAP, WSDL, සහ වෙනත්) වැනි යාන්ත්‍රණයන් සඳහා සැහැල්ලු විකල්පයකි. REST යනු කෙතරම් සරලද යන්න පසුව අපි බලමු.

සරල වුවත්, REST සම්පූර්ණයෙන්ම අංගයකි; RESTful ගෘහ නිර්මාණ ශිල්පයකින් කළ නොහැකි වෙබ් සේවා තුළ ඔබට කළ හැකි කිසිවක් නැත. REST යනු “ප්‍රමිතියක්” නොවේ. උදාහරණයක් ලෙස REST සඳහා W3C නිර්දේශයක් නොමැත. REST ක්‍රමලේඛන රාමු තිබියදීත්, REST සමඟ වැඩ කිරීම ඉතා සරල බැවින් ඔබට බොහෝ විට පර්ල්, ජාවා හෝ සී # වැනි භාෂාවලින් සම්මත පුස්තකාල විශේෂාංග සමඟ “ඔබේම දෑ රෝල්” කළ හැකිය.

විවේකයේ සරල සැබෑ අරුත සොයා ගැනීමට උත්සාහ කරන විට මා සොයාගත් හොඳම සඳහනකි.

http://rest.elkstein.org/


මෙය සැබවින්ම සංක්ෂිප්ත පිළිතුරකි. REST අස්ථායි ලෙස හඳුන්වන්නේ මන්දැයි ඔබට විස්තර කළ හැකිද?
චක්ලඩර් අස්ෆක් අරෙෆේ

89

REST දත්ත හැසිරවීම සඳහා විවිධ HTTP ක්‍රම (ප්‍රධාන වශයෙන් GET / PUT / DELETE) භාවිතා කරයි.

ක්‍රමයක් මකා දැමීමට නිශ්චිත URL එකක් භාවිතා කරනවා වෙනුවට (කියන්න, /user/123/delete), ඔබ /user/[id]GET ඉල්ලීමක් යවන පරිශීලකයෙකුගේ තොරතුරු ලබා ගැනීමට, පරිශීලකයකු සංස්කරණය කිරීමට, URL වෙත DELETE ඉල්ලීමක් යවනු ඇත./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

18
එය "HTTP නිසියාකාරව භාවිතා කිරීම", එය "
විවේක

2
ඔබට / user / del / 2 සහ / user / remove / 2 හෝ ... GET / DELETE / PUT / POST යනු එවැනි දේ කිරීමට ප්‍රමිතිගත, “නිසි” ක්‍රමයක් පමණි (ජූලියන් පවසන පරිදි, එපමණක් නොවේ REST වෙත ඇත)
dbr

1
ෂුවර්, නමුත් ඒවා වළක්වා ගැනීමට එය හේතුවක් නොවේ .. REST මඟින් සෑම විටම රෝදය ප්‍රතිනිර්මාණය කිරීමෙන් ඔබව ඉතිරි කරයි. ඒපීඅයි සඳහා, REST විශිෂ්ටයි (අනුකූලතාව!), නමුත් අහඹු වෙබ් අඩවියක්
සැකසීම සඳහා

14
වඩීම්, එය හුදෙක් ආර්පීසී ය. (වෙනත් හේතූන් අතර) සෙවුම් යන්ත්‍රයක් මඟින් ඔබේ මකාදැමීමේ සම්බන්ධතා මකුළු කර ඒවා සියල්ලම නැරඹිය හැකි බැවින් දත්ත වෙනස් කිරීම සඳහා GET භාවිතා කිරීම ද භයානක ය.
aehlke

7
@aehlke - එහි ඇති සැබෑ ප්‍රශ්නය වනුයේ "නිර්නාමික පරිශීලකයෙකුට ඔබේ පද්ධතියෙන් වාර්තා මකා දැමීමේ හැකියාව ඇත්තේ මන්ද?"
ස්පෙන්සර් රූපට්

68

රෝයි ෆීල්ඩින් විසින් ඔහුගේ නිබන්ධනයේ දක්වා ඇති REST ශෛලියට ඔබේ පද්ධතියේ ගෘහ නිර්මාණ ශිල්පය ගැලපෙන වැඩසටහන්කරණයකි . වෙබය විස්තර කරන වාස්තු විද්‍යාත්මක ශෛලිය මෙය බැවින් (වැඩි හෝ අඩු), බොහෝ දෙනෙක් ඒ ගැන උනන්දු වෙති.

පාරිතෝෂික පිළිතුර: නැත. ඔබ මෘදුකාංග ගෘහ නිර්මාණ ශිල්පය ශාස්ත්‍රීය හෝ වෙබ් සේවා සැලසුම් කිරීමක් ලෙස හැදෑරුවේ නැත්නම්, මෙම පදය ඇසීමට කිසිදු හේතුවක් නැත.


2
නමුත් කෙළින්ම ඉදිරියට නොවේ .. එය විය යුතු බව වඩාත් සංකීර්ණ කරයි.
hasen

4
එසේම, REST සහ RESTful යන යෙදුම් වෙබ් යෙදුම් ක්ෂේත්‍රය තුළ පමණක්ම පාහේ භාවිතා කර ඇතත්, තාක්‍ෂණිකව REST HTTP සමඟ සම්බන්ධ කිරීමට කිසිවක් නොමැත.
හැන්ක් ගේ

3
ෆීල්ඩින්ගේ බ්ලොග් අඩවියේ REST සහ පොදු වැරදි වැටහීම් පිළිබඳ ලිපි තේරුම් ගැනීමට පහසු, පහසු ය: roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven
aehlke

3
@HankGay මම සිතන්නේ එය වඩාත් ව්‍යාකූල නොවීමට හේතුව බොහෝ වෙබ් සේවා සංවර්ධකයින් REST දකින්නේ SOAP වැනි විකල්පයන්ට වඩා පුදුමාකාර සරල කිරීමක් ලෙස ය. ඔවුන් සියලු REST තාක්‍ෂණයන් නිවැරදිව ලබා ගැනීමට බැඳී නොසිටින අතර - එය බොහෝ විට REST රසිකයින් උමතු කරවන්නක් විය හැකිය - නමුත් බොහෝ විට ඔවුන්ගේ ප්‍රති results ල “හයිපර්මීඩියා-සක්‍රීය” බවට වග බලා ගැනීම වැනි දේවල් ගැන කරදර වීමට අවශ්‍ය නැත.
moodboom

47

RESTful වැඩසටහන්කරණය යනු REST වාස්තු විද්‍යාත්මක ශෛලිය අනුගමනය කරන පද්ධති (API) නිර්මාණය කිරීම යැයි මම කියමි.

ආචාර්ය එම්. එල්ක්ස්ටයින් විසින් REST පිළිබඳ නිබන්ධනය සහ ඔබේ ප්‍රශ්නයට බොහෝ දුරට පිළිතුරු සැපයිය යුතු අත්‍යවශ්‍ය කොටස උපුටා දක්වමින් මෙම අපූරු, කෙටි හා පහසුවෙන් තේරුම් ගත හැකි නිබන්ධනයක් මට හමු විය:

REST ඉගෙන ගන්න: නිබන්ධනයක්

REST යනු ජාලගත යෙදුම් සැලසුම් කිරීම සඳහා ගෘහ නිර්මාණ ශෛලියකි . යන්ත‍්‍ර අතර සම්බන්ධ වීමට CORBA, RPC හෝ SOAP වැනි සංකීර්ණ යාන්ත්‍රණ භාවිතා කරනවා වෙනුවට යන්ත්‍ර අතර ඇමතුම් ලබා ගැනීම සඳහා සරල HTTP භාවිතා කරයි.

  • බොහෝ ආකාරවලින්, HTTP මත පදනම් වූ ලෝක ව්‍යාප්ත වෙබ් අඩවිය REST මත පදනම් වූ ගෘහ නිර්මාණ ශිල්පයක් ලෙස දැකිය හැකිය.

RESTful යෙදුම් දත්ත පළ කිරීම (නිර්මාණය කිරීම සහ / හෝ යාවත්කාලීන කිරීම), දත්ත කියවීම (උදා: විමසුම් කරන්න) සහ දත්ත මකා දැමීම සඳහා HTTP ඉල්ලීම් භාවිතා කරයි. මේ අනුව, REST CRUD (Create / Read / Update / Delete) මෙහෙයුම් හතර සඳහාම HTTP භාවිතා කරයි.

ස්ටැක් පිටාර ගැලීමෙන් පිටත REST ගැන ඇසීම ගැන ඔබට මෝඩකමක් දැනෙනු ඇතැයි මම නොසිතමි ..., මමත් එම තත්වයේම සිටිමි! REST දැන් විශාල වන්නේ ඇයි යන තවත් SO ප්‍රශ්නයට පිළිතුරු සමහර හැඟීම් ලිහිල් කළ හැකිය.


මෙම ලිපියෙන් HTTP සහ REST freecodecamp.org/news/…
ඔබ පමණක්

45

මම ප්‍රශ්නයට කෙලින්ම පිළිතුරු නොදෙන්නේ නම් මම සමාව ඉල්ලමි, නමුත් මේ සියල්ල වඩාත් සවිස්තරාත්මක උදාහරණ සමඟ තේරුම් ගැනීම පහසුය. සියලු වියුක්ත හා පාරිභාෂිතය නිසා ක්ෂේත්‍රකරණය තේරුම් ගැනීම පහසු නැත.

මෙහි තරමක් හොඳ උදාහරණයක් තිබේ:

REST සහ හයිපර් ටෙක්ස්ට් පැහැදිලි කිරීම: අයාචිත තැපැල් පිරිසිදු කිරීමේ රොබෝ

ඊටත් වඩා හොඳයි, මෙහි සරල උදාහරණ සමඟ පිරිසිදු පැහැදිලි කිරීමක් ඇත (පවර්පොයින්ට් වඩාත් පුළුල් ය, නමුත් ඔබට එය බොහෝමයක් html අනුවාදයෙන් ලබා ගත හැකිය):

http://www.xfront.com/REST.ppt හෝ http://www.xfront.com/REST.html

උදාහරණ කියවීමෙන් පසුව, REST හයිපර් ටෙක්ස්ට් මඟින් ධාවනය වන බව කෙන් පවසන්නේ මන්දැයි මට වැටහුණි. ඔහු / පරිශීලක / 123 යනු සම්පතක් වෙත යොමු වන යූආර්අයි එකක් වන නිසාත්, සේවාදායකයා ඒ ගැන "සංගීත කණ්ඩායමෙන් බැහැරව" දන්නා නිසාත් එය අවිනිශ්චිත බව මට පැහැදිලි නැත.

එම xfront ලේඛනය REST සහ SOAP අතර වෙනස පැහැදිලි කරයි, මෙයද ඇත්තෙන්ම ප්‍රයෝජනවත් වේ. ෆීල්ඩින් පවසන විට, “ එය ආර්පීසී ය. එය ආර්පීසී කෑගසයි. ”, ආර්පීසී රෙස්ට්ෆුල් නොවන බව පැහැදිලිය, එබැවින් මේ සඳහා නිශ්චිත හේතු බැලීම ප්‍රයෝජනවත් වේ. (SOAP යනු RPC වර්ගයකි.)


12
නියම සබැඳි, ස්තූතියි. සමහර උදාහරණ "REST-ful" නොවන බව පවසන මෙම REST යාලුවනේ මට මහන්සියි, නමුත් REST-ful ලෙස ආදර්ශය වෙනස් කරන්නේ කෙසේදැයි පැවසීම ප්‍රතික්ෂේප කරන්න.
coder_tim

38

REST යනු කුමක්ද?

නිල වචන වලින් REST, REST යනු වර්තමාන “වෙබ්” මූලධර්ම භාවිතා කරමින් ඇතැම් මූලධර්ම මත ගොඩනගා ඇති වාස්තු විද්‍යාත්මක ශෛලියකි. REST සේවාවන් නිර්මාණය කිරීම සඳහා උත්තේජනය කරන වෙබ් අඩවි වල මූලික මූලධර්ම 5 ක් ඇත.

  • මූලධර්මය 1: සෑම දෙයක්ම සම්පතක් REST වාස්තු විද්‍යාත්මක ශෛලිය තුළ, දත්ත සහ ක්‍රියාකාරිත්වය සම්පත් ලෙස සලකනු ලබන අතර සාමාන්‍යයෙන් වෙබයේ සබැඳි වන ඒකාකාර සම්පත් හඳුනාගැනීම් (URIs) භාවිතයෙන් ප්‍රවේශ වේ.
  • මූලධර්මය 2: සෑම සම්පතක්ම අද්විතීය හඳුනාගැනීමක් (යූආර්අයි) විසින් හඳුනා ගනු ලැබේ
  • මූලධර්මය 3: සරල හා ඒකාකාර අතුරුමුහුණත් භාවිතා කරන්න
  • 4 වන මූලධර්මය: සන්නිවේදනය සිදු කරනු ලබන්නේ නියෝජනයෙනි
  • මූලධර්මය 5: අස්ථිර වන්න

1
එයින් Communication is Done by Representationඅදහස් කරන්නේ කුමක්ද?
mendez7

33

පරිශීලක 123 ගැන සෑම දෙයක්ම "/ user / 123" සම්පතෙහි තැබීම RESTful යැයි පවසන පිළිතුරු පොකුරක් මට පෙනේ.

මෙම යෙදුම භාවිතා කළ රෝයි ෆීල්ඩින් පවසන්නේ REST APIs අධි-පෙළ මත පදනම් විය යුතු බවයි . විශේෂයෙන්, "REST API මඟින් ස්ථාවර සම්පත් නම් හෝ ධූරාවලිය නිර්වචනය නොකළ යුතුය".

එබැවින් ඔබේ "/ user / 123" මාර්ගය සේවාදායකයා මත තදින් කේතනය කර ඇත්නම්, එය සැබවින්ම RESTful නොවේ. HTTP හොඳ භාවිතය, සමහර විට, සමහර විට නැත. නමුත් RESTful නොවේ. එය හයිපර් ටෙක්ස්ට් වලින් පැමිණිය යුතුය.


7
ඉතින් .... එම ආදර්ශය සන්සුන් වන්නේ කෙසේද? යූආර්එල් එක සන්සුන් කිරීම සඳහා ඔබ වෙනස් කරන්නේ කෙසේද?
hasen

1
hasen: සියලු මෙහෙයුම් සඳහා එක් සම්පතක් භාවිතා කිරීම RESTfulness සඳහා අවශ්‍ය විය හැකි නමුත් එය ප්‍රමාණවත් නොවේ .
කෙන්

18
හොඳයි .. ඔබට තවදුරටත් විස්තර කළ හැකිද? ඔබ දන්නා දේ (හෝ සිතන) නිවැරදි යැයි නොකියමින් "මේ අය වැරදියි .. මම හරි දේ දන්නවා" යැයි කීමේ තේරුම කුමක්ද?
hasen

5
ෆීල්ඩින්ගේ විස්තරයට මම සබැඳිය දුන්නා. අනෙක් ප්‍රතිචාර වලට අදාළ වෙනස හරියටම කිව යුතු යැයි මම සිතුවෙමි: හයිපර් ටෙක්ස්ට් මඟින් ධාවනය කළ යුතුය. "/ User / 123" පැමිණෙන්නේ කිසියම් බාහිර API ප්‍රලේඛනයකින් නම්, එය RESTful නොවේ. එය ඔබගේ හයිපර් ටෙක්ස්ට් හි සම්පත් හදුනාගැනීමක් වෙතින් පැමිණේ නම් එය එසේ වේ.
කෙන්

1
නැතහොත් ඔබට / පරිශීලකයින් / වැනි පිවිසුම් ස්ථානයක් භාවිතා කළ හැකි අතර එමඟින් ඔබට පරිශීලක සම්පත් ලැයිස්තුවක් සහ එක් එක් සඳහා යූආර්අයි ලබා දෙනු ඇත. එවිට සම්පත් සොයාගත හැකි අතර සංචලනය අධි-පෙළ මත පදනම් වේ.
aehlke

26

පිළිතුර ඉතා සරල ය, රෝයි ෆීල්ඩින් විසින් රචිත නිබන්ධනයක් ඇත.] 1 එම නිබන්ධනයේ දී ඔහු REST මූලධර්ම නිර්වචනය කරයි. යෙදුමක් එම මූලධර්ම සියල්ලම සපුරා ඇත්නම්, එය REST යෙදුමකි.

RESTful යන පදය නිර්මාණය කරන ලද්දේ ppl ඔවුන්ගේ REST නොවන යෙදුම REST ලෙස ඇමතීමෙන් REST යන වචනය අවසන් කර ඇති බැවිනි. ඊට පසු RESTful යන පදය ද අවසන් විය. වර්තමානයේ අපි කතා කරන්නේ වෙබ් ඒපීඅයි සහ හයිපර්මීඩියා ඒපීඅයි ගැන ය , මන්ද යත් ඊනියා REST යෙදුම් බොහොමයක් ඒකාකාරී අතුරුමුහුණත් අවහිරතාවයේ HATEOAS කොටස සපුරා නොමැති බැවිනි.

REST අවහිරතා පහත දැක්වේ:

  1. ග්‍රාහක සේවාදායක සැකැස්ම

    එබැවින් එය PUB / SUB සොකට් සමඟ ක්‍රියා නොකරයි, එය REQ / REP මත පදනම් වේ.

  2. අස්ථායි සන්නිවේදනය

    එබැවින් සේවාදායකයා සේවාදායකයින්ගේ තත්වයන් නඩත්තු නොකරයි. මෙයින් අදහස් කරන්නේ ඔබට සේවාදායකයාට පැති සැසි ගබඩාවක් භාවිතා කළ නොහැකි අතර සෑම ඉල්ලීමක්ම සත්‍යාපනය කළ යුතු බවයි. ඔබේ සේවාදායකයින් සංකේතාත්මක සම්බන්ධතාවයක් හරහා මූලික සත්‍යාපන ශීර්ෂයන් යැවිය හැක. (විශාල යෙදුම් මගින් බොහෝ සැසි පවත්වා ගැනීම දුෂ්කර ය.)

  3. ඔබට හැකි නම් හැඹිලි භාවිතය

    එබැවින් ඔබට එකම ඉල්ලීම් නැවත නැවතත් සේවය කිරීමට අවශ්‍ය නැත.

  4. සේවාදායකයා සහ සේවාදායකයා අතර පොදු ගිවිසුමක් ලෙස ඒකාකාර අතුරුමුහුණත

    සේවාදායකයා සහ සේවාදායකයා අතර ඇති කොන්ත්‍රාත්තුව සේවාදායකයා විසින් නඩත්තු නොකෙරේ. වෙනත් වචන වලින් කිවහොත්, සේවාව ක්‍රියාත්මක කිරීමෙන් සේවාදායකයා වෙන් කළ යුතුය. සම්පත් හඳුනා ගැනීම සඳහා IRI (URI) ප්‍රමිතිය, පණිවිඩ හුවමාරු කර ගැනීම සඳහා HTTP ප්‍රමිතිය, ශරීර අනුක්‍රමික ආකෘතිය විස්තර කිරීමට සම්මත MIME වර්ග, පාර-දත්ත (සමහර විට RDF වචන, මයික්‍රොෆෝමැට් ආදිය) වැනි සම්මත විසඳුම් භාවිතා කිරීමෙන් ඔබට මෙම තත්වයට ළඟා විය හැකිය. පණිවිඩ ශරීරයේ විවිධ කොටස්වල අර්ථ නිරූපණය කරන්න. සේවාදායකයාගෙන් IRI ව්‍යුහය විකේතනය කිරීම සඳහා, ඔබ (HTML, JSON-LD, HAL, ආදිය) වැනි හයිපර්මීඩියා ආකෘතිවල සේවාදායකයින්ට අධි-සබැඳි යැවිය යුතුය. එබැවින් සේවාදායකයෙකුට එහි වර්තමාන ඉලක්කය සපුරා ගැනීම සඳහා යෙදුමේ රාජ්‍ය යන්ත්‍රය නිසි රාජ්‍ය සංක්‍රාන්ති හරහා සැරිසැරීමට අධි-සබැඳිවලට පවරා ඇති පාර-දත්ත (සමහරවිට සම්බන්ධතා සම්බන්ධතා, ආර්ඩීඑෆ් වෝකාබ්) භාවිතා කළ හැකිය.

    උදාහරණයක් ලෙස සේවාදායකයෙකුට වෙබ් සාප්පුවකට ඇණවුමක් යැවීමට අවශ්‍ය වූ විට, එය වෙබ් සාප්පුව විසින් එවන ලද ප්‍රතිචාරවල ඇති අධි සබැඳි පරීක්ෂා කළ යුතුය. සබැඳි පරික්ෂා කිරීමෙන් එය http://schema.org/OrderAction සමඟ විස්තර කර ඇති එකක් සොයා ගනී . සේවාදායකයා schema.org වාග් මාලාව දනී, එබැවින් මෙම අධි-සබැඳිය සක්‍රිය කිරීමෙන් එය ඇණවුම යවන බව තේරුම් ගනී. එබැවින් එය හයිපර්ලින්ක් සක්‍රිය කර POST https://example.com/api/v1/orderනිසි ශරීරය සමඟ පණිවිඩයක් යවයි . ඉන්පසු සේවාව පණිවිඩය සකසන අතර නිසි HTTP තත්ව ශීර්ෂයක් ඇති ප්‍රති result ලයට ප්‍රතිචාර දක්වයි, උදාහරණයක් ලෙස 201 - createdසාර්ථකත්වය. සවිස්තරාත්මක දත්ත සමුදායක් සහිත පණිවිඩ විවරණය කිරීම සඳහා RDF ආකෘතියක් භාවිතා කිරීම සඳහා සම්මත විසඳුම , උදාහරණයක් ලෙස RST වෝබ් එකක් සහිත JSON-LD , උදාහරණයක් ලෙස හයිඩ්‍රා සහ වසම් විශේෂිත වචනschema.org හෝ වෙනත් සම්බන්ධිත දත්ත වෝකාබ් සහ අවශ්‍ය නම් අභිරුචි යෙදුම් විශේෂිත වචන මාලාවක්. දැන් මෙය පහසු නැත, ඒ නිසා බොහෝ ppl සාමාන්‍යයෙන් REST වාග් මාලාවක් පමණක් සපයන HAL සහ වෙනත් සරල ආකෘති භාවිතා කරයි, නමුත් සම්බන්ධිත දත්ත සහාය නොමැත.

  5. පරිමාණය වැඩි කිරීම සඳහා ස්ථර පද්ධතියක් සාදන්න

    REST පද්ධතිය ධූරාවලි ස්ථර වලින් සමන්විත වේ. සෑම ස්ථරයකම ඊළඟ ස්ථරයේ ඇති සංරචකවල සේවාවන් භාවිතා කරන සංරචක අඩංගු වේ. එබැවින් ඔබට නව ස්ථර සහ සංරචක පහසුවෙන් එකතු කළ හැකිය.

    උදාහරණයක් ලෙස සේවාදායකයින් අඩංගු සේවාදායක ස්ථරයක් ඇති අතර ඊට පහළින් තනි සේවාවක් අඩංගු සේවා ස්ථරයක් ඇත. දැන් ඔබට ඔවුන් අතර සේවාදායක පාර්ශවීය හැඹිලියක් එක් කළ හැකිය. ඊට පසු ඔබට වෙනත් සේවා අවස්ථාවක් සහ බර බැලන්සර් එක් කළ හැකිය, සහ එසේ ය ... සේවාදායක කේතය සහ සේවා කේතය වෙනස් නොවේ.

  6. සේවාදායකයාගේ ක්‍රියාකාරිත්වය දීර් extend කිරීම සඳහා ඉල්ලුම මත කේතය

    මෙම අවහිරතාවය අත්‍යවශ්‍ය නොවේ. උදාහරණයක් ලෙස ඔබට සේවාදායකයාට විශේෂිත මාධ්‍ය වර්ගයක් සඳහා විග්‍රහයක් යැවිය හැකිය, සහ එසේ ය ... මෙය සිදු කිරීම සඳහා ඔබට සේවාදායකයා තුළ සම්මත ප්ලගීන පැටවුම් පද්ධතියක් අවශ්‍ය විය හැකිය, නැතහොත් ඔබේ සේවාදායකයා ප්ලගීන පැටවුම් විසඳුමට සම්බන්ධ වේ. .

REST අවහිරතා හේතුවෙන් සේවා පරිමාණයෙන් සේවාදායකයින් විසුරුවා හරිනු ලබන ඉහළ පරිමාණයකින් යුත් පද්ධතියක් ඇතිවේ. එබැවින් වෙබයේ ඇති බ්‍රව්සර් මෙන් සේවාදායකයින්ට නැවත භාවිතා කළ හැකිය. සේවාදායකයින් සහ සේවාවන් එකම ප්‍රමිතීන් සහ වචන හුවමාරු කර ගන්නා අතර එමඟින් සේවාව ක්‍රියාත්මක කිරීමේ තොරතුරු සේවාදායකයා නොදන්නා නමුත් එකිනෙකා තේරුම් ගත හැකිය. මෙමඟින් REST සේවාවන් සොයා ගැනීමට සහ ඔවුන්ගේ අරමුණු සාක්ෂාත් කර ගැනීමට භාවිතා කළ හැකි ස්වයංක්‍රීය සේවාදායකයින් නිර්මාණය කිරීමට හැකි වේ. දිගු කාලීනව මෙම සේවාදායකයින්ට මිනිසුන් මෙන් එකිනෙකා සමඟ සන්නිවේදනය කළ හැකි අතර එකිනෙකා සමඟ කාර්යයන් කෙරෙහි විශ්වාසය තැබිය හැකිය. අපි එවැනි සේවාදායකයින්ට ඉගෙනුම් රටා එකතු කළහොත්, ප්‍රති result ලය වනුයේ තනි සේවාදායක උද්‍යානයක් වෙනුවට යන්ත්‍ර ජාලයක් භාවිතා කරමින් AI එකක් හෝ වැඩි ගණනක් වනු ඇත. ඉතින් අවසානයේ බර්නර්ස් ලීගේ සිහිනය: අර්ථකථන වෙබ් සහ කෘතිම බුද්ධිය යථාර්ථයක් වනු ඇත. ඉතින් 2030 දී අපි ස්කයිනෙට් විසින් අවසන් කරනු ලැබේ. එතෙක් ... ;-)


22

RESTful (නියෝජිත රාජ්‍ය මාරුව) API ක්‍රමලේඛනය යනු මූලික මෘදුකාංග වාස්තු විද්‍යාත්මක ශෛලීය මූලධර්ම 5 ක් අනුගමනය කරමින් ඕනෑම ක්‍රමලේඛන භාෂාවකින් වෙබ් යෙදුම් ලිවීමයි :

  1. සම්පත් (දත්ත, තොරතුරු).
  2. අද්විතීය ගෝලීය හඳුනාගැනීමක් (සියලුම සම්පත් යූආර්අයි විසින් හඳුනාගෙන ඇත ).
  3. ඒකාකාර අතුරුමුහුණත - සරල හා සම්මත අතුරුමුහුණතක් (HTTP) භාවිතා කරන්න.
  4. නිරූපණය - සියලුම සන්නිවේදනයන් නිරූපණය මගින් සිදු කෙරේ (උදා: XML / JSON )
  5. අස්ථායි (සෑම ඉල්ලීමක්ම සම්පූර්ණ හුදකලාවකින් සිදු වේ, හැඹිලි සහ පැටවුම් ශේෂය පහසුය),

වෙනත් වචන වලින් කිවහොත්, ඔබ එක් එක් “සම්පත” නිරාවරණය කරන අතුරු මුහුණතේ ප්‍රමිතිකරණය යෝජනා කරන RESTful ගෘහ නිර්මාණ ශිල්පය ක්‍රියාත්මක කිරීමෙන් GET, POST, PUT හෝ DELETE වැනි ක්‍රියා පද භාවිතා කරන HTTP හරහා සරල ලක්ෂ්‍ය ජාල යෙදුම් ලියයි. වෙබයේ වර්තමාන අංග සරල හා way ලදායී ආකාරයකින් භාවිතා කිරීම (ඉහළ සාර්ථක, ඔප්පු කළ සහ බෙදා හරින ලද ගෘහ නිර්මාණ ශිල්පය) කිසිවක් නොවේ. එය SOAP , CORBA සහ RPC වැනි වඩාත් සංකීර්ණ යාන්ත්‍රණ සඳහා විකල්පයකි .

RESTful ක්‍රමලේඛනය වෙබ් ගෘහ නිර්මාණ සැලැස්මට අනුකූල වන අතර, නිසි ලෙස ක්‍රියාත්මක කරන්නේ නම්, පරිමාණ කළ හැකි වෙබ් යටිතල ව්‍යුහයේ පූර්ණ වාසිය ලබා ගැනීමට එය ඔබට ඉඩ සලසයි.


17

REST හි මුල් නිබන්ධනය කෙටි වාක්‍ය 3 ක් දක්වා අඩු කිරීමට මට සිදු වූයේ නම්, පහත දැක්වෙන්නේ එහි සාරය ග්‍රහණය කර ගැනීමයි:

  1. URL හරහා සම්පත් ඉල්ලනු ලැබේ.
  2. URL භාවිතා කිරීමෙන් ඔබට සන්නිවේදනය කළ හැකි දේට ප්‍රොටෝකෝල සීමා වේ.
  3. පාර-දත්ත නාම-වටිනා යුගල ලෙස (පසු දත්ත සහ විමසුම් නූල් පරාමිතීන්) ලෙස සම්මත කර ඇත.

ඊට පසු, අනුවර්තනයන්, කේතීකරණ සම්මුතීන් සහ හොඳම භාවිතයන් පිළිබඳ විවාදවලට වැටීම පහසුය.

සිත්ගන්නා කරුණ නම්, නිබන්ධනයේ HTTP POST, GET, DELETE, හෝ PUT මෙහෙයුම් ගැන සඳහනක් නොමැත. එය “ඒකාකාර අතුරුමුහුණතක්” සඳහා “හොඳම පුහුණුව” පිළිබඳ යමෙකුගේ පසුකාලීන අර්ථ නිරූපණය විය යුතුය.

වෙබ් සේවා සම්බන්ධයෙන් ගත් කල, අපට WSDL සහ SOAP මත පදනම් වූ ගෘහ නිර්මාණ වෙන්කර හඳුනා ගැනීමට යම් ක්‍රමයක් අවශ්‍ය බව පෙනේ. ක්‍රියාත්මක කිරීම සඳහා අමතර රාමු සහ සංවර්ධක මෙවලම් ද ඔවුන්ට අවශ්‍ය වේ. සාමාන්‍ය බුද්ධි අතුරුමුහුණත් සහ WSDL සහ SOAP වැනි ඕනෑවට වඩා සැලසුම් කළ අතුරුමුහුණත් අතර වෙනස හඳුනා ගැනීමට REST හොඳම යෙදුමදැයි මට විශ්වාස නැත. නමුත් අපට යමක් අවශ්‍යයි.


17

REST යනු වාස්තු විද්‍යාත්මක රටාවක් සහ බෙදා හරින ලද යෙදුම් ලිවීමේ ශෛලියකි. එය පටු අර්ථයෙන් වැඩසටහන්කරණ ශෛලියක් නොවේ.

ඔබ REST ශෛලිය භාවිතා කරන බව පැවසීම ඔබ විශේෂිත ශෛලියකින් නිවසක් ඉදිකර ඇති බව පැවසීමට සමානය: උදාහරණයක් ලෙස ටියුඩර් හෝ වික්ටෝරියානු. මෘදුකාංග ශෛලියක් ලෙස REST සහ ගෘහ ශෛලියක් ලෙස ටියුඩර් හෝ වික්ටෝරියානු යන දෙකම අර්ථ දැක්විය හැක්කේ ඒවා සෑදෙන ගුණාංග සහ අවහිරතා මගිනි. උදාහරණයක් ලෙස REST හි සේවාදායකයන් වෙන් කිරීම තිබිය යුතුය, එහිදී පණිවිඩ ස්වයං විස්තර කරයි. ටියුඩර් විලාසිතාවේ නිවෙස්වල අතිච්ඡාදනය වන ගේබල් සහ වහලවල් ඇති අතර ඒවා ඉදිරිපස මුහුණත සහිත ගේබල් වලින් තදින් සවි කර ඇත. REST හි ඇති අවහිරතා සහ ගුණාංග පිළිබඳ වැඩිදුර දැන ගැනීම සඳහා ඔබට රෝයිගේ නිබන්ධනය කියවිය හැකිය.

ගෘහ ශෛලීන් මෙන් නොව REST නිරන්තරයෙන් හා ප්‍රායෝගිකව යෙදීමට දුෂ්කර කාලයක් තිබේ. මෙය හිතාමතාම සිදු වන්නට ඇත. එහි සැබෑ ක්‍රියාත්මක කිරීම නිර්මාණකරුට භාර දීම. එබැවින් ඔබ REST පද්ධති නිර්මාණය කරන නිබන්ධනයේ දක්වා ඇති බාධක සපුරාලන තාක් කල් ඔබට අවශ්‍ය දේ කිරීමට ඔබට නිදහස තිබේ.

පාරිතෝෂිකය:

මුළු වෙබ් අඩවියම REST මත පදනම් වේ (හෝ REST පදනම් වූයේ වෙබය මතය). එබැවින් වෙබ් සංවර්ධකයෙකු ලෙස ඔබට හොඳ වෙබ් යෙදුම් ලිවීමට අවශ්‍ය නොවුවද ඒ පිළිබඳව දැනුවත් වීමට අවශ්‍ය වනු ඇත.


17

මෙන්න මගේ REST හි මූලික දළ සටහන. RESTful ගෘහ නිර්මාණ ශිල්පය තුළ එක් එක් සංරචක පිටුපස ඇති චින්තනය නිරූපණය කිරීමට මම උත්සාහ කළෙමි. සමහර පුද්ගලයින් සඳහා REST අවලංගු කිරීමට මෙය උපකාරී වේ යැයි සිතමු!

REST (නියෝජිත රාජ්‍ය මාරුව) යනු ජාලගත සම්පත් (එනම් තොරතුරු බෙදාගන්නා නෝඩ්) නිර්මාණය කර ආමන්ත්‍රණය කරන ආකාරය දැක්වෙන සැලසුම් ගෘහ නිර්මාණ ශිල්පයකි. පොදුවේ ගත් කල, RESTful ගෘහ නිර්මාණ ශිල්පය මඟින් සේවාදායකයාට (ඉල්ලුම් කරන යන්ත්‍රයට) සහ සේවාදායකයාට (ප්‍රතිචාර දක්වන යන්ත්‍රයට) සේවාදායකයා ක්‍රියාකරන ආකාරය සහ සේවාදායකයාට සමත් විය හැකි ආකාරය නොදැන සේවාදායකයාට දත්ත කියවීමට, ලිවීමට හා යාවත්කාලීන කිරීමට ඉල්ලුම් කළ හැකිය. සේවාදායකයා ගැන කිසිවක් දැන ගැනීමට අවශ්‍ය නොවී එය ආපසු ලබා දේ. හරි, නියමයි ... නමුත් අපි මෙය ප්‍රායෝගිකව කරන්නේ කෙසේද?

  • වඩාත්ම පැහැදිලිව පෙනෙන අවශ්‍යතාවය නම්, යම් ආකාරයක විශ්වීය භාෂාවක් තිබිය යුතු වන අතර එමඟින් සේවාදායකයාට ඉල්ලීම සමඟ කුමක් කිරීමට උත්සාහ කරනවාද යන්න සේවාදායකයාට පැවසිය හැකි අතර සේවාදායකයාට ප්‍රතිචාර දැක්විය හැකිය.

  • නමුත් කිසියම් සම්පතක් සොයා ගෙන එම සම්පත් ජීවත්වන ස්ථානය සේවාදායකයාට පැවසීමට නම්, සම්පත් වෙත යොමු වීමේ විශ්වීය ක්‍රමයක් තිබිය යුතුය. විශ්ව සම්පත් හඳුනාගැනීම් (යූආර්අයි) පැමිණෙන්නේ මෙහිදීය; ඒවා මූලික වශයෙන් සම්පත් සෙවීම සඳහා අද්විතීය ලිපින වේ.

නමුත් REST ගෘහ නිර්මාණ ශිල්පය එතැනින් අවසන් නොවේ! ඉහත සඳහන් කරුණු අපට අවශ්‍ය දේවල මූලික අවශ්‍යතා සපුරාලන අතර, ඕනෑම සේවාදායකයක් සාමාන්‍යයෙන් ගනුදෙනුකරුවන් ගණනාවකගේ ප්‍රතිචාර හසුරුවන බැවින් ඉහළ ධාරිතාවයකින් යුත් ගමනාගමනයට සහාය වන ගෘහ නිර්මාණ ශිල්පයක් අපට අවශ්‍යය. මේ අනුව, පෙර ඉල්ලීම් පිළිබඳ තොරතුරු මතක තබා ගැනීමෙන් සේවාදායකය යටපත් කිරීමට අපට අවශ්‍ය නැත.

  • එම නිසා, සේවාදායකයා සහ සේවාදායකයා අතර ඇති සෑම ඉල්ලීම්-ප්‍රතිචාර යුගලයක්ම ස්වාධීන බව අපි පනවා ඇත, එයින් අදහස් කරන්නේ නවයකට ප්‍රතිචාර දැක්වීම සඳහා සේවාදායකයාට පෙර ඉල්ලීම් (සේවාදායක-සේවාදායක අන්තර්ක්‍රියාකාරිත්වයේ පෙර තත්වයන්) ගැන කිසිවක් මතක තබා ගත යුතු නැති බවයි. ඉල්ලීම. මෙයින් අදහස් කරන්නේ අපගේ අන්තර්ක්‍රියා අස්ථායි වීමට අපට අවශ්‍ය බවයි.

  • දී ඇති සේවාදායකයකු සඳහා දැනටමත් සිදු කර ඇති ගණනය කිරීම් නැවත සිදු කිරීමෙන් අපගේ සේවාදායකයේ ඇති වන පීඩනය තවදුරටත් ලිහිල් කිරීම සඳහා, REST ද හැඹිලිගත කිරීමට ඉඩ දෙයි. මූලික වශයෙන්, හැඹිලි කිරීම යනු සේවාදායකයාට ලබා දී ඇති ආරම්භක ප්‍රතිචාරයේ කෙටි සටහනක් ගැනීමයි. සේවාදායකයා නැවත එම ඉල්ලීමම කරන්නේ නම්, ආරම්භක ප්‍රතිචාරය නිර්මාණය කිරීමට අවශ්‍ය සියලු ගණනය කිරීම් නැවත සිදු කරනවාට වඩා සේවාදායකයාට සේවාදායකයාට ස්නැප්ෂොට් ලබා දිය හැකිය. කෙසේ වෙතත්, එය සැණින් ඡායාරූපයක් බැවින්, සැණෙළිය කල් ඉකුත්වී නොමැති නම් - සේවාදායකයා කල් ඉකුත් වීමේ වේලාව කල්තියා නියම කරයි - සහ ආරම්භක හැඹිලියේ සිට ප්‍රතිචාරය යාවත්කාලීන කර ඇත (එනම් ඉල්ලීම හැඹිලි ප්‍රතිචාරයට වඩා වෙනස් පිළිතුරක් ලබා දෙනු ඇත) , හැඹිලිය කල් ඉකුත් වන තුරු (හෝ හැඹිලිය නිෂ්කාශනය වන තෙක්) සේවාදායකයාට යාවත්කාලීනයන් නොපෙනේ.

  • RESTful ගෘහ නිර්මාණ ශිල්පය පිළිබඳව ඔබ බොහෝ විට මෙහි එන අවසාන දෙය නම් ඒවා ස්ථර කර තිබීමයි. සේවාදායකයා සහ සේවාදායකයා අතර අන්තර්ක්‍රියා පිළිබඳ අපගේ සාකච්ඡාවේදී අපි ඇත්ත වශයෙන්ම දැනටමත් මෙම අවශ්‍යතාවය ව්‍යංගයෙන් සාකච්ඡා කර ඇත්තෙමු. මූලික වශයෙන්, මෙයින් අදහස් කරන්නේ අපගේ පද්ධතියේ සෑම ස්ථරයක්ම අන්තර්ක්‍රියා කරන්නේ යාබද ස්ථර සමඟ පමණක් බවයි. එබැවින් අපගේ සාකච්ඡාවේදී, සේවාදායක ස්ථරය අපගේ සේවාදායක ස්තරය සමඟ අන්තර්ක්‍රියා කරයි (සහ අනෙක් අතට), නමුත් සේවාදායකයා directly ජුව සන්නිවේදනය නොකරන ඉල්ලීමක් ප්‍රාථමික සේවාදායකයට සැකසීමට උපකාර වන වෙනත් සේවාදායක ස්ථර තිබිය හැකිය. ඒ වෙනුවට, සේවාදායකයා අවශ්‍ය පරිදි ඉල්ලීම ඉටු කරයි.

දැන්, මේ සියල්ල හුරුපුරුදු නම්, නියමයි. ලෝක ව්‍යාප්ත වෙබ් හරහා සන්නිවේදන ප්‍රොටෝකෝලය නිර්වචනය කරන හයිපර්ටෙක්ස්ට් ට්‍රාන්ස්ෆර් ප්‍රොටොකෝලය (HTTP) යනු RESTful ගෘහ නිර්මාණ ශිල්පයේ වියුක්ත සංකල්පය ක්‍රියාත්මක කිරීමකි (හෝ ඔබ මා වැනි OOP රසිකයෙක් නම් REST පන්තියේ උදාහරණයක්). REST ක්‍රියාවට නැංවීමේදී, සේවාදායකයා සහ සේවාදායකයා විශ්ව භාෂාවේ කොටසක් වන GET, POST, PUT, DELETE යනාදිය හරහා අන්තර්ක්‍රියා කරයි. සම්පත් URL භාවිතා කිරීම වෙත යොමු කළ හැකිය.


15

මම සිතන්නේ විවේකයෙන් ගත යුතු කාරණය නම්, අන්තර්ජාලය (ප්‍රොටෝකෝලය) අස්ථායි ප්‍රවාහන ස්ථරයක් ලෙස භාවිතා කරන අතරම , රාජ්‍ය ස්ථරතාව ඉහළ තට්ටුවකට වෙන් කිරීමයි . වෙනත් බොහෝ ප්‍රවේශයන් දේවල් මිශ්‍ර කරයි.

අන්තර්ජාල යුගයේ වැඩසටහන්කරණයේ මූලික වෙනස්කම් හැසිරවීමට හොඳම ප්‍රායෝගික ප්‍රවේශය එයයි. මූලික වෙනස්කම් සම්බන්ධයෙන්, එරික් මෙයිජර් මෙහි ප්‍රදර්ශනය පිළිබඳ සාකච්ඡාවක් ඇත: http://www.infoq.com/interviews/erik-meijer-programming-language-design-effects-purity#view_93197 . ඔහු එය බලපෑම් පහක් ලෙස සාරාංශ කරන අතර විසඳුම ක්‍රමලේඛන භාෂාවකට සැලසුම් කිරීමෙන් විසඳුමක් ඉදිරිපත් කරයි. භාෂාව නොසලකා වේදිකාව හෝ පද්ධති මට්ටමින් ද විසඳුම ලබා ගත හැකිය. වර්තමාන භාවිතයේ ඉතා සාර්ථක වී ඇති එක් විසඳුමක් ලෙස විවේකය දැකිය හැකිය.

විවේකී ශෛලිය සමඟ, ඔබ විශ්වාස කළ නොහැකි අන්තර්ජාලයක් හරහා යෙදුමේ තත්වය ලබා ගනී. නිවැරදි හා වත්මන් තත්වය ලබා ගැනීම සඳහා එය වත්මන් මෙහෙයුම අසමත් වුවහොත්, යෙදුම දිගටම කරගෙන යාමට එය ශුන්‍ය-වලංගු කිරීමේ විදුහල්පති අවශ්‍ය වේ. එය රාජ්‍යය හැසිරවීමට අපොහොසත් වුවහොත්, එය සාමාන්‍යයෙන් කරුණු නිවැරදිව තබා ගැනීම සඳහා තහවුරු කිරීමේ අදියර කිහිපයක් භාවිතා කරයි. මේ අර්ථයෙන් ගත් කල, විවේකය යනු සම්පූර්ණ විසඳුමක් නොවේ, එහි ක්‍රියාකාරීත්වයට සහාය වීම සඳහා වෙබ් යෙදුම් තොගයේ අනෙක් කොටසෙහි කාර්යයන් අවශ්‍ය වේ.

මෙම දෘෂ්ටි කෝණයෙන් බලන විට, ඉතිරි ශෛලිය ඇත්ත වශයෙන්ම අන්තර්ජාලය හෝ වෙබ් යෙදුම සමඟ බැඳී නොමැත. බොහෝ වැඩසටහන්කරණ අවස්ථාවන්ට එය මූලික විසඳුමකි. එය සරල නැත, එය අතුරු මුහුණත සැබවින්ම සරල කරයි, සහ වෙනත් තාක්ෂණයන් සමඟ විස්මය දනවන අයුරින් කටයුතු කරයි.

මගේ 2 සී.

සංස්කරණය කරන්න: තවත් වැදගත් අංශ දෙකක්:


1
MVC මතයක්: මෙම බ්ලොග් රෙස්ට් නරකම පිළිවෙත් නොකරන යෝජනා ආකෘති හා සම්පත් ගොඩට දැමීමක් ද . පොත දෙකක් ෙයොත් django ක විවේක API මතය වන අතර, දැක්ම ව්යාපාර තර්කනය මිශ්ර කිරීමට නොහැකි බවයි. යෙදුම සඳහා කේතය යෙදුම තුළ පැවතිය යුතුය.
minghua

1
තවත් හොඳ ලිපියක්: සම්පත්
නැඹුරු

14

මෙය පුදුම සහගත ලෙස දිගු "සාකච්ඡාවක්" වන අතර අවම වශයෙන් පැවසීම තරමක් ව්‍යාකූල ය.

IMO:

1) විශාල සන්ධියක් සහ බියර් ගොඩක් නොමැතිව, විවේකී වැඩසටහන්කරණය වැනි දෙයක් නොමැත :)

2) නියෝජිත රාජ්‍ය මාරුව (REST) ​​යනු රෝයි ෆීල්ඩින්ගේ නිබන්ධනයේ දක්වා ඇති වාස්තු විද්‍යාත්මක ශෛලියකි . එයට අවහිරතා ගණනාවක් තිබේ. ඔබේ සේවාව / සේවාදායකයා ඒවාට ගරු කරන්නේ නම් එය වඩාත් සුදුසුය. මේ එයයි.

ඔබට ඇති සීමාවන් සාරාංශගත කළ හැකිය (සැලකිය යුතු ලෙස):

  • අස්ථායි සන්නිවේදනය
  • HTTP පිරිවිතරයන්ට ගරු කරන්න (HTTP භාවිතා කරන්නේ නම්)
  • සම්ප්‍රේෂණය කළ අන්තර්ගත ආකෘති පැහැදිලිව සන්නිවේදනය කරයි
  • යෙදුම් තත්වයේ එන්ජිම ලෙස හයිපර්මීඩියා භාවිතා කරන්න

කාරණා මනාව පැහැදිලි කරන තවත් හොඳ පෝස්ට් එකක් තිබේ.

බොහෝ පිළිතුරු පිටපත් / අලවන ලද වලංගු තොරතුරු එය මිශ්‍ර කර යම් ව්‍යාකූලත්වයක් එක් කරයි. මිනිසුන් මෙහි මට්ටම් ගැන කතා කරයි, RESTFul URIs ගැන (එවැනි දෙයක් නැත!), HTTP ක්‍රම යොදන්න GET, POST, PUT ... REST යනු ඒ ගැන හෝ ඒ ගැන පමණක් නොවේ.

උදාහරණයක් ලෙස සබැඳි - ලස්සන පෙනුමක් ඇති ඒපීඅයි එකක් තිබීම සතුටක් නමුත් අවසානයේ සේවාදායකයා / සේවාදායකයා ඔබට ලැබෙන / යවන සබැඳි ගැන සැබවින්ම සැලකිල්ලක් නොදක්වයි.

අවසානයේ දී ඕනෑම RESTful සේවාදායකයෙකුට අන්තර්ගත ආකෘතිය දන්නා තාක් කල් ඕනෑම RESTful සේවාවක් සඳහා පරිභෝජනය කළ හැකිය.


14

පැරණි ප්‍රශ්නය, පිළිතුරු දීමට නව ක්‍රමයක්. මෙම සංකල්පය පිළිබඳ වැරදි වැටහීමක් තිබේ. මම සැමවිටම මතක තබා ගැනීමට උත්සාහ කරමි:

  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 මට්ටම) හෝ ඔබ නොවේ, නමුත් මම ඒ ගැන හ call නැගීමට කැමති දේ එක් එක් මට්ටම RESTful වෙත යන ගමනේදී ඔබ වෙනුවෙන්

විවරණය කළ රිචඩ්සන් පරිණත ආකෘතිය


12

ඕනෑම වෙබ් සේවාවක් කරන වාස්තු විද්‍යාත්මක බාධක 6 ක් REST අර්ථ දක්වයි - සැබෑ RESTful API .

  1. ඒකාකාර අතුරුමුහුණත
  2. සේවාලාභී සේවාදායකයා
  3. අස්ථායි
  4. හැඹිලි කළ හැකි
  5. ස්ථර පද්ධතිය
  6. ඉල්ලුම මත කේතය (අත්‍යවශ්‍ය නොවේ)

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


ෆීල්ඩින් විසින් තවත් නීති කිහිපයක් එකතු කරන ලදි RESTful API / සේවාදායකයින්ට පිළිපැදිය යුතුය
රෝමන් වොට්නර්

11

REST === HTTP ප්‍රතිසමයන් නිවැරදි නොවන අතර එය " HATEOAS ධාවනය කළ යුතුය" යන කාරණය අවධාරණය නොකරයි .

රෝයි විසින්ම එය මෙහි ඉවත් කර ඇත .

ආරම්භක යූආර්අයි (පිටු සලකුණ) සහ අපේක්ෂිත ප්‍රේක්ෂකයින් සඳහා සුදුසු ප්‍රමිතිගත මාධ්‍ය වර්ග සමූහයක් (එනම්, ඒපීඅයි භාවිතා කරන ඕනෑම සේවාදායකයෙකු විසින් තේරුම් ගනු ඇතැයි අපේක්ෂා කෙරේ) ඉක්මවා පූර්ව දැනුමක් නොමැතිව REST API එකක් ඇතුළත් කළ යුතුය. එතැන් සිට, සියලුම යෙදුම් තත්ව සංක්‍රාන්තිය මෙහෙයවනු ලබන්නේ ලැබුනු නිරූපණයන්හි ඇති සේවාදායකයා විසින් සපයනු ලබන තේරීම් සේවාදායකයින් විසින් තෝරා ගැනීම හෝ එම නිරූපණයන් පරිශීලකයා විසින් මෙහෙයවීම මගින් ගම්‍ය වේ. සංක්‍රාන්තිය තීරණය කළ හැකිය (හෝ සීමා කර ඇත) සේවාදායකයාගේ මාධ්‍ය වර්ග සහ සම්පත් සන්නිවේදන යාන්ත්‍රණයන් පිළිබඳ දැනුම, ඒවා දෙකම පියාසර කරන විට වැඩිදියුණු කළ හැකිය (උදා: ඉල්ලුමට අනුව කේතය).

[මෙහි අසමත් වීමෙන් ඇඟවෙන්නේ කලාපයෙන් පිටත තොරතුරු හයිපර් ටෙක්ස්ට් වෙනුවට අන්තර්ක්‍රියාකාරිත්වයට හේතු වන බවයි.]


අනෙක් අයට මෙන් ප්‍රශ්නයට පිළිතුරු සපයන්නේ නැත, නමුත් අදාළ තොරතුරු සඳහා +1!
CybeX

මම හිතන්නේ මෙය ප්‍රශ්නයට ද පිළිතුරු සපයයි, නමුත් නිදසුනක් ලෙස අස්ථායිතාව එයින් මග හැරී ඇත. සෑම අවහිරයක්ම වැදගත් වේ ... සම්මත මාධ්‍ය වර්ගයේ කොටස සැමවිටම සත්‍ය නොවේ. මම කිව්වේ අවබෝධයේ ස්ථර තියෙනවා. උදාහරණයක් ලෙස ඔබ RDF භාවිතා කරන්නේ නම්, මාධ්‍ය වර්ගය තේරුම් ගත හැකි නමුත් අන්තර්ගතයේ තේරුම එසේ නොවේ. එබැවින් සේවාදායකයාට වචන මාලාව ද දැනගත යුතුය. සමහර අය මේ ආකාරයේ REST API සහ අධි-සබැඳි විස්තර කිරීම සඳහා සාමාන්‍ය REST වචන මාලාවක් අත්හදා බලමින් සිටිති. Hydra-cg.com
inf3rno

11

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 නව සම්පතක් නිර්මාණය කරයි. එය ද පරමාදර්ශී විය යුතුය.
  • DELETE සම්පත් ඉවත් කරයි. මෙහෙයුම් අනර් are ය. විවිධ ප්‍රති .ල ලබා නොගෙන ඒවා නැවත නැවත ලබා ගත හැකිය.
  • POST පවත්නා සම්පතක් යාවත්කාලීන කිරීම හෝ නව සම්පතක් නිර්මාණය කිරීම.

උපුටා දැක්වීම් කිහිපයක්, නමුත් එක මූලාශ්‍රයක්වත් සඳහන් කර නැත. ඔබට මෙය ලැබුනේ කොහෙන්ද?
djvg

10

REST යනු නියෝජිත රාජ්‍ය මාරුවයි .

එය අස්ථායි, සේවාදායක-සේවාදායක, හැඹිලි කළ හැකි සන්නිවේදන ප්‍රොටෝකෝලයක් මත රඳා පවතී - සහ සෑම අවස්ථාවකම පාහේ HTTP ප්‍රොටෝකෝලය භාවිතා කරයි.

REST බොහෝ විට ජංගම යෙදුම්, සමාජ ජාල වෙබ් අඩවි, මාෂප් මෙවලම් සහ ස්වයංක්‍රීය ව්‍යාපාර ක්‍රියාවලීන්හි භාවිතා වේ. සීමිත මෙහෙයුම් සංඛ්‍යාවක් (ක්‍රියා පද) තිබීමෙන් සේවාදායකයින් සහ සේවාවන් අතර අන්තර්ක්‍රියා වැඩි දියුණු වන බව REST විලාසය අවධාරණය කරයි. නම්‍යශීලිත්වය සපයනු ලබන්නේ සම්පත් (නාම පද) ඔවුන්ගේම අද්විතීය විශ්ව සම්පත් දර්ශක (යූආර්අයි) පැවරීමෙනි.

විවේකය පිළිබඳ හැඳින්වීම


10

කතා කිරීම යනු හුදෙක් තොරතුරු හුවමාරු කර ගැනීමට වඩා වැඩි ය . ප්‍රොටෝකෝලයක් සැබවින්ම නිර්මාණය කර ඇත්තේ කිසිදු කතා කිරීමක් සිදු නොවන පරිදි ය. සෑම පාර්ශවයක්ම ඔවුන්ගේ විශේෂිත රැකියාව කුමක්දැයි දන්නේ එය ප්‍රොටෝකෝලයෙහි දක්වා ඇති බැවිනි. හැකි ක්‍රියාමාර්ගවල යම් වෙනසක් සිදුකිරීමේ වියදමින් පිරිසිදු තොරතුරු හුවමාරුව සඳහා ප්‍රොටෝකෝල මඟින් ඉඩ ලබා දේ. අනෙක් අතට, කතා කිරීම, එක් පාර්ශ්වයකට අනෙක් පාර්ශවයෙන් ගත හැකි ඉදිරි ක්‍රියාමාර්ග මොනවාදැයි විමසීමට ඉඩ දෙයි. අනෙක් පාර්ශවයේ තත්වය අන්තර්වාරයේදී වෙනස් වී ඇති බැවින් ඔවුන්ට එකම ප්‍රශ්නය දෙවරක් ඇසීමට හා වෙනස් පිළිතුරු දෙකක් ලබා ගත හැකිය. කතා කිරීම යනු RESTful ගෘහ නිර්මාණ ශිල්පයයි . ෆීල්ඩින්ගේ නිබන්ධනය මඟින් ගෘහ නිර්මාණ ශිල්පය නියම කරනුයේ යමෙකුට යන්තම් එකිනෙකා සමඟ කථා කිරීමට ඉඩ දීමට අවශ්‍ය නම් යමෙකු අනුගමනය කළ යුතු බවයි.සන්නිවේදනය කරන්න .


10

"RESTful වැඩසටහන්කරණය" වැනි අදහසක් නොමැත. එය වඩා හොඳ RESTful පැරඩිගම් හෝ ඊටත් වඩා හොඳ RESTful ගෘහ නිර්මාණ ශිල්පය ලෙස හැඳින්වේ. එය ක්‍රමලේඛන භාෂාවක් නොවේ. එය ආදර්ශයකි.

විකිපීඩියාවෙන් :

පරිගණනයේදී, නියෝජන රාජ්‍ය හුවමාරුව (REST) ​​යනු වෙබ් සංවර්ධනය සඳහා භාවිතා කරන වාස්තු විද්‍යාත්මක ශෛලියකි.


9

විවේක ගැනීමේ කාරණය නම්, මූලික මෙහෙයුම් සඳහා (http ක්‍රියාපද) පොදු භාෂාවක් භාවිතා කිරීමට අප එකඟ වන්නේ නම්, යටිතල ව්‍යුහය ඒවා තේරුම් ගැනීමට සහ ඒවා නිසි ලෙස ප්‍රශස්ත කිරීමට වින්‍යාසගත කළ හැකිය, නිදසුනක් ලෙස, හැඹිලි ක්‍රියාත්මක කිරීම සඳහා හැඹිලි ශීර්ෂ භාවිතා කිරීමෙන් මට්ටම්.

නිසියාකාරව ක්‍රියාත්මක කරන ලද විවේක GET මෙහෙයුමක් සමඟ, ඔබේ සේවාදායකයේ ඩීබී, ඔබේ සේවාදායකයේ මතක සටහන්, සීඩීඑන්, ප්‍රොක්සි හැඹිලිය, බ්‍රව්සරයේ හැඹිලිය හෝ බ්‍රව්සරයේ දේශීය ගබඩාවෙන් තොරතුරු ලැබෙන්නේ නම් එය වැදගත් නොවේ. නිරාහාරව ඇති, වඩාත්ම පහසුවෙන් ලබා ගත හැකි යාවත්කාලීන ප්‍රභවය භාවිතා කළ හැකිය.

විවේකය යනු ක්‍රියාකාරී පරාමිතියක් සහිත GET ඉල්ලීම් භාවිතා කිරීමෙන් ලබා ගත හැකි http ක්‍රියාපද භාවිතා කිරීම සඳහා වූ සින්ටැක්ටික් වෙනසක් පමණක් බව පැවසීමෙන් එයින් කිසිදු ප්‍රතිලාභයක් නොමැති අතර එය තනිකරම රූපලාවණ්‍ය වේ. කාරණය වන්නේ දාමයේ සෑම කොටසකටම තේරුම් ගත හැකි හා ප්‍රශස්ත කළ හැකි භාෂාවක් භාවිතා කිරීමයි. ඔබගේ GET මෙහෙයුමට අතුරු ආබාධ සහිත ක්‍රියාවක් තිබේ නම්, ඔබට සියලු HTTP හැඹිලි මඟ හැරිය යුතුය, නැතහොත් ඔබ නොගැලපෙන ප්‍රති .ල සමඟ අවසන් වනු ඇත.


5
"විවේකය යනු සින්ටැක්ටික් වෙනසක් පමණක් යැයි පැවසීම ... එයින් කිසිදු ප්‍රතිලාභයක් නැති බවත් එය තනිකරම රූපලාවණ්‍යයක් බවත් පෙනේ" --- ඒ නිසාම මම SO හි පිළිතුරු කියවන්නේ එබැවිනි. REST තනිකරම රූපලාවණ්‍ය නොවන්නේ මන්දැයි ඔබ පැහැදිලි නොකළ බව සලකන්න.
osa

5

API පරීක්ෂණ යනු කුමක්ද?

API පරීක්ෂාව මඟින් API වෙත ඇමතුම් යැවීමට සහ අස්වැන්න ලබා ගැනීමට ක්‍රමලේඛනය භාවිතා කරයි. එය පරීක්ෂණයට භාජනය වන කොටස කළු පෙට්ටියක් ලෙස සලකයි. ඒපීඅයි පරීක්ෂණයේ පරමාර්ථය වන්නේ යෙදුමක් සම්බන්ධීකරණය කිරීමට පෙර කොටස නිවැරදිව ක්‍රියාත්මක කිරීම සහ වැරදි ලෙස සැලකීම තහවුරු කිරීමයි.

REST API

REST: නියෝජිත රාජ්‍ය මාරුව.

  • එය පරීක්ෂකයින් විසින් ඉල්ලීම් ඉටු කරන සහ ප්‍රතිචාර ලැබෙන කාර්යයන් වල විධිවිධානයකි. REST API අන්තර්ක්‍රියා HTTP ප්‍රොටෝකෝලය හරහා සිදු කෙරේ.
  • ජාලයක් හරහා එකිනෙකා සමඟ පරිගණක සන්නිවේදනය කිරීමට REST අවසර දෙයි.
  • පණිවිඩ යැවීම සහ ලැබීම සඳහා, එයට HTTP ක්‍රම භාවිතා කිරීම ඇතුළත් වන අතර, වෙබ් සේවා මෙන් නොව, දැඩි පණිවිඩ අර්ථ දැක්වීමක් අවශ්‍ය නොවේ.
  • REST පණිවිඩ බොහෝ විට XML ස්වරූපයෙන් හෝ ජාවාස්ක්‍රිප්ට් වස්තු අංකනය (JSON) ආකාරයෙන් පිළිගනී.

බහුලව භාවිතා වන API ක්‍රම: -

  1. ලබා ගන්න: - එය සම්පතක් සඳහා කියවීමට පමණක් ප්‍රවේශය සපයයි.
  2. සටහන: - එය නව සම්පතක් නිර්මාණය කිරීමට හෝ යාවත්කාලීන කිරීමට භාවිතා කරයි.
  3. PUT: - එය දැනට පවතින සම්පතක් යාවත්කාලීන කිරීමට හෝ ප්‍රතිස්ථාපනය කිරීමට හෝ නව සම්පතක් නිර්මාණය කිරීමට භාවිතා කරයි.
  4. මකන්න: - එය සම්පතක් ඉවත් කිරීමට භාවිතා කරයි.

API අතින් පරීක්ෂා කිරීමට පියවර: -

API අතින් භාවිතා කිරීමට, අපට බ්‍රව්සරය පදනම් කරගත් REST API ප්ලගීන භාවිතා කළ හැකිය.

  1. POSTMAN (Chrome) / REST (Firefox) ප්ලගිනය ස්ථාපනය කරන්න
  2. API URL ඇතුලත් කරන්න
  3. REST ක්‍රමය තෝරන්න
  4. අන්තර්ගත-ශීර්ෂකය තෝරන්න
  5. ඉල්ලීම JSON (POST) ඇතුළත් කරන්න
  6. යැවීම මත ක්ලික් කරන්න
  7. එය ප්‍රතිදාන ප්‍රතිචාරය ලබා දෙනු ඇත

REST API ස්වයංක්‍රීය කිරීමට පියවර


5
මෙය නිසි පිළිතුරක් පවා නැති
therealprashant

5

මෙය සෑම තැනකම සඳහන් කර ඇත්තේ ඉතා අල්ප වශයෙනි. නමුත් රිචඩ්සන්ගේ පරිණත ආකෘතිය යනු කෙනෙකුගේ ඒපීඅයි යනු කෙතරම් විවේකද යන්න සැබවින්ම විනිශ්චය කිරීමට හොඳම ක්‍රමයකි. ඒ ගැන වැඩි විස්තර මෙතැනින්:

රිචඩ්සන්ගේ පරිණත ආකෘතිය


ෆීල්ඩින් විසින් REST හි ඇති බාධක දෙස බැලුවහොත් ඔබට පැහැදිලිව පෙනෙනුයේ RESTF ලෙස බැලීම සඳහා API එකක් RMM හි 3 වන ස්ථරයට ළඟා විය යුතු බවයි, නමුත් මෙය හුදෙක් ප්‍රමාණවත් නොවන නමුත් අසමත් වීමට තවමත් ප්‍රමාණවත් හැකියාවන් පවතින බැවින් REST අදහස - සේවාදායක API වලින් සේවාදායකයින් විසන්ධි කිරීම. නිසැකවම, 3 වන ස්ථරය HATEOAS අවහිරතා සපුරාලන නමුත් අවශ්‍යතා කඩ කිරීම සහ සේවාදායකයින් වෙත සේවාදායකයින් තදින් බැඳීම තවමත් පහසුය (එනම් ටයිප් කළ සම්පත් භාවිතා කිරීමෙන්)
රෝමන් වොට්නර්

2

REST අවබෝධ කර ගැනීමේ වැදගත් ගොඩනැඟිල්ලක් අවසාන ලක්ෂ්‍යවල හෝ සිතියම්කරණයේ ඇති බව මම කියමි /customers/{id}/balance.

වෙබ් අඩවියේ (ඉදිරිපස කෙළවරේ) සිට ඔබේ දත්ත ගබඩාවට / සේවාදායකයට (පසුපස අන්තයට) සම්බන්ධ වන නල මාර්ගය ලෙස ඔබට එවැනි අන්ත ලක්ෂ්‍යයක් සිතාගත හැකිය. ඒවා භාවිතා කරමින්, ඔබේ යෙදුමේ ඇති ඕනෑම REST සිතියම්කරණයේ අනුරූප ක්‍රම වලින් අර්ථ දක්වා ඇති පසුපස අන්තයේ මෙහෙයුම් සිදු කළ හැකිය.

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.