Creazione di entità con indirizzi validati tramite API REST

Question

Creazione di entità con indirizzi validati tramite API REST

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

6

Sto costruendo un servizio REST. Questo servizio consente all'utente di creare un'entità che ha un indirizzo. Per semplificare, diciamo che questa altra entità è 'Casa', quindi 'A casa ha un indirizzo'.

Il sistema deve geocodificare tutte le case, quindi insieme all'indirizzo, una casa deve avere latitudine / longitudine al momento della creazione, ma queste non sono richieste all'utente.

L'utente verrà invitato a inserire un indirizzo. Da questo indirizzo il sistema proverà a recuperare latitudine / longitudine usando un servizio di terze parti. Questo servizio restituirà la migliore corrispondenza per l'indirizzo inserito dall'utente, quindi a volte restituirà un indirizzo diverso (ad esempio potrebbe accadere che ci siano due strade diverse con lo stesso nome in città diverse e che i servizi possano restituire informazioni relative a quella sbagliata ).

Devo assicurarmi che l'indirizzo che sto memorizzando con la casa sia quello desiderato dall'utente, quindi il flusso di lavoro per l'utente sarebbe qualcosa del tipo:

L'utente desidera creare una nuova casa.
L'utente Inserisci un indirizzo.
L'utente vede la migliore corrispondenza per quell'indirizzo in una mappa.
L'utente conferma che l'indirizzo è OK.
Il sistema salva la casa con l'indirizzo e il lat / long recuperati dal servizio.

Approccio 1

Il modello delle entità sarebbe:

House ha un indirizzo
L'indirizzo ha una coordinata (lat / long)

e avrei un endpoint per gli indirizzi POST e un altro per le case POST. Il flusso di lavoro sarebbe:

L'utente desidera creare una nuova casa.
L'utente Inserisci un indirizzo e crea un POST per l'endpoint degli indirizzi .
Il sistema recupera il lat / long per la migliore corrispondenza.
Il sistema salva l'indirizzo recuperato dal servizio di geocoding nel DB. Si noti che può essere diverso dall'indirizzo inserito dall'utente.
Come risposta alla richiesta POST, il sistema restituisce l'indirizzo che è stato salvato e lo mostra all'utente.
L'utente conferma che l'indirizzo è OK.
Il sistema esegue un POST all'endpoint delle case con l'ID per l'indirizzo che è stato creato in precedenza, quindi in DB la casa sarà collegata all'indirizzo già creato in precedenza.

Con questo approccio, se l'utente non accetta l'indirizzo fornito, finirei con alcuni indirizzi "orfani" (indirizzi che non sono collegati ad alcuna Casa). Avrei bisogno di fare una pulizia periodica sul DB per quegli indirizzi.

Approccio 2

In questo approccio, avrei un endpoint / validate-address, quindi l'utente avrebbe POST un indirizzo e il sistema restituirebbe la migliore corrispondenza. A questo punto non verrà creato nulla nel DB. L'utente accetterebbe quindi l'indirizzo restituito e farebbe un POST a / case con le informazioni della casa e l'indirizzo.

Con questo approccio, non posso assicurare che tutti gli indirizzi nel DB siano georeferenziati correttamente poiché alcuni utenti potrebbero effettuare un POST a / case senza una precedente chiamata a / validate-address.

Inoltre, non sembra corretto da una prospettiva REST avere una richiesta POST / indirizzo di convalida che non crei nulla sul DB.

Quale sarebbe l'approccio migliore a questa situazione? Riesci a vedere un approccio alternativo a questi due? Qualsiasi feedback sarebbe apprezzato.

rest

posta mario595 18.11.2014 - 20:54

fonte

2 risposte

Leggi altre domande sui tag rest

Le migliori pratiche per autenticare terze parti in un sito web? Decoratore che cambia la firma: documenta adeguatamente argomenti aggiuntivi

score 1 · Answer 1

Quando dici, un utente ha una casa; e ogni casa ha dati di indirizzo, che significa al contrario: nessun indirizzo senza una casa - il che non ha alcun senso. Da questo la procedura dovrebbe essere chiara:

Usecase: Creazione della casa

1) L'utente inserisce tutti i dati rilevanti

2) Un GET -Richiesta viene inviato a un geocode -Servizio, che restituisce gli indirizzi possibili

3) Solo dopo che l'utente ha inserito dati validi / accettato un set di dati dal geocode -Servizio a POST -Richiedi con i dati completi (dati di casa e indirizzo) è fatto per / houses : poiché stai creando una nuova house -ressource. Anche POST in / utente / {id} / case è una possibilità; lo stress è quindi (semanticamente) sull'utente . Preferisco la prima variante. La relazione appartiene all'utente {id} è un attributo della casa.

4) Quando viene creata la casa - la nuova risorsa viene restituita (si ottiene l'idea):

{
    "name": "Casa di falcone",
    "id": "123",
    "links": [
        {
            "rel": "self",
            "href": "http://www.example.com/houses/123"
        },
        {
            "rel": "users",
            "href": "http://www.example.com/users/1"
        },
        {
            "rel": "addresses",
            "href": "http://www.example.com/addresses/27/"
        }
    ],
    "address": {
        "id": "27",
        "links": [
            {
                "rel": "self",
                "href": "http://www.example.com/addresses/27"
            },
            {
                "rel": "houses",
                "href": "http://www.example.com/houses?address=27"
            },
            {
                "rel": "users",
                "href": "http://www.example.com/users?address=27"
            }
        ]
    },
        "user": {
        "id": "1",
        "links": [
            {
                "rel": "self",
                "href": "http://www.example.com/users/1"
            },
            {
                "rel": "houses",
                "href": "http://www.example.com/houses?user=1"
            },
            {
                "rel": "addresses",
                "href": "http://www.example.com/addresses?user=1"
            }
        ]
    }
}

Implicitamente c'era un indirizzo generato e il suo id è incorporato nel risultato. Ovviamente indirizzo e casa sono nel tuo modello due cose / risorse diverse, ma non ha senso gestirle separatamente.

score 0 · Answer 2

Questa risposta si espande sui commenti toniedzwiedz, quindi chiunque altro li legge pure.

Quindi leggendo la domanda diventa chiaro che non ti fidi della descrizione dell'utente dell'indirizzo, ma Fidati della descrizione dell'utente dell'ID del codice geografico dell'indirizzo.

Vale a dire che l'utente non è l'autorità del formato dell'indirizzo per la casa, il database del codice geografico è l'autorità. Ma è l'autorità di cui l'ID dell'indirizzo geografico è mappato alla casa.

Quindi quando l'utente dice al sistema "Questo è l'indirizzo della casa", quello che stanno realmente dicendo è "Questo è l'ID dell'indirizzo geo-codice della casa" .

In questo caso il flusso è

L'utente crea una casa tramite POSTing a / users / 123 / houses

L'utente crea l'indirizzo di casa tramite l'immissione dell'indirizzo di geo-codice per / users / 123 / houses / 1 / address

In che modo l'utente ottiene l'ID del codice geografico? Come dice toniedzwiedz, possono interrogarlo indipendentemente dal flusso. Puoi avere un endpoint che restituisce semplicemente gli ID geo-code per gli indirizzi

GET /geo-codes?address=1600 Pennsylvania Ave NW

{
    "matches": [
    {
        "geo-id":122,
        "address": "1600 Pennsylvania Ave NW, Washington, D.C., United States"
    },
    {
        "geo-id":9837,
        "address": "1600 Pennsylvania Ave, Sweden,"
    }]
}

L'utente quindi METTA il geo-id all'URI / utenti / 123 / case / 1 / indirizzo.