Strutturazione di una richiesta GET / POST per recuperare i dati utilizzando l'API di riposo

Question

Strutturazione di una richiesta GET / POST per recuperare i dati utilizzando l'API di riposo

#1 da (2 voti)
#2 da (0 voti)

0

Ho notato che ci sono un paio di modi in cui si può usare una risorsa usando l'API di riposo. Attualmente sto cercando di trovare validi pro / contro su ciascuna di queste tecniche per adottarle su una scala più ampia.

Quali sarebbero le principali differenze tra queste richieste? Perché dovrei aggiungere id nel percorso, e non in querystring o corpo della richiesta? Ha a che fare con la memorizzazione nella cache o solo con le convenzioni centrate sulla risorsa?

[HttpGet]
http://doamin.com/resources/{id}/?filter1=a,filter2=b,
or
http://doamin.com/resources/?filter1=a,filter2=b,id=500

invece di

[HttpPost]
http://doamin.com/resources

Body
{
id: 100,
filter1: "a",
filter2: "b"
}

o

[HttpPost]
    http://doamin.com/resources/{id}

    Body
    {
    filter1: "a",
    filter2: "b"
    }

Trovo molto più facile sviluppare endpoint usando Post, ma mi piacerebbe davvero prendere in considerazione possibili problemi che uno sviluppatore che consumerà questi endpoint avrebbe effettivamente.

api-design api rest web-api

posta John 26.06.2017 - 12:19

fonte

2 risposte

Leggi altre domande sui tag api-design api rest web-api

Gestione di istanze di dati di gioco salvate multiple in MySQL questioni didattiche su RUP e agile [chiuso]

score 2 · Answer 1

What would be the main differences between these requests?

La differenza più significativa è la semantica del metodo. GET è sicuro , il che significa che la risorsa può essere pre-scaricata e possiamo ripetere richiesta, senza preoccupazioni, tante volte quante sono necessarie per ricevere una risposta attraverso un trasporto di messaggi inaffidabile.

POST non è né sicuro né idempotente , quindi dobbiamo fare molta più attenzione a reagire ai messaggi" persi ".

Why would I add id into the path, and not into querystring or request body? Does it have to do with caching or only with resource centered conventions?

Puramente convenzione, in particolare quella di RFC 3986 ,

The path component contains data, usually organized in hierarchical form, that, along with data in the non-hierarchical query component (Section 3.4), serves to identify a resource within the scope of the URI's scheme and naming authority (if any).

Questo è conveniente nel caso di riferimenti relativi; dove noi che abbiamo un link di rappresentazione ad un "vicino" senza dover specificare l'identificatore completo.

I find it much more easier to develop endpoints using Post, but I would really like to consider possible issues a developer who will consume these endpoints would actually have.

Il world wide web è l'applicazione di riferimento per REST. Sarà la tua guida più utile per anticipare i problemi che le tue API hanno. In altre parole, in caso di dubbi, chiediti cosa fa un sito Web.

score 0 · Answer 2

Se stai provando a seguire uno stile API RESTful, è preferibile avere l'ID all'interno del percorso dell'URL (al contrario di querystring o dei parametri del corpo). Ciò lo rende in modo che l'URL di base stesso (ad esempio, l'host e il percorso) possa rappresentare completamente un'entità specifica.

Questo gioca anche su alcune strutture di chiamata RESTful attese:

GET me.com/Users/154    (get this user)
GET me.com/Users        (get all users)
POST me.com/Users/154   (post (or PUT) this user)
DELETE me.com/Users/154 (delete this user)
DELETE me.com/Users     (delete all users)

Quando si utilizza un'API RESTful, le persone generalmente si attendono le convenzioni di cui sopra.

(concesso, non hai chiesto specificamente su REST, ma è lì che le cose tendono a cadere in questi giorni)