Hi Peter,
Need some clarification on the project structure and good practices in general. Our org is moving to microservices architecture so we are in the process of creating tonnes of small api's. Project structure I am thinking in karate would be something like below. Can you please let me know if this looks OK or would you improve on this?
Master Folder (com.company.something)
|
+-- master-karate-config.js (something applicable to all api folder)
+-- mster-reusable.feature (something applicable to all api folder)
+-- master-classpath-function.js (something applicable to all api folder)
|
-- API-1
| |
| +-- API-1-post.feature
| +-- API-1-get.feature
| +-- API-1.json
| -- API-1-runner.java
|
|
-- API-2
| |
| +-- API-2-post.feature
| +-- API-2-get.feature
| +-- API-2.json
| -- API-2-runner.java
|
Screenshot below

Great to see you thinking through this carefully. This looks ok at first glance. I would personally avoid attempting to have a single "master" especially for the karate-config.js because that would tightly couple all the api-s, or every team will need to clobber it - as well as their respective API folder.
But to kind of contradict what I said above - I would also suggest starting with a single project and have sub-folders for each API - and then consider splitting out later, since it should be reasonably easy to do if this does not scale. Note that you can use tags so that you can run only some tests at a time. If you use folders wisely, you can have a *Test.java class that is responsible for each API-etc. The advantage here is that re-use of "common" utilities will be easy.
Later if you need to scale - you would have now figured out what functions need to be in a "common" re-usable project. And then you can invest time into making that a maven-module that all other projects depend on. Reusing JS functions (or even feature files) is easy, they just need to exist on the classpath.
So my opinion is try to defer the decision as to what should be "common" for later. Hope that helps.
Thanks peter. This does helps. Appreciate it
Follow up questions.
1) Each API should have its own karate-config.js in its respective folder. Is that correct?
2) Right now I created empty project in intellij and under that project I am adding IDEA modules using karate archetype(like sub-folder) for each API. Does that makes sense?
Another question around headers- many of our api's have following header structure
Content-Type - Some value
TrackingiD - Some random value
Token - some value
For certain tests like security/validation I want to pass different token value in header (expired token, bad token, null etc) and ensure it returns expired or unauthorized message.
Can I just put the first two header values in background and explicitly pass token as separate header value for each test?
Answer to the last question is yes. Try it out. Look at the demo examples and doc.
For 1 and 2 - you can do this if you want - but my previous comment suggested that you should start with one "flat" project and have sub folders for each API. You can convert to modules later. Can you re-read my comment and see if it makes sense.
Ahh...ok. That's what I earlier thought. What you are saying is gonna look something like below. This example is taken from your guideline and I believe "animals" here is one of the API and cats and dogs are different end point. From what I have tried it looks like I cannot place config file directly under API folder and has to be placed under Java folder which means I can only have one config file. I am unsure how to configure the structure so to have config and header file for each API.
src/test/java
|
+-- karate-config.js
+-- logback-test.xml
+-- some-reusable.feature
+-- some-classpath-function.js
+-- some-classpath-payload.json
|
-- animals (API-1)
|
+-- AnimalsTest.java
|
+-- cats
| |
| +-- cats-get.feature
| +-- cat.json
| -- CatsRunner.java
|
-- dogs
|
+-- dog-crud.feature
+-- dog.json
-- DogsRunner.java
|
-- zoo (API-2)
|
+-- ZooTest.java
|
+-- Someendpoint
| |
| +--get.feature
To be clear I am actually recommending you start with only one karate-config.js for all your API-s. In my honest opinion, it won't be complicated. Even if the file fills up with multiple lines, the number of times teams need to edit it is very small compared to the actual feature files. Does that make sense ?
Yeah I understand now. Let me try that and see how it works out. Thanks for your patience.