For a large api the postman suite can become quite cumbersome to navigate, it would be easier if the routes were grouped by; Resource and ApiResource, this can be extended further by looking at the prefixes and groups inside the routes file.
It would also be nice if the routes were grouped if they are nested; for example if the route has the name "posts.comments" there should be a directory with /posts/comments/{get},{post},{put},{delete}.
One way you could approach this is by taking the route name for each $uri in the route processor and checking if there are multiple instances of the same route name per nesting level. So if your route name is posts.comments you could check for all the occurrences on posts by exploding the routename and grouping these together. If there are more matches on posts.comments for example on a CRUD api with a resource route you can bundle these inside
/posts with a sub-directory named /comments etc.
Some users may not want this, so possibly also add a flag --flat to avoid mapping/grouping.
The combination of these two idea's would be the icing on the cake for this package!
For a large api the postman suite can become quite cumbersome to navigate, it would be easier if the routes were grouped by; Resource and ApiResource, this can be extended further by looking at the prefixes and groups inside the routes file.
It would also be nice if the routes were grouped if they are nested; for example if the route has the name "posts.comments" there should be a directory with /posts/comments/{get},{post},{put},{delete}.
One way you could approach this is by taking the route name for each
$uri
in the route processor and checking if there are multiple instances of the same route name per nesting level. So if your route name isposts.comments
you could check for all the occurrences onposts
by exploding the routename and grouping these together. If there are more matches onposts.comments
for example on a CRUD api with a resource route you can bundle these inside/posts
with a sub-directory named/comments
etc.Some users may not want this, so possibly also add a flag
--flat
to avoid mapping/grouping.The combination of these two idea's would be the icing on the cake for this package!