Move away delete and post requests for the keygen service from query param to path

[BenFradet]

Relatedly to #60, I think it would be more RESTful to move away from requests like:

/api/apikeys/keygen?vendor_prefix=com.acme

To something like:

/api/apikeys/com.acme

Removing the keygen keyword since it doesn't really make sense anymore (given that we can retrieve/delete/create api keys) and moving away from the vendor_prefix query param in favour of a path based query.

In the same way, we could send GET and DELETE requests to:

/api/apikeys/some-uuid-to-delete-or-retrieve

What do you think @alexanderdean?

[alexanderdean]

I like it, agree

[BenFradet]

Better yet would be to split uuid-based requests from vendor prefix-based requests:

• On the one hand, you would have:

/api/apikeys/keys/some-uuid

For retrieving the vendor prefix associated with an uuid or deleting this specific key.

• And on the other hand, there would be requests like this one:

/api/apikeys/vendorprefixes/some.vendor.prefix

To create a pair of api keys, deleting them or retrieving them.

Which is the best approach in your opinion?

[alexanderdean]

What's the relationship in the db between vendor prefixes and keys. Many to one or what?

[BenFradet]

A vendor prefix can have at most two (read and write) api keys and obviously an api key can only have one vendor prefix

[alexanderdean]

Then yes I like the latter approach

[BenFradet]

Ok thanks for your input.