Avfärdar myten om "bara POST"-API:er, förklarar varför den härrör från en missuppfattning av API-designprinciper och klargör de lämpliga användningsfallen för RESTful och RPC-arkitekturstilar.
Nyligen fångade en diskussion om huruvida man ska designa API:er med "bara POST" min uppmärksamhet. Efter att ha fördjupat mig i denna debatt fann jag att inte bara är frågan om vad folk argumenterar meningslös, utan den avslöjar också många utvecklares missförstånd av kärnan i API-design. Låt oss idag dyka djupt in i huvudidéerna med API-design och se varför denna debatt inte borde existera från första början.
De utvecklare som förespråkar att använda "bara POST" för att ersätta RESTful API-specifikationer har tydligt inte förstått den viktigaste punkten inom API-design. Deras argument inkluderar vanligtvis:
Vid en första anblick verkar dessa argument ge viss mening. Men i verkligheten förväxlar denna syn valet av HTTP-metoder med API-designstilar, två olika nivåer av problem. POST är bara en metod i HTTP-protokollet, medan REST är en stil för API-design.
Innan vi diskuterar specifika API-stilar behöver vi förstå vad som är det centrala syftet med API-design. Ett bra API bör vara:
RESTful API är bara en av många API-designstilar, med fokus på resurser och operationer på resurser. Låt oss ta ett enkelt bloggsystem som exempel för att se hur RESTful API designas:
Hämta alla artiklar:
Hämta en specifik artikel:
Skapa en ny artikel:
Uppdatera en artikel:
Ta bort en artikel:
I det här exemplet kan vi se:
Denna designmetod gör API:et mer intuitivt och självförklarande, vilket gör det enkelt för utvecklare att förstå funktionen av varje slutpunkt.
Målet med RPC (Remote Procedure Call) stil API-design är att göra fjärrtjänstanrop så enkla som att kalla lokala funktioner.
Intressant nog kanske de som förespråkar "bara POST" inte inser att de faktiskt beskriver RPC-stilen.
Jämfört med RESTful API:er fokuserar RPC mer på själva operationen snarare än resursen. Därför använder RPC-stil API:er vanligtvis en "verb + substantiv"-form, såsom getProduct(productId) eller createUser(userData).
I många RPC-implementeringar skickas alla operationer vanligen via POST-förfrågningar till samma slutpunkt, med den specifika operationen och parametrarna angivna i förfrågningskroppen. Detta är varför idén om "bara POST" faktiskt ligger närmare RPC än REST.
Till exempel kan en RPC-stil "hämta produkt"-förfrågan baserad på HTTP se ut så här:
Moderna RPC-ramverk, såsom gRPC, erbjuder kraftfullare och mer effektiva implementationer. Låt oss använda detta som ett exempel för att demonstrera RPC-stilen:
Först definierar vi tjänsten och meddelandeformatet (med hjälp av Protocol Buffers):
Sedan, med hjälp av denna tjänst i en Node.js-klient är det lika enkelt som att kalla en lokal funktion:
I detta RPC-stil exempel kan vi se:
GetArticle och CreateArticle).await för att vänta på resultatet, vilket ytterligare döljer nätverkskommunikationens komplexitet.Även om det underliggande lagret fortfarande kan använda HTTP/2 som transportprotokoll, ger RPC-ramverk (som gRPC) utvecklare ett abstraktionslager som gör fjärranropen till att se ut och kännas som lokala funktionsanrop.
Därför kan vi se att de flesta debatter om "bara POST" och RESTful API:er egentligen borde vara diskussioner om dessa två API-stilar: REST och RPC. Nyckeln är dock att erkänna att dessa två stilar har sina tillämpliga scenarier, och valet bör baseras på projektets specifika behov, inte personliga preferenser.
Nu när vi förstår skillnaderna mellan REST och RPC, låt oss titta på deras respektive tillämpliga scenarier:
Valet av stil bör baseras på dina specifika behov. I vissa fall kan du till och med använda en blandning av dessa två stilar inom samma system för att tillgodose behoven i olika delar.
Låt oss flytta vår uppmärksamhet bort från dessa meningslösa argument och fokusera på att designa riktigt utmärkta API:er. Efter allt är teknik till för att lösa problem, inte skapa dem.