REST staat voor Representational State Transfer, een term bedacht door Roy Fielding in 2000. Het is een architectuurstijl voor het ontwerpen van losjes gekoppelde applicaties via HTTP, die vaak wordt gebruikt bij de ontwikkeling van webservices. REST handhaaft geen enkele regel met betrekking tot hoe het moet worden geïmplementeerd op een lager niveau, het zet gewoon hoog niveau ontwerp richtlijnen en laat u aan uw eigen implementatie denken.
In mijn laatste dienstverband ontwierp ik gedurende twee goede jaren RESTful API ‘ s voor een groot telecombedrijf. In deze post, Ik zal het delen van mijn gedachten, afgezien van standaard design praktijken. Misschien ben je het op een paar punten niet met me eens, en dat is prima. Ik wil graag alles van u bespreken met een open geest.
laten we beginnen met standaard ontwerp specifieke dingen om duidelijk te maken wat ‘Roy Fielding’ wil dat we bouwen. Dan zullen we mijn gedachten bespreken, die meer naar fijnere punten zullen zijn terwijl u uw RESTful API ‘ s ontwerpt.
architecturale beperkingen
REST definieert 6 architecturale beperkingen die van elke webservice een echte RESTful API maken.
- uniforme interface
- Client-server
- staatloos
- Cacheable
- gelaagd systeem
- Code op aanvraag (facultatief))
uniforme interface
aangezien de naam van de beperking zelf van toepassing is, moet u de API-interface kiezen voor bronnen in het systeem die worden blootgesteld aan API-Gebruikers en religieus volgen. Een bron in het systeem zou slechts één logische URI moeten hebben, en dat zou een manier moeten bieden om gerelateerde of aanvullende gegevens op te halen. Het is altijd beter om een bron te synonymiseren met een webpagina.
een enkele bron mag niet te groot zijn en alles in zijn representatie bevatten. Wanneer relevant, zou een bron links (HATEOAS) moeten bevatten die naar relatieve URI ‘ s wijzen om gerelateerde informatie op te halen.
ook moeten de bronrepresentaties in het hele systeem specifieke richtlijnen volgen, zoals naamgevingsconventies, linkformaten of dataformaten (XML of/en JSON).
alle bronnen moeten toegankelijk zijn via een gemeenschappelijke aanpak zoals HTTP GET en op soortgelijke wijze aangepast met behulp van een consistente aanpak.
Client-server
deze beperking betekent in wezen dat clienttoepassing en servertoepassing afzonderlijk moeten kunnen evolueren zonder enige afhankelijkheid van elkaar. Een client moet alleen Resource URI ‘ s kennen, en dat is alles. Vandaag, Dit is standaard praktijk in webontwikkeling, dus niets fancy is vereist van uw kant. Hou het simpel.
Stateless
Roy Fielding kreeg inspiratie van HTTP, dus het weerspiegelt zich in deze beperking. Maak alle client-server interacties stateloos. De server zal niets opslaan over de laatste HTTP-aanvraag van de client. Het zal elk verzoek als nieuw behandelen. Geen sessie, geen geschiedenis.
als de clienttoepassing een stateful toepassing voor de eindgebruiker moet zijn, waarbij de gebruiker eenmaal inlogt en daarna andere geautoriseerde bewerkingen uitvoert, dan moet elk verzoek van de client alle informatie bevatten die nodig is om het verzoek te onderhouden – inclusief authenticatie-en autorisatiedetails.
Cacheable
in de wereld van vandaag is het cachen van gegevens en antwoorden van het grootste belang waar deze van toepassing/mogelijk zijn. De webpagina die u hier leest is ook een gecached versie van de HTML pagina. Caching brengt prestatieverbetering voor de client-side en betere mogelijkheden voor schaalbaarheid voor een server omdat de belasting is verminderd.
in rust moet caching worden toegepast op bronnen indien van toepassing, en dan moeten deze bronnen zichzelf cacheable verklaren. Caching kan worden geïmplementeerd op de server of client-side.
gelaagd systeem
REST kunt u een gelaagde systeemarchitectuur gebruiken waarbij u de API ‘ s op server a implementeert en gegevens op server B opslaat en verzoeken in Server C bijvoorbeeld verifieert. Een client kan normaal gesproken niet zeggen of het direct verbonden is met de eindserver of een intermediair onderweg.
Code on demand (optioneel)
deze beperking is optioneel. Meestal stuurt u de statische representaties van bronnen in de vorm van XML of JSON. Maar als het nodig is, bent u vrij om return executable code te gebruiken om een deel van uw toepassing te ondersteunen, bijvoorbeeld, clients kunnen uw API bellen om een UI widget rendering code te krijgen. Het is toegestaan.
merk op dat alle bovenstaande beperkingen het nauwst verbonden zijn met WWW (het web). Met RESTful API ’s kunt u hetzelfde doen met uw webservices wat u met webpagina’ s doet.