Design Application per "attivamente" invitare utenti (fingere di avere privilegi)

Question

Design Application per "attivamente" invitare utenti (fingere di avere privilegi)

#1 da (1 voti)

2

Sto progettando un'applicazione in cui gli utenti si scambiano messaggi privati e possono inviare messaggi a qualsiasi Entity nel database (un Entity potrebbe non avere ancora un account utente, è un database professionale). Non sono sicuro di come progettare al meglio il database e l'API per consentire agli utenti non registrati di messaggistica. L'applicazione deve rimanere protetta e i dati sono accessibili solo a coloro che dispongono delle autorizzazioni corrette.

I messaggi inviati a persone senza account utente fungono da invito. La persona invitata dovrebbe essere in grado di visualizzare il messaggio, agire su di esso e completare la registrazione dell'utente dopo aver ricevuto un InviteMessage .

In termini semplici, ho:

User
    misc user fields (email, pw, dateJoined)

Entity (large professional dataset):
   personalDetails... 
   user->User (may be null) 

UserMessage:
   sender->User 
   recipient->User
   dateCreated
   messageContent, other fields.....

InviteMessage:
   sender->User
   recipient->Entity
   expiringUrl
   inviteeEmail
   inviteePhone

Ho intenzione di avvisare l'utente quando selezioni un recipient che non è ancora stato registrato, e informo che può inviare il messaggio come un invito fornendo un'e-mail, un telefono dove possiamo inviare l'invito.

Gli inviti avranno un URL univoco e univoco, ad es. %codice%. Una volta effettuato l'accesso, l'invitato visualizzerà il uuid.uuid4() e i dettagli sul completamento del suo profilo di registrazione.

Quando la registrazione è completa, InviteMessage dettagli su una nuova istanza di InviteMessage (per non perdere i loro dati), e assegnalo al UserMessage appena creato.

La possibilità di interagire con e invitare persone che non hanno ancora account è una caratteristica chiave dell'applicazione, e sembra preferibile separare l'invito dai messaggi privati, app (più facile mantenere le funzionalità separate, meglio se modello dati modifiche).

Si tratta di un progetto ragionevole e valido?
Se no, cosa suggeriresti?
Hai qualche miglioramento?
Sono corretto per scegliere di creare un endpoint separato per la creazione di inviti tramite l'API?

api-design web-applications database-design user-experience permissions

posta user3086451 10.12.2013 - 11:22

fonte

1 risposta

Leggi altre domande sui tag api-design web-applications database-design user-experience permissions

C # Problema di progettazione [chiuso] In GSL, perché alcune funzioni accettano un argomento "spazio di lavoro"?

score 1 · Answer 1

Se un messaggio può essere inviato a qualsiasi Entity , sarebbe più sensato associare il messaggio al Entity ricevente piuttosto che all'utente. Se lo fai, non è necessario distinguere tra inviti e messaggi normali; invece, puoi scrivere i dati specifici dell'invito in una tabella:

 User:
     misc user fields

 Entity:
     personalDetails
     user -> User (nullable)

 UserMessage:
     sender -> User
     recipient -> Entity
     dateCreated
     messageContent

 Invitation:
     content -> UserMessage
     expiringUrl
     inviteeEmail
     inviteePhone (aren't these two field part of Entity?)

Aumenta la manutenibilità: se vuoi aggiungere un campo aggiuntivo a UserMessage dovresti anche cambiare InviteMessage e il codice copia un InviteMessage in UserMessage con il tuo approccio.

Inoltre, supponiamo che un'entità abbia ricevuto più inviti. Vorresti persisterli tutti quando viene creato un nuovo account utente. Questo è anche più semplice se non hai bisogno di copiare il messaggio (elimina solo Invitation s dei messaggi di Entity ).