Vraag Wat is RESTful programmeren precies?


Wat is RESTful programmeren precies?


3628
2018-03-22 14:45


oorsprong


antwoorden:


Een architectonische stijl riep REST (representatieve staatstransfer) pleit ervoor dat webtoepassingen HTTP gebruiken zoals het was oorspronkelijk gepland. Opzoekingen zouden moeten gebruiken GET verzoeken. PUT, POST, en DELETE verzoeken moet worden gebruikt voor mutatie, creatie en verwijdering.

REST-voorstanders neigen naar voorkeur voor URL's, zoals

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

maar de REST-architectuur vereist deze "mooie URL's" niet. Een GET-verzoek met een parameter

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

is net zo RUSTIG.

Houd er rekening mee dat GET-verzoeken nooit mogen worden gebruikt voor het bijwerken van informatie. Bijvoorbeeld een GET-aanvraag voor het toevoegen van een artikel aan een winkelwagentje

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

zou niet gepast zijn. GET-verzoeken moeten zijn idempotent. Dat wil zeggen dat het twee keer verzenden van een verzoek niet anders moet zijn dan het één keer uitgeven. Dat is wat de aanvragen cacheable maakt. Een verzoek om aan het winkelwagentje toe te voegen is niet idempotent. Als u dit tweemaal uitgeeft, worden twee exemplaren van het artikel aan het winkelwagentje toegevoegd. Een POST-verzoek is in deze context duidelijk geschikt. Dus zelfs een RESTful webapplicatie heeft zijn aandeel POST-aanvragen nodig.

Dit komt uit het uitstekende boek Core JavaServer-gezichten boek van David M. Geary.


540
2018-04-15 11:26



RUST UIT is het onderliggende architecturale principe van het web. Het verbazingwekkende van internet is het feit dat clients (browsers) en servers op complexe manieren kunnen communiceren zonder dat de klant vooraf iets weet over de server en de bronnen die het host. De belangrijkste beperking is dat de server en de client het beide eens moeten zijn media gebruikt, wat in het geval van het web is HTML.

Een API die voldoet aan de principes van RUST UIT vereist niet dat de client iets weet over de structuur van de API. Integendeel, de server moet alle informatie verstrekken die de klant nodig heeft om met de service te communiceren. Een HTML-formulier is een voorbeeld hiervan: de server geeft de locatie van de resource en de vereiste velden op. De browser weet niet van tevoren waar de informatie moet worden verzonden en weet niet van tevoren welke informatie moet worden ingediend. Beide vormen van informatie worden volledig geleverd door de server. (Dit principe wordt genoemd HATEOAS: Hypermedia als de motor van de aanvraagstaat.)

Dus, hoe is dit van toepassing HTTPen hoe kan het in de praktijk worden geïmplementeerd? HTTP is gericht op werkwoorden en bronnen. De twee werkwoorden in het reguliere gebruik zijn GET en POST, waarvan ik denk dat iedereen ze zal herkennen. De HTTP-standaard definieert echter verschillende andere, zoals PUT en DELETE. Deze werkwoorden worden vervolgens toegepast op bronnen, volgens de instructies van de server.

Laten we ons bijvoorbeeld voorstellen dat we een gebruikersdatabase hebben die wordt beheerd door een webservice. Onze service maakt gebruik van een aangepaste hypermedia op basis van JSON, waarvoor we het mimetype toewijzen application / json + userdb (Er kan ook een zijn application / xml + userdb en aanvraag / whatever + userdb - veel mediatypen kunnen worden ondersteund). De client en de server zijn beide geprogrammeerd om dit formaat te begrijpen, maar ze weten niets van elkaar. Als Roy Fielding wijst erop:

Een REST API zou bijna al zijn beschrijvende inspanningen moeten besteden in   het definiëren van de mediatype (s) gebruikt voor het representeren van middelen en autorijden   applicatiestatus, of bij het definiëren van uitgebreide relatienamen en / of   hypertext-enabled mark-up voor bestaande standaard mediatypen.

Een aanvraag voor de basisresource / kan iets als dit retourneren:

Verzoek

GET /
Accept: application/json+userdb

antwoord

200 OK
Content-Type: application/json+userdb

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

We weten uit de beschrijving van onze media dat we informatie over gerelateerde bronnen kunnen vinden in secties die 'links' worden genoemd. Dit heet Bedieningselementen voor hypermedia. In dit geval kunnen we aan zo'n sectie zien dat we een gebruikerslijst kunnen vinden door een nieuwe aanvraag voor te doen /user:

Verzoek

GET /user
Accept: application/json+userdb

antwoord

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

We kunnen veel vertellen van dit antwoord. We weten nu bijvoorbeeld dat we een nieuwe gebruiker kunnen maken door te POSTen naar /user:

Verzoek

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

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

antwoord

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

We weten ook dat we bestaande gegevens kunnen wijzigen:

Verzoek

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

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

antwoord

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

Merk op dat we verschillende HTTP-werkwoorden gebruiken (GET, PUT, POST, DELETE enz.) Om deze bronnen te manipuleren, en dat de enige kennis die we veronderstellen over het deel van de klant, onze mediabesturing is.

Verder lezen:

(Dit antwoord is het onderwerp geweest van een behoorlijke hoeveelheid kritiek voor het missen van het punt. Voor het grootste deel was dat een eerlijke kritiek. Wat ik oorspronkelijk beschreef, was meer in overeenstemming met hoe REST gewoonlijk een paar jaar geleden werd geïmplementeerd toen ik schreef dit eerst, eerder dan de ware betekenis ervan, ik heb het antwoord herzien om de echte betekenis beter weer te geven.)


2788
2018-03-22 19:37



RESTful programming gaat over:

  • middelen worden geïdentificeerd door een persistent identifier: URI's zijn tegenwoordig de alomtegenwoordige keuze van de identifier
  • middelen die worden gemanipuleerd met behulp van een gemeenschappelijke reeks werkwoorden: HTTP-methoden zijn het vaak voorkomende geval - het eerbiedwaardige Create, Retrieve, Update, Delete wordt POST, GET, PUT, en DELETE. Maar REST is niet beperkt tot HTTP, het is gewoon het meest gebruikte transport nu.
  • de werkelijke representatie opgehaald voor een resource is afhankelijk van het verzoek en niet de identifier: gebruik Accept headers om te bepalen of u XML, HTTP of zelfs een Java-object wilt dat de resource vertegenwoordigt
  • handhaven van de staat in het object en representeren van de staat in de representatie
  • de relaties tussen resources in de representatie van de resource vertegenwoordigen: de links tussen objecten worden direct in de representatie ingebed
  • bronrepresentaties beschrijven hoe de representatie kan worden gebruikt en onder welke omstandigheden deze op een consistente manier moet worden weggegooid / opnieuw gezet: gebruik van HTTP Cache-Control-headers

De laatste is waarschijnlijk het belangrijkste in termen van gevolgen en algehele effectiviteit van REST. Over het algemeen lijken de meeste RESTful discussies op HTTP en het gebruik ervan vanuit een browser en wat niet. Ik begrijp dat R. Fielding de term bedacht toen hij de architectuur beschreef en beslissingen die tot HTTP leidden. Zijn proefschrift gaat meer over de architectuur en cache-mogelijkheden van bronnen dan over HTTP.

Als je echt geïnteresseerd bent in wat een RESTful architectuur is en waarom het werkt, lees dan zijn proefschrift een paar keer en lees de hele ding niet alleen hoofdstuk 5! Volgende blik waarom DNS werkt. Lees over de hiërarchische organisatie van DNS en hoe verwijzingen werken. Lees dan en overweeg hoe DNS-caching werkt. Lees ten slotte de HTTP-specificaties (RFC2616 en RFC3040 in het bijzonder) en overweeg hoe en waarom de caching werkt zoals dat gebeurt. Uiteindelijk zal het gewoon klikken. De laatste openbaring voor mij was toen ik de gelijkenis zag tussen DNS en HTTP. Hierna begint te begrijpen waarom SOA en Message Passing Interfaces schaalbaar zijn.

Ik denk dat dit de belangrijkste truc is om het architecturale belang en de implicaties voor de prestaties van een RESTful te begrijpen Niets gedeeld architecturen is om te voorkomen dat je de details van de technologie en de implementatie oplost. Concentreer u op wie de eigenaar is van hulpmiddelen, wie verantwoordelijk is voor het maken / onderhouden ervan, enz. Denk vervolgens aan de representaties, protocollen en technologieën.


500
2017-07-04 05:47



Dit is hoe het eruit zou kunnen zien.

Maak een gebruiker met drie eigenschappen:

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

De server reageert:

200 OK
Location: /user/123

In de toekomst kunt u dan de gebruikersinformatie ophalen:

GET /user/123

De server reageert:

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

Om het record te wijzigen (lname en age blijft ongewijzigd):

PATCH /user/123
fname=Johnny

Om het record bij te werken (en bijgevolg lname en age zal NULL zijn):

PUT /user/123
fname=Johnny

392
2017-11-18 20:46



Een geweldig boek over REST is RUST in de praktijk.

Moet lezen zijn Representational State Transfer (REST) en REST-API's moeten hypertextgestuurd zijn 

Zie Martin Fowlers artikel de Richardson Maturity Model (RMM) voor een uitleg over wat een RESTful service is.

Richardson Maturity Model

Om REST te zijn moet een Service de Hypermedia als de Engine of Application State. (HATEOAS), dat wil zeggen, het moet niveau 3 bereiken in de RMM, Lees het artikel voor details of de dia's van de qcon-talk.

De HATEOAS-beperking is een afkorting   voor Hypermedia als de motor van   Aanvraagstaat. Dit principe is   de belangrijkste differentiator tussen een REST   en de meeste andere vormen van client-server   systeem.

...

Een klant van een RESTful applicatie nodig   ken maar één vaste URL om toegang te krijgen   het. Alle toekomstige acties zouden moeten zijn   vindbaar dynamisch van   hypermedia links opgenomen in de   representaties van de middelen die   worden geretourneerd van die URL.   Gestandaardiseerde mediatypen zijn ook   naar verwachting door iedereen begrepen   client die een RESTful API zou kunnen gebruiken.   (Van Wikipedia, de gratis encyclopedie)

RUST lakmoesproef voor webkaders is een vergelijkbare volwassenheidstest voor webraamwerken.

Zuiver REST benaderen: leren HATEOAS lief te hebben is een goede verzameling links.

REST versus SOAP voor de Public Cloud bespreekt de huidige niveaus van REST-gebruik.

REST en versiebeheer bespreekt Uitbreidbaarheid, Versioning, Evolvability, etc.  via modificeerbaarheid


170
2018-03-22 15:20



Wat is REST?

REST staat voor Representational State Transfer. (Het is soms   gespeld "ReST".) Het vertrouwt op een staatloze client-server, cacheable   communicatieprotocol - en in vrijwel alle gevallen de HTTP   protocol wordt gebruikt.

REST is een architectuurstijl voor het ontwerpen van netwerktoepassingen.   Het idee is dat, in plaats van het gebruik van complexe mechanismen zoals CORBA,   RPC of SOAP om verbinding te maken tussen machines, waarbij eenvoudig HTTP wordt gebruikt   oproepen tussen machines.

In veel opzichten kan het World Wide Web zelf, gebaseerd op HTTP, worden bekeken   als een REST-gebaseerde architectuur. RESTful applicaties gebruiken HTTP-requests   om gegevens te plaatsen (maken en / of bijwerken), gegevens lezen (bijvoorbeeld zoekopdrachten maken),   en verwijder gegevens. REST gebruikt dus HTTP voor alle vier CRUD's   (Maken / Lezen / Bijwerken / Verwijderen) bewerkingen.

REST is een lichtgewicht alternatief voor mechanismen zoals RPC (Remote   Procedure Calls) en Web Services (SOAP, WSDL, et al.). Later zullen we dat doen   zie hoe veel simpeler REST is.

Ondanks dat het eenvoudig is, is REST volledig uitgerust; er is eigenlijk   niets wat je kunt doen in Web Services dat niet kan worden gedaan met een RESTful   architectuur. REST is geen "standaard". Er zal nooit een W3C zijn   Recommendataion voor REST, bijvoorbeeld. En hoewel er RUST is   programmeerkaders, werken met REST is zo eenvoudig dat je het kunt   vaak "roll your own" met standaard bibliotheekfuncties in talen zoals   Perl, Java of C #.

Een van de beste referenties die ik vond toen ik probeerde de simpele echte betekenis van rust te vinden.

http://rest.elkstein.org/


128
2018-03-22 14:53



REST gebruikt de verschillende HTTP-methoden (voornamelijk GET / PUT / DELETE) om gegevens te manipuleren.

In plaats van een specifieke URL te gebruiken om een ​​methode te verwijderen (bijvoorbeeld /user/123/delete), zou u een VERWIJDEREN verzoek naar de verzenden /user/[id] URL, om een ​​gebruiker te bewerken, om informatie op te halen over een gebruiker aan wie u een GET-verzoek stuurt /user/[id]

In plaats daarvan een reeks URL's die er bijvoorbeeld als volgt uit kunnen zien ..

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

U gebruikt de HTTP "werkwoorden" en hebt ..

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

85
2017-07-12 16:33



Het is programmeren waarbij de architectuur van je systeem past bij de REST-stijl uitgelegd door Roy Fielding in zijn proefschrift. Omdat dit de architecturale stijl is die het web (min of meer) beschrijft, zijn er veel mensen in geïnteresseerd.

Bonusantwoord: Nee. Tenzij je software-architectuur bestudeert als een academische of ontwerpende webservice, is er echt geen reden om de term te horen.


63
2018-03-23 17:11



Ik zou zeggen dat RESTful programming gaat over het creëren van systemen (API) die de REST-architectuurstijl volgen.

Ik vond deze fantastische, korte en gemakkelijk te begrijpen tutorial over REST van Dr. M. Elkstein en citeerde het essentiële deel dat je vraag voor het grootste deel zou beantwoorden:

Leer REST: een zelfstudie

REST is een architecturale stijl voor het ontwerpen van netwerktoepassingen.   Het idee is dat, in plaats van het gebruik van complexe mechanismen zoals CORBA,   RPC of SOAP om verbinding te maken tussen machines, waarbij eenvoudig HTTP wordt gebruikt   oproepen tussen machines.

  • In veel opzichten kan het World Wide Web zelf, gebaseerd op HTTP, worden beschouwd als een REST-gebaseerde architectuur.

RESTful applicaties gebruiken HTTP-requests om data te plaatsen (create en / of   update), lees gegevens (bijvoorbeeld query's maken) en verwijder gegevens. Dus REST   gebruikt HTTP voor alle vier CRUD-bewerkingen (Maken / Lezen / Bijwerken / Verwijderen).

Ik vind niet dat je je dom zou moeten voelen omdat je niet hoort over REST buiten Stack Overflow ..., ik zou in dezelfde situatie zitten !; antwoorden op deze andere SO vraag Waarom wordt REST nu groot zou wat gevoelens kunnen verzachten.


43
2017-07-25 09:05



Mijn excuses als ik de vraag niet rechtstreeks beantwoord, maar het is gemakkelijker om dit allemaal te begrijpen met meer gedetailleerde voorbeelden. Fielding is niet gemakkelijk te begrijpen vanwege alle abstractie en terminologie.

Hier is een redelijk goed voorbeeld:

REST en Hypertext uitleggen: Spam-E de Spam-reinigingsrobot

En nog beter, er is een duidelijke uitleg met eenvoudige voorbeelden hier (het PowerPoint is uitgebreider, maar je kunt het meeste krijgen in de html-versie):

http://www.xfront.com/REST.ppt of http://www.xfront.com/REST.html

Na het lezen van de voorbeelden, kon ik zien waarom Ken zegt dat REST hypertext-driven is. Ik ben er niet zeker van dat hij gelijk heeft, omdat die / user / 123 een URI is die naar een resource wijst en het is mij niet duidelijk dat het onterecht is, alleen omdat de klant er 'out-of-band' van kent.

Dat xfront-document verklaart het verschil tussen REST en SOAP, en dit is ook echt nuttig. Wanneer Fielding zegt: "Dat is RPC. Het schreeuwt RPC.", het is duidelijk dat RPC niet RESTvol is, dus het is handig om de exacte redenen hiervoor te zien. (SOAP is een type RPC.)


43
2018-03-22 16:36



Wat is REST?

RUST in officiële woorden, REST is een architecturale stijl gebouwd op bepaalde principes met behulp van de huidige "Web" -beginselen. Er zijn 5 basisfundamentals van internet die worden gebruikt om REST-services te maken.

  • Principe 1: Everything is a Resource In de architecturale stijl van REST worden gegevens en functionaliteit beschouwd als bronnen en zijn ze toegankelijk via Uniform Resource Identifiers (URI's), meestal links op het web.
  • Principe 2: elke resource wordt geïdentificeerd door een unieke identificatie (URI)
  • Principe 3: Gebruik eenvoudige en uniforme interfaces
  • Principe 4: Communicatie wordt uitgevoerd door vertegenwoordiging
  • Principe 5: wees staatloos

36
2017-11-22 22:49