0

Let's say you have a database-credential resource that stores a few things:

  • whitelist of IPs that can connect
  • connection password for the user

When GETting / POSTing these, should they be under one API /database-credential or under two separate ones?

The reason I'm hesitating is because the whitelist of IPs will be stored in the database itself, whereas the connection password will be stored elsewhere (Azure KeyVault)

  • The obvious question is: Why are you returning passwords!. Rethink you're API so that the IP and Password Hash are given to the Service and it returns an authentication token on success, or something else on failure. – Kain0_0 Oct 28 at 21:48
  • @Kain0_0 looks like this is a repository of credentials to connect to another service. You can't connect to the other service without the credentials.... full stop. – user253751 Oct 29 at 12:54
1

Try to think of RESTful resources in terms of business entities, not database entities.

So if "database-credential"s are always dealt together as business entieties, I would recoment to use /database-credential in APIs.

If at all you need to deal with whitelist IPs or connection passwords independent of each other you can also add resources for them as:

  • /database-credential/{id}/whitelist-ip
  • /database-credential/{id}/connection-passwords

Side note: Not sure why but please rethink about exposing your credentials over rest APIs.

| improve this answer | |
  • 1
    Thanks, yeah they are handled together as a single entity. I appreciate the concern, but the API is secured under oauth2 and will always communicate via HTTPS. This is an application that will provide administrative password management capabilities for various readonly database users. – xandermonkey Oct 29 at 15:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.