Hopp til innholdet
ENStudio (åpnes i ny fane)
Meny

RestAPI.com · Plattformen under

Alt dere leverer, står på dette.

Modeller dataene én gang, så finnes dokumenterte REST-endepunkter i det øyeblikket dere lagrer — med pålogging, tilganger og logikk på serversiden som en del av strukturen, ikke skrudd på måneder senere. Det er dette Softeria Studio bygger på, og det kan også brukes alene.

Datamodellen i utviklerportalen til RestAPI.com: samlingene product, warehouse og manufacturer med feltene og typene sine, koblingene mellom dem og en visning bygget på product
Backend-kode
0 linjer
Mellom en lagret samling og et dokumentert endepunkt i drift
Deres
100 %
Av dataene og strukturen, alltid mulig å eksportere
Planer fra
250 kroner
I måneden, eks. mva. Gratisplanen er for apper bygget med Studio for Business
Svar innen
< 1 time
Fra dem som bygger plattformen, ikke fra en kø

I produktet

Utviklerportalen til RestAPI.com slik den er, i et demoområde: feltene og typene i en samling, en forespørsel og svaret, og oversikten over hele API-et.

  • Samlingsredigereren i RestAPI.com-portalen: samlingen product med feltene sine, typene og koblingen til manufacturerSamlingsredigereren i RestAPI.com-portalen: samlingen product med feltene sine, typene og koblingen til manufacturer

    Definer dataene

  • REST-utforskeren i RestAPI.com: en GET-forespørsel etter produkter og JSON-svaret, med den tilknyttede produsenten inkludertREST-utforskeren i RestAPI.com: en GET-forespørsel etter produkter og JSON-svaret, med den tilknyttede produsenten inkludert

    Kall API-et

  • Oversikten i RestAPI.com-portalen: antall samlinger, visninger, spørringer og funksjoner, fakturering for perioden og datalagring over tidOversikten i RestAPI.com-portalen: antall samlinger, visninger, spørringer og funksjoner, fakturering for perioden og datalagring over tid

    Se helheten

Ingen roser laget som ligger under. Alt står på det likevel.

Det den bærer

Databaser, endepunkter, tilganger, pålogging, drift, sikkerhetskopiering. Måneder med arbeid ingen kunde noen gang kommer til å takke dere for, og det første som senker et produkt når det er gjort dårlig. RestAPI.com er hele det laget, drevet som en administrert plattform.

  • Controllere, rutefiler og rørleggerarbeid for forespørslerBorte
  • API-dokumentasjon som må holdes i takt for håndBorte
  • En brukertabell, en tilbakestilling av passord og et sesjonslagerBorte
  • Migreringsskript kjørt for hånd en fredag ettermiddagBorte
  • En ekstra tjeneste bare for å nå systemet dere allerede harBorte

Lagre tabellen. API-et finnes allerede.

Tabell inn, API ut

Ingenting å generere, ingenting å rulle ut, ingenting å holde synkronisert. Dette er hele utvekslingen.

Det dere definerer · bookings

customer
relation→ customers
kayak
relation→ kayaks
startsAt
datetime
hours
integer
status
stringheld · paid · out · returned
totalNok
decimal

id · created · createdBy · modified · modifiedBy — satt av plattformen, aldri av dere.

Det dere får, med en gang

  • GET /api/bookings
  • GET /api/bookings/{id}
  • POST /api/bookings
  • PATCH /api/bookings/{id}
  • DELETE /api/bookings/{id}
  • GET /api/_openapi

GET /api/bookings?filter=status eq 'paid'&sortBy=startsAt-&pageSize=50

Og reglene oppå

  • ansatte kan lese alle bookinger på sitt eget utleiested
  • en kunde kan aldri lese andre bookinger enn sine egne
  • ingen utenfor bedriften ser en eneste rad

Filtrering, sortering, søk, sidevisning og utvalg av felt er spørreparametere, ikke endepunkter noen må skrive. OpenAPI-dokumentet genereres fra den samme definisjonen, så frontenden kan få typer generert fra API-et i stedet for å håpe at det stemmer.

Tre ting som holder det ærlig mens det vokser.

Og så forblir det riktig

  • Typet, ikke gjettet

    Generer TypeScript-typer rett fra API-et i drift, så et omdøpt felt blir en byggefeil i editoren i stedet for en feil kunden finner.

  • Dokumentert på vei ut

    Hver samling publiserer en OpenAPI-beskrivelse automatisk. Dokumentasjonen kan ikke henge etter implementasjonen, fordi den genereres fra den.

  • Trygt å endre

    Skjemaendringer som ville ødelagt eksisterende data eller eksisterende kall, blir flagget før de kjøres, i stedet for å bli oppdaget i produksjon etterpå.