API vs Routes/Services difference

One thing in the past that I ended up liking but was not documented was that consumers and api resources could have their id (uuid) passed in on the POST requests if we so chose too for creation, rather than Kong assigning a uuid itself. I have tested and verified in the newer introduced routes/services this is not possible, if I pass in my own random generated uuid that has not been used in the table it still creates my route but will not do it based on the uuid I passed in.

In implementation I prefer to simply verify the transaction was successful on REST calls via the HTTP status as opposed to parsing the body, getting Kong’s generated UUID and then working with that to insert into a db of our own accord for some external auditing/tooling.

Is there any reason this functionality was dropped for route/service creation? Would Kong consider letting the id be passed in on a REST transaction to create the routes/service object much like the consumer/now deprecated api resources? It makes it easier on people trying to integrate with Kong with external apps.

1 Like

Yes, we are going to implement PUT /services/{service_id} and PUT /routes/(route_id), but we don’t have that just yet. Sorry for inconvenience.

2 Likes

Great! Glad to know its on the short term road-map :slight_smile: . Will reorganize my code so I am ready for PUT methods like so. As I understand PUT will Create or Update if exists so I will have to take that into consideration too.