Will a checklist approach work for APIs ?

bala
Participant II

When you have cross-functional team working on APIs and API programs, is a checklist approach a simple way to keep the teams aligned on the creating and managing the APIs ? Would love to hear your feedback and experiences. Also, if you can, please join me on Tuesday (Mar 15th, 10am PT) for the webcast. https://pages.apigee.com/2016-03-15-Webcast-Checklist-for-API-Call-reg.html

Solved Solved
0 5 885
1 ACCEPTED SOLUTION

bala
Participant II

Thanks to all of you who attended the webcast this morning. Would love to hear your perspectives on how and where you use checklists in your API lifecycle. We will post the slides and the video of the webcast shortly.

View solution in original post

5 REPLIES 5

bala
Participant II

Thanks to all of you who attended the webcast this morning. Would love to hear your perspectives on how and where you use checklists in your API lifecycle. We will post the slides and the video of the webcast shortly.

bala
Participant II

Thanks to all of you who attended the webcast this morning. Would love to hear your perspectives on how and where you use checklists in your API lifecycle. We will post the slides and the video of the webcast shortly.

bala
Participant II

The slides and the webcast recording is live now here

Please share your comments and perspectives here to continue the conversation.

bala@apigee.com

I am part of a team which has around 7 to 8 different development team. For maintaining the same standard among diff team we have created below documents and tools:-

1) Similar Format for Message Logging policy across all the proxies

2) Separate OAUTH Proxies which can be invoked by any other proxy using Service call out

3) A document which has naming standards like Assign Message header policy name should be

AMH_<SET/GET>_<Logical Task>

4) Main development team for reviewing the Proxy. So once the Proxy is created by team. Internal reviews are done and before moving to higher Environment( i.e. PERF, TEST, PROD) the code is reviewed by Main development team. This ensures that the code is similar across various teams.

5) Also, maintaining one doc which has API PROXIES details i.e. API PRODUCT , DEVELOPER APP, CONSUMER, PROVIDER, VHOST , VIP, TRUSSTORE name in case of 2way ssl, etc for that proxy.

Thanks for sharing this. BTW on #4 - have you folks broken it down further in the critical review steps instead of leaving it to the code reviewer ? Are there any specific patterns that have broken the proxy in the past that you want to catch ?