Come dovrei incorporare un endpoint di messaggi in un'API REST?

Per questo semplice caso, è meglio la seconda alternativa:

/members/{member-id}/messages

E puoi restituire 404 se non è stato trovato member-id .

I'm thinking about creating a /messages endpoint that I make a POST request to when I want to send a message, providing a member's ID and the message content. The problem that I see with this approach is handling the case where someone provides a non-existent member ID. Would I return a 404 in this case?

Anche questa è un'alternativa valida. A volte, è necessario "rompere" alcuni endpoint di grandi dimensioni. Ad esempio, invece di qualcosa di simile:

/members/{id}/carts/{id}/orders/{id}/products/{id}/

Puoi avere due endpoint:

/members/{id}/carts/{id}/
/orders/{id}/products/{id}/ 

Il necessario id s sarà nel corpo della richiesta. Ad esempio, nella seconda richiesta il member e cart id sarà nel corpo della richiesta.

E non vedo alcun problema al momento del ritorno 404. Se 404 ti dà fastidio, puoi usare un altro codice. La cosa più importante è essere coerenti con la tua API.

The problem that I see with this approach is handling the case where someone provides a non-existent member ID. Would I return a 404 in this case?

No. 400 sarebbe ok. La risorsa esiste ed è stata trovata ( /messages ). Stava elaborando ciò che non era riuscito a causa di un input non valido. Quindi, il cliente può riprovare non appena risolve i problemi.

404 non è così "gentile". Il "continuare a provare" non è così esplicito.

Another approach would be to make the messages endpoint part of the members endpoint. So, I would do something like make a POST request to /members/{member-id}/messages

discutibile.

Pensa solo ai servizi di posta web. Come manderebbero e-mail a un elenco di e-mail, con copia ad altre e-mail, ecc.

Come faresti con tale design API? Iterare su N URI? Abbastanza discutibile.

In modo definitivo, nessuno scrive un messaggio e lo invia direttamente e si avvicina alla casella di arrivo del bersaglio. O raccolta di e-mail.

Vorrei andare all'opzione n. 1, perché sembra più naturale per questo tipo di attività (invio di messaggi).

I'm designing a REST API that needs to allow me to send messages to members in the system.

Forse dovresti esaminare la pubblicazione Atom ; rendere i messaggi disponibili agli abbonati non è poi così diverso da creazione di voci di Atom in un feed.

... Which approach is more RESTful?

Né - A REST non importa come organizzi le tue risorse, né quali ortografie usi per gli identificatori. Uno dei vantaggi di REST è che il cliente è disaccoppiato da quelle preoccupazioni.