Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.


Info
1 § 1 REST services skal kunne modtage og svare med beskeder der er formateret som JSON. Svaret skal indeholde http header: "Content-Type: application/json".


Info

2 § 2 En REST service skal anvende HTTP verberne som følger:


HTTP GET: Anvendes til at hente information.
HTTP POST: Anvendes til at oprettet nye ressourcer.
HTTP PUT: Anvendes til at udskifte hele en eksisterende ressource.
HTTP PATCH: Anvendes til at opdatere enkelte dele af en eksisterende ressource.
HTTP DELETE: Anvendes til at slette ressourcer.


Info

3 § 3 REST services skal anvende navneord frem for verber i URL’en til at beskrive servicen.

For at hente en aftale gennem en REST service eksempelvist: ”/aftale” er korrekt, mens ”/hentaftale” er forkert.


Info

4 § 3.1 Såfremt en REST service returnerer collections, anvendes flertalsformen i URL’en.

Eksempelvis ”/aftaler”.


Info
5 § 3.2 Såfremt REST servicen giver mulighed for at hente enkelte attributter, bør de kunne specificeres i URL’en.

Dette kan være "/aftaler/<aftale-id>/starttime", hvor "starttime" er en enkel attribut.

Info
6 § 3.3 Såfremt en REST service tilbyder filtrering, sortering eller paginering af svaret, skal det ske via søgeparametre i URL’en.

Eksempelvis et HTTP GET kald mod "/articles/?page=1&page_size=10".

Info
7 § 3.4 Såfremt der er behov for at versionere en REST service, skal versionsnummeret være det første element i URL’ens path del.

Eksempelvis "v1/aftaler" og "v2/aftaler". Versioner med dato istedet vX.
 Her kan der benyttes et servlet filter til at få fat i versionen, og placere den på en servlet context. Den kan således anvendes til at skelne mellem forskellig logik på tværs af versioner.

Info
8 § 4 REST services skal returnere HTTP statuskoder ved succesfuld transaktion:
GET: 200 OK.
POST: 201 Created.
PUT: 200 OK.
PATCH: 200 OK.
DELETE: 204 No Content.


Info
9 § 5 Ved fejl transaktion returneres passende HTTP statuskode.

Ved klient fejl returneres en HTTP 4xx fejlkode, og ved server fejl en HTTP 5xx fejlkode. 

Info
10 § 6 En REST service skal kommunikere eventuelle begrænsninger i svaret.

Dette kan være begrænsninger i antal elementer der kan returneres, f.eks. ved loft på 10 aftaler fra en REST service "/aftaler", returneres HTTP "413 Content Too Large".

Info
11 § 7 En REST service skal designes så den er stateless.


Info
12 § 8 En REST service bør understøtte HTTP caching, når det er relevant.

...