Paw Document Repository?

Question

I'm still struggling a bit with how to use and organize Paw files (*.paw documents), particularly as an API consumer. Is it smarter to:

1. Organize by project (i.e. project A consumes these particular API calls, so create a my-project.paw document for that project/client); or

2. Organize by API service (i.e. a MailChimp.paw document defining the various MailChimp endpoints, then add new environments for each project that consumes the MailChimp API)?

(As a side note, it would be great if there were a public repository for sharing .paw files for popular APIs!)

Answer 1

There's no rule, you may organize stuff as it fits to your use case, but I'd recommend organizing files around APIs, so it's all ordered around the given API, following its standard, groupping requests depending on the resources served by the API. One tree example would be:

My-Blog-API.paw

• Users (a group)
  • Get one user (GET /users/:id)
  • Create user (POST /users)
• Articles (a group)
  • Get list of articles (GET /articles)
  • Get one article (GET /articles/:id)
  • Create article (POST /articles)

This way your document closely follows the semantic of the API. Also, it allows a good organization of your Environments, to store for example the Base URL of your API, or the user credentials/access token(s).

Though, maybe I'd keep a "Related" folder for calls to 3rd party services needed for the API calls. For example, you may want to have a call to the Twitter API to get an access token, you'd pass then to your API for the "login with Twitter" feature.

• Related (a group)
  • Twitter (a group)
    • Login with Twitter (GET https://api.twitter.com/login – whatever I don't know the exact URL)

(Also, thanks for the idea of creating a public repo, some have shared Paw collections on their website, but it would be nice!)