├── 2020 └── IDEAS.md ├── 2021 └── Ideas.md ├── LICENSE └── README.md /2020/IDEAS.md: -------------------------------------------------------------------------------- 1 | Postman in Google Summer of Code 2020 - Ideas 2 | ============================================= 3 | 4 | ## Project Ideas 5 | 6 | We accept original ideas and proposals for every project. Following is a list of ideas which you can use as a reference. 7 | 8 | ### Newman 9 | 10 | * **Newman login**: Add support for a new `newman login` command to be an alternative to the conventional way of using cloud URLs to run collections. It will allows users to login with their API key from CLI and simply run collections by providing their unique IDs. This will also require dedicated security considerations to ensure safety of user's Postman API key. 11 | 12 | * **Create new or update existing reporters**: Newman reporters provide information about the current collection run in a format that is easy to both: disseminate and assimilate. Create new external reporters or update existing reporters like `newman-reporter-html`. Working examples of how Newman reporters work can be found here - https://github.com/postmanlabs/newman/tree/develop/lib/reporters 13 | 14 | * **Ability to execute individual requests**: Currently, you can run entire Postman collections. Add the capability the run a single request - not the whole collection. 15 | 16 | ### Collection SDK + Runtime 17 | * **Support for more request body methods**: Add support for different request body serialization techniques like Protocol Buffers, JSON RPC, etc. in Postman runtime library. Support for protobuf is one of the most request feature from our comunity - https://github.com/postmanlabs/postman-app-support/issues/2801 18 | 19 | * **Support for different authentication schemes**: Add support for different authentication schemes like JWT, NTLM Kerberos, etc. 20 | Steps to be done to add a new auth mechanism https://github.com/postmanlabs/postman-runtime/blob/develop/docs/new-auth-mechanisms.md 21 | 22 | * **Support for RSA-SHA1 signature method in OAuth1**: Add support for RSA-SHA1 signature method in Runtime OAuth1 helper as requested in - https://github.com/postmanlabs/postman-app-support/issues/2302 23 | 24 | ### Code Generators 25 | 26 | * **Collection-level codegen**: Convert a Postman collection to a client SDK. Work on a module that utilizes Postman's existing code-generators to create an SDK for an entire collection, not just a request. This could be extremely beneficial to advanced users. 27 | 28 | * **Generate an Axios/Superagent snippet from a Postman request**: This is a very popular feature request from our community - https://github.com/postmanlabs/postman-app-support/issues/3822 and https://github.com/postmanlabs/postman-app-support/issues/6331, and could help solve use-cases for a lot of users. 29 | 30 | ### Importers 31 | 32 | * **Support for Links in OpenAPI3**: Links are an OpenAPI feature that provide the ability to define custom workflows. This fits in well with Postman's collections, where you can use the in-built API to create branching/looping in workflows. If implemented correctly, links could truly bridge the gap between a workflow definition in OAS, and a working collection in Postman. 33 | 34 | * **SoapUI conversion to Postman's collection format**: SoapUI is a popular SOAP API platform. It supports WSDL export, and that's something we'd like to include as a format Postman supports. WSDL is really extensive, so this will require research around what's possible with WSDL, and how you'd want to perform the conversion. 35 | 36 | * **AsyncAPI conversion to Postman's collection format**: AsyncAPI is an upcoming schema format that supports messaging-based API communication patterns. It's a relatively new format, and a working converter would require a thorough exploration of webhooks and Postman features you'd like to implement from a spec. 37 | 38 | ## Contact 39 | 40 | If you have any questions or queries please create an issue on this project (with a prefix GSoC 2020) or send an email to us at gsoc@postman.com 41 | -------------------------------------------------------------------------------- /2021/Ideas.md: -------------------------------------------------------------------------------- 1 | Postman in Google Summer of Code 2021 - Ideas 2 | ============================================= 3 | 4 | ## Project Ideas 5 | 6 | We accept original ideas and proposals for every project. Following is a list of ideas which you can use as a reference. 7 | 8 | 9 | ### Idea 1: Newman Request 10 | Newman already makes it effortless for you to run Postman collections. It enables you to see the results with your favourite reporters on CLI, as JSON, HTML etc. making it easy to summarise data and at the same time, use it in automations and build systems. But currently, it is limited to only running a collection of requests. This project aims to enable users to use these same capabilities for a single request. 11 | 12 | **Expected outcome**
13 | Users can send a single request with Newman and show the request/response using a reporter of their choice.
14 | Replacing curl with newman request in a curl command should run the send the request using Newman.
15 | If user is logged in, the request should show up in Postman app’s History in sidebar.
16 | 17 | **Relevant skills**
18 | JavaScript language
19 | Understanding of HTTP protocol.
20 | curl
21 | 22 | **Complexity**: low

23 | 24 | ### Idea 2: Parallel Iterations in Newman
25 | Newman supports running multiple iterations of a collection with different data provided in a CSV or JSON file, enabling users to test an API against multiple scenarios. But Newman executes each iteration serially and this can take a lot of time as the number of requests in a collection and iterations grow. This project aims to bring parallelism into Newman by splitting the iterations data into multiple chunks and running them as threads to bring down the total time roughly by a factor of n, where n is the number of threads. 26 | 27 | **Expected outcome**
28 | Newman can split iteration data and run multiple runs using this data.
29 | Users can specific the number of parallel iterations that Newman can run.
30 | 31 | **Relevant skills**
32 | JavaScript language
33 | Understanding of threads and processes communication
34 | 35 | **Complexity**: low

36 | 37 | ### Idea 3: Newman Dashboard
38 | Newman has an array of reporters that consume the run data that Newman provides. These include viewing a run in the terminal using CLI, as JSON which can be easily transported by a build system, as an HTML summary webpage, and many more. However, Newman lacks a way to control the runs in a central dashboard. This project aims to create a dashboard on a browser which can be used to start, resume, pause and stop Newman runs. 39 | 40 | **Expected outcome**
41 | A dashboard can be opened on a browser which shows currently running Newman runs.
42 | The dashboard can be used to start, stop, pause and stop any Newman run.
43 | There is an option in Newman to connect to the dashboard and wait for run to be started by the dashboard.
44 | 45 | **Relevant skills**
46 | JavaScript language
47 | Understanding of daemons and IPC (websockets is a plus).
48 | Basic understanding of HTML, CSS
49 | 50 | **Complexity**: medium

51 | 52 | ### Idea 4: API-First Blueprint for a Commerce API
53 | Building out an OpenAPI, mock, documentation, testing, and deployment of a commerce (or other) API that uses the Schema.org (http://Schema.org) as the underlying schema, providing a functioning and well documented example of what an API can be. 54 | 55 | **Use case:**
56 | Increasing the number of API blueprints that could serve as learning material for individuals/teams working on an API first approach.
57 | An API blueprint could be useful for anyone to hit the ground running when building a Commerce API.
58 | 59 | **Required knowledge:**
60 | Understanding of the API first philosophy - https://www.postman.com/use-cases/api-first-development/.
61 | Comfort with YAML/JSON formats.
62 | Understanding of API lifecycle phases - Design, Document, Test

63 | 64 | 65 | ### Idea 5: API Conversion API
66 | Aggregating all of the OpenAPI conversion tooling that exists out there into a single API conversion solution that will convert all API formats similar to API Transformer - https://www.apimatic.io/transformer/, publishing as a single API that can be hosted and operated by anyone as an open source conversion solution. 67 | 68 | **Use case:**
69 | There is no open source solution that provides conversion among all formats in one place. There are a lot of open source CLI tools - https://github.com/postmanlabs/openapi-to-postman, https://github.com/postmanlabs/swagger2-postman2, APIs, apps that have converters but the idea is to have a common interface for all of them. 70 | 71 | **Required knowledge:**
72 | Depends on the tech stack used by existing converters
73 | Comfortable with building APIs and learning how to build an API on top of existing converters
74 | Exposure to frontend technologies to build the UI for the conversions.
75 | Willingness to learn about different API formats - swagger, raml, openapi

76 | 77 | 78 | ### Idea 6: Contributing to Postman Public Workspace
79 | https://www.postman.com/api-evangelist/workspace/openapi/overview
80 | 81 | The workspace above has a list of tasks/ideas that could serve as utilities for managing OpenAPI specifications eg. cleanup tasks, adding default responses. 82 | Similarly, there are other public workspaces:
83 | Managing Postman collections - https://www.postman.com/api-evangelist/workspace/collections/overview
84 | Managing Postman environments - https://www.postman.com/api-evangelist/workspace/environments/overview
85 | 86 | **Expectation:**
87 | Build utilities for managing Postman entities (OpenAPI definitions/collections/environments). These utilities could be scripts embedded in Postman requests/collections or an open source project eg. openapi-utils. 88 | 89 | **Required knowledge:**
90 | Should be familiar with or willing to learn how to use the Postman API, OpenAPI concepts. Hands-on experience with Javascript is necessary. Some familiarity with version control (https://learning.postman.com/docs/collaborating-in-postman/version-control-for-collections/) in Postman would help in managing contributions.

91 | 92 | ### Idea 7: Simple schema registry
93 | Provide a simple implementation of the schema registry API (https://github.com/cloudevents/spec/blob/master/schemaregistry/schemaregistry.md) and showcase how this can be used with AsyncAPI document and schema references. It can do an in-memory persistence for schemas as it would be used purely for showcases, and learning materials. 94 | 95 | **Use case:**
96 | In AsyncAPI file you can provide schemas for the payload of the message. Those schemas can be shared between different applications, meaning, different AsyncAPI files. Schema registries that store such shareable schemas are becoming a de-facto standard. Would be great to have a simple mock implementation of such a schema to show how it would work with AsyncAPI documents. 97 | 98 | **Required knowledge:**
99 | You do not need any specific deep knowledge of any subject here. You will only have to provide an implementation of this API (https://github.com/cloudevents/spec/blob/master/schemaregistry/schemaregistry.yaml). It is not supposed to be a production-ready implementation, but only for testing and showcasing. Knowledge about how to use this registry with AsyncAPI is something that you can learn while working on the task with mentor support. There is not specific repository where you can place the code. It is something that can be decided anytime during development.

100 | 101 | ### Idea 8: Duplications discovery - optimizer
102 | Build a library that code-first users would benefit from the most but not only. A library that as the input gets AsyncAPI document and as output provides optimized AsyncAPI document.

103 | For example:
104 | Reuse of components
105 | Duplicated schemas moved to components and ref-ed from a message
106 | Remove not used components
107 | The goal is to shrink the document to a minimum. There should be flags to disable specific parts of optimization, like removal of not used components for example. 108 | 109 | **Use case:**
110 | AsyncAPI offers many different ways to reuse certain parts of the document like messages or schemas definitions or references to external files, not to even mention the traits. There is a need for a tool that can be plugged into any workflows and optimize automatically documents that are generated from code. 111 | 112 | **Required knowledge:**
113 | This task will require you to learn some details about the AsyncAPI spec to understand what parts can be componentized and how reuse works in the spec. This knowledge will be essential to be able to apply optimizations. You will for sure have to go through our getting stated (https://www.asyncapi.com/docs/getting-started) guides and later the spec (https://www.asyncapi.com/docs/specifications/2.0.0). Mentors will be available for any questions and setting directions. 114 | We already started work on the CLI so before summer there will be enough to plug in this functionality https://github.com/asyncapi/cli

115 | 116 | ### Idea 9: AsyncAPI Diff
117 | A library that as the input gets two AsyncAPI documents and shows changes between them. As an output, you get json pointers to sections that are different. The main purpose of such a tool is a changelog where you can present to the user what has changed between v1 and v2 of the document. Some ideas can be picked up from https://github.com/OpenAPITools/openapi-diff
118 | We basically need a library that can be later used to build such a UI (http://www.jsondiff.com/) 119 | 120 | **Use case:**
121 | The result of diff is a part of changelog/release notes, so users can easily spot what parts of the document changed so they can understand how affected they are by the change
122 | Diff is needed in a review process, so the reviewer gets an overview of specification changes 123 | 124 | **Required knowledge:**
125 | There is not much knowledge about the spec itself needed. It is about pointing out differences in 2 different files, but not as pointing what lines changed but in general what objects changed. So if there was an update in payload, the library must specify what channel in what message got updated (with json pointers most probably). You can familiarize with other tools that do it already for other specifications. 126 | We already started work on the CLI so before summer there will be enough to plug in this functionality https://github.com/asyncapi/cli

127 | 128 | ### Idea 10: AsyncAPI Applications Relations Finder
129 | A library that as the input gets a list of AsyncAPI documents and analyzes them to get information about Applications described by those files:
130 | If they subscribe or publish to the same channels
131 | If one subscribes to a channel that the other one publishes to
132 | If there are apps that are subscribed to channels that no one publishes too
133 | As an output, we should get a format that can be used to generate a diagram of relations between applications with additional metadata information about them (message, schemas).
134 | 135 | **Use case:**
136 | Visualization of the architecture and understanding what happens with the system if one of the puzzles is removed.
137 | Later on, we could use this library in AsyncAPI CLI and also the AsyncAPI Studio.
138 | 139 | **Required knowledge:**
140 | There is no need to have any experience in event-driven architecture. You do not even need to know AsyncAPI spec too much. It is a pure coding task where you will need to find matching patterns between different documents and return this information. You will have the full support of the mentor on the subject. Mentors will define requirements, etc.
141 | There is no decision yet if this is a library that will have to live in a separate repository or be a part of an existing CLI or UI project.

142 | We already started work on the CLI so before summer there will be enough to plug in this functionality asyncapi/cli (https://github.com/asyncapi/cli)

143 | 144 | ### Idea 11: AsyncAPI Extensions registry
145 | Provide an implementation of the extensions registry for AsyncAPI. This task includes action points:
146 | - improve the shape/definition of the single extension (describe it by JSON Schema) - reference asyncapi/extensions-catalog (https://github.com/asyncapi/extensions-catalog)
147 | - like for schema registry: implement an extensions registry API
148 | - add support in parser-js
149 | - -asyncapi/parser-js (https://github.com/asyncapi/parser-js)- for validation of extension against provided extension schema

150 | 151 | **Required knowledge:**
152 | The main contribution will go into the parser. So you will have to first onboard on the project with few basic tasks handed over by the mentor. The rest will be explained by the mentor.

153 | 154 | ### Idea 12: Chatbot for AsyncAPI creators
155 | Explore how we could help people to write the spec document without knowing the specification. Prepare a kind of prototype. Instead of learning the spec, users talk to a chatbot, and as a result of the conversation, they get an AsyncAPI document generated. The chatbot should learn from the specification what are the possible solutions and options. 156 | 157 | **Use case:**
158 | Learning the AsyncAPI spec (https://github.com/asyncapi/asyncapi/blob/master/versions/2.0.0/asyncapi.md) can be a time-consuming process. This is what causes learning of every new specification hard. Let’s explore if we can have a machine that can consume the spec, its JSON schema and serve the users as an expert. Based on a set of questions and answers it should generate an AsyncAPI document for the user.
159 | 160 | Example conversation: (real-time we show a preview of the AsyncAPI document that will be generated)
161 | Bot: what do you want to describe?
162 | User: app that connects with kafka?
163 | Bot: can you provide some more details about the kafka server? Like the url?
164 | User: no
165 | Bot: no problem, let us skip the server details for now. What topics does your app subscribe to?
166 | 167 | **Visible challenges:**
168 | Vocabulary: bot needs to know that AsyncAPI channels mean topic in Kafka
169 | Real-time object generation
170 | Vocabulary: understand that bot needs to ask questions “subscribe to” but in document write it as “publish” operation
171 | 172 | **Required knowledge:**
173 | This project requires you to have a basic knowledge about the location of spec related materials that could be used to feed the bot. This is a research task that only requires a prototype to see if this is even possible or what is missing to make it possible. As prerequisite you of course need to read about current technologies that are available for building a chatbot.

174 | 175 | ### Idea 13: AsyncAPI application simulation
176 | A simulation library that can trigger events in your applications based on AsyncAPI definition(s). The main purpose is to stimulate your application(s) in a development environment (staging?). Use it for stress testing, hunting down concurrency problems, stimulating visual applications, finding scalability issues in your application and more.

177 | You provide one or more AsyncAPI files
178 | You decide which channel(s) and applications should be stimulated and with which parameters.
179 | The library simulates messages to the application(s) based on the parameters, in the given protocol described in the AsyncAPI file.
180 | Inspect the application(s) and their state to figure out if errors occurred etc 181 | 182 | **Extra thoughts: **
183 | Can it be used directly in a system test so you can decide on the expected outcome?

184 | 185 | **Required knowledge:**
186 | You need to learn the spec basics (what channels are). It will be useful to learn first how to set up environments with Docker compose and mocks and a proper testing environment will have to be created first to work on the implementation and load generation. 187 | 188 | 189 | -------------------------------------------------------------------------------- /LICENSE: -------------------------------------------------------------------------------- 1 | Apache License 2 | Version 2.0, January 2004 3 | http://www.apache.org/licenses/ 4 | 5 | TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION 6 | 7 | 1. Definitions. 8 | 9 | "License" shall mean the terms and conditions for use, reproduction, 10 | and distribution as defined by Sections 1 through 9 of this document. 11 | 12 | "Licensor" shall mean the copyright owner or entity authorized by 13 | the copyright owner that is granting the License. 14 | 15 | "Legal Entity" shall mean the union of the acting entity and all 16 | other entities that control, are controlled by, or are under common 17 | control with that entity. For the purposes of this definition, 18 | "control" means (i) the power, direct or indirect, to cause the 19 | direction or management of such entity, whether by contract or 20 | otherwise, or (ii) ownership of fifty percent (50%) or more of the 21 | outstanding shares, or (iii) beneficial ownership of such entity. 22 | 23 | "You" (or "Your") shall mean an individual or Legal Entity 24 | exercising permissions granted by this License. 25 | 26 | "Source" form shall mean the preferred form for making modifications, 27 | including but not limited to software source code, documentation 28 | source, and configuration files. 29 | 30 | "Object" form shall mean any form resulting from mechanical 31 | transformation or translation of a Source form, including but 32 | not limited to compiled object code, generated documentation, 33 | and conversions to other media types. 34 | 35 | "Work" shall mean the work of authorship, whether in Source or 36 | Object form, made available under the License, as indicated by a 37 | copyright notice that is included in or attached to the work 38 | (an example is provided in the Appendix below). 39 | 40 | "Derivative Works" shall mean any work, whether in Source or Object 41 | form, that is based on (or derived from) the Work and for which the 42 | editorial revisions, annotations, elaborations, or other modifications 43 | represent, as a whole, an original work of authorship. For the purposes 44 | of this License, Derivative Works shall not include works that remain 45 | separable from, or merely link (or bind by name) to the interfaces of, 46 | the Work and Derivative Works thereof. 47 | 48 | "Contribution" shall mean any work of authorship, including 49 | the original version of the Work and any modifications or additions 50 | to that Work or Derivative Works thereof, that is intentionally 51 | submitted to Licensor for inclusion in the Work by the copyright owner 52 | or by an individual or Legal Entity authorized to submit on behalf of 53 | the copyright owner. For the purposes of this definition, "submitted" 54 | means any form of electronic, verbal, or written communication sent 55 | to the Licensor or its representatives, including but not limited to 56 | communication on electronic mailing lists, source code control systems, 57 | and issue tracking systems that are managed by, or on behalf of, the 58 | Licensor for the purpose of discussing and improving the Work, but 59 | excluding communication that is conspicuously marked or otherwise 60 | designated in writing by the copyright owner as "Not a Contribution." 61 | 62 | "Contributor" shall mean Licensor and any individual or Legal Entity 63 | on behalf of whom a Contribution has been received by Licensor and 64 | subsequently incorporated within the Work. 65 | 66 | 2. Grant of Copyright License. Subject to the terms and conditions of 67 | this License, each Contributor hereby grants to You a perpetual, 68 | worldwide, non-exclusive, no-charge, royalty-free, irrevocable 69 | copyright license to reproduce, prepare Derivative Works of, 70 | publicly display, publicly perform, sublicense, and distribute the 71 | Work and such Derivative Works in Source or Object form. 72 | 73 | 3. Grant of Patent License. Subject to the terms and conditions of 74 | this License, each Contributor hereby grants to You a perpetual, 75 | worldwide, non-exclusive, no-charge, royalty-free, irrevocable 76 | (except as stated in this section) patent license to make, have made, 77 | use, offer to sell, sell, import, and otherwise transfer the Work, 78 | where such license applies only to those patent claims licensable 79 | by such Contributor that are necessarily infringed by their 80 | Contribution(s) alone or by combination of their Contribution(s) 81 | with the Work to which such Contribution(s) was submitted. If You 82 | institute patent litigation against any entity (including a 83 | cross-claim or counterclaim in a lawsuit) alleging that the Work 84 | or a Contribution incorporated within the Work constitutes direct 85 | or contributory patent infringement, then any patent licenses 86 | granted to You under this License for that Work shall terminate 87 | as of the date such litigation is filed. 88 | 89 | 4. Redistribution. You may reproduce and distribute copies of the 90 | Work or Derivative Works thereof in any medium, with or without 91 | modifications, and in Source or Object form, provided that You 92 | meet the following conditions: 93 | 94 | (a) You must give any other recipients of the Work or 95 | Derivative Works a copy of this License; and 96 | 97 | (b) You must cause any modified files to carry prominent notices 98 | stating that You changed the files; and 99 | 100 | (c) You must retain, in the Source form of any Derivative Works 101 | that You distribute, all copyright, patent, trademark, and 102 | attribution notices from the Source form of the Work, 103 | excluding those notices that do not pertain to any part of 104 | the Derivative Works; and 105 | 106 | (d) If the Work includes a "NOTICE" text file as part of its 107 | distribution, then any Derivative Works that You distribute must 108 | include a readable copy of the attribution notices contained 109 | within such NOTICE file, excluding those notices that do not 110 | pertain to any part of the Derivative Works, in at least one 111 | of the following places: within a NOTICE text file distributed 112 | as part of the Derivative Works; within the Source form or 113 | documentation, if provided along with the Derivative Works; or, 114 | within a display generated by the Derivative Works, if and 115 | wherever such third-party notices normally appear. The contents 116 | of the NOTICE file are for informational purposes only and 117 | do not modify the License. You may add Your own attribution 118 | notices within Derivative Works that You distribute, alongside 119 | or as an addendum to the NOTICE text from the Work, provided 120 | that such additional attribution notices cannot be construed 121 | as modifying the License. 122 | 123 | You may add Your own copyright statement to Your modifications and 124 | may provide additional or different license terms and conditions 125 | for use, reproduction, or distribution of Your modifications, or 126 | for any such Derivative Works as a whole, provided Your use, 127 | reproduction, and distribution of the Work otherwise complies with 128 | the conditions stated in this License. 129 | 130 | 5. Submission of Contributions. Unless You explicitly state otherwise, 131 | any Contribution intentionally submitted for inclusion in the Work 132 | by You to the Licensor shall be under the terms and conditions of 133 | this License, without any additional terms or conditions. 134 | Notwithstanding the above, nothing herein shall supersede or modify 135 | the terms of any separate license agreement you may have executed 136 | with Licensor regarding such Contributions. 137 | 138 | 6. Trademarks. This License does not grant permission to use the trade 139 | names, trademarks, service marks, or product names of the Licensor, 140 | except as required for reasonable and customary use in describing the 141 | origin of the Work and reproducing the content of the NOTICE file. 142 | 143 | 7. Disclaimer of Warranty. Unless required by applicable law or 144 | agreed to in writing, Licensor provides the Work (and each 145 | Contributor provides its Contributions) on an "AS IS" BASIS, 146 | WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or 147 | implied, including, without limitation, any warranties or conditions 148 | of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A 149 | PARTICULAR PURPOSE. You are solely responsible for determining the 150 | appropriateness of using or redistributing the Work and assume any 151 | risks associated with Your exercise of permissions under this License. 152 | 153 | 8. Limitation of Liability. In no event and under no legal theory, 154 | whether in tort (including negligence), contract, or otherwise, 155 | unless required by applicable law (such as deliberate and grossly 156 | negligent acts) or agreed to in writing, shall any Contributor be 157 | liable to You for damages, including any direct, indirect, special, 158 | incidental, or consequential damages of any character arising as a 159 | result of this License or out of the use or inability to use the 160 | Work (including but not limited to damages for loss of goodwill, 161 | work stoppage, computer failure or malfunction, or any and all 162 | other commercial damages or losses), even if such Contributor 163 | has been advised of the possibility of such damages. 164 | 165 | 9. Accepting Warranty or Additional Liability. While redistributing 166 | the Work or Derivative Works thereof, You may choose to offer, 167 | and charge a fee for, acceptance of support, warranty, indemnity, 168 | or other liability obligations and/or rights consistent with this 169 | License. However, in accepting such obligations, You may act only 170 | on Your own behalf and on Your sole responsibility, not on behalf 171 | of any other Contributor, and only if You agree to indemnify, 172 | defend, and hold each Contributor harmless for any liability 173 | incurred by, or claims asserted against, such Contributor by reason 174 | of your accepting any such warranty or additional liability. 175 | 176 | END OF TERMS AND CONDITIONS 177 | 178 | APPENDIX: How to apply the Apache License to your work. 179 | 180 | To apply the Apache License to your work, attach the following 181 | boilerplate notice, with the fields enclosed by brackets "[]" 182 | replaced with your own identifying information. (Don't include 183 | the brackets!) The text should be enclosed in the appropriate 184 | comment syntax for the file format. We also recommend that a 185 | file or class name and description of purpose be included on the 186 | same "printed page" as the copyright notice for easier 187 | identification within third-party archives. 188 | 189 | Copyright [yyyy] [name of copyright owner] 190 | 191 | Licensed under the Apache License, Version 2.0 (the "License"); 192 | you may not use this file except in compliance with the License. 193 | You may obtain a copy of the License at 194 | 195 | http://www.apache.org/licenses/LICENSE-2.0 196 | 197 | Unless required by applicable law or agreed to in writing, software 198 | distributed under the License is distributed on an "AS IS" BASIS, 199 | WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. 200 | See the License for the specific language governing permissions and 201 | limitations under the License. 202 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 |
2 | 3 | # Postman Google Summer Code 4 | 5 | This repository contains information about Postman's open source projects in Google Summer of Code.
6 | Also, check out AsyncAPI which has joined hands with Postman -- https://github.com/asyncapi 7 | 8 | # Communication 9 | 10 | Join our community here to interact with our mentors and discuss your project ideas
11 | Read the guidelines here - https://community.postman.com/t/gsoc-2021-guidelines/ 12 | 13 | * Create an issue on this project if you're unable to get a response from the community 14 | * Start a new idea under discussions only once you've frozen on your project proposal. 15 | * Send us an email at gsoc@postman.com for any administrative or operational concerns regarding the program 16 | --------------------------------------------------------------------------------