REST: Posso usare la richiesta POST per leggere i dati?

Una cosa che ho fatto dove lavoro è avere un'API di servizio "storage". Fondamentalmente, POST un oggetto JSON al servizio e restituisce un UUID. Si invia l'UUID come parametro di query a qualsiasi successiva chiamata API e otterrà i parametri / dati dal servizio di archiviazione. È particolarmente utile se si effettuano più chiamate con gli stessi dati, poiché è necessario inviarli una sola volta.

Dopo aver letto un paio di domande simili mi sono reso conto che REST non è in realtà progettato per risolvere questo problema. Quindi ho deciso di optare per JSON-RPC piuttosto REST che offre maggiore flessibilità e sembra essere la soluzione giusta per questo tipo di problemi.

Sì, puoi farlo funzionare almeno utilizzando WCF, è leggermente diverso in MVC e Web API in cui aggiungi attributi a metodi come [GET] [POST] ecc.

I have heard that it's against REST best-practices to use a POST request to read data and I highly prefer to follow the best-practices as the API is supposed to be publicly accessible to the company's clients.

Ovviamente è una pratica sbagliata usare il POST per ottenere i dati poiché il POST è per la creazione di risorse nel sistema che non le ricevono.

Best practice per REST

I have an API call that requires a lot of parameters and it's basically a Read action. I can't use GET request because it may hit the URI limit.

Usa la matrice per inviare parametri o creare oggetti se i tuoi parametri sono correlati

Migliorare la risposta di TMT anziché utilizzare un servizio di archiviazione per archiviare gli UUID rispetto ai parametri della richiesta. Puoi invece scrivere un'API senza stato utilizzando Token Web JSON . Ciò eliminerà il problema della gestione dello spazio di archiviazione, consentirà il riutilizzo e la memorizzazione nella cache.

Il flusso sarà simile a questo:

1. Il client invia un oggetto JSON con i parametri di richiesta come richiesta POST alla tua API Tokenize.
2. API restituisce un token Web JSON generato utilizzando l'oggetto JSON fornito come payload.
3. Il client invia una richiesta GET alla tua vera API con quel token come parametro.
4. La tua API (o idealmente un middleware) decodifica il token per ottenere i parametri della richiesta ed elabora la richiesta.

Questo metodo non richiede archiviazione.
L'implementazione dell'API reale non richiede alcuna considerazione speciale.
Assicura che i token non vengano manomessi lungo il percorso.
Poiché non esiste uno stato, non è necessario preoccuparsi della corruzione dei dati. Il caching è molto più semplice. L'applicazione a più API è banale e può essere eseguita senza la supervisione di qualsiasi altro membro del team.

Ricorda che se il tuo payload è troppo grande, anche la JWT può essere grande. Assicurati che la lunghezza dell'URL non superi i 2000 caratteri. Ho provato con un JSON 1.9K e ho ottenuto un JWT a 1695 caratteri (che dovrebbe essere più che sufficiente IMO)