Git Product home page Git Product logo

docs's Introduction

docs

Automatically generate RESTful API documentation for GO projects - aligned with Open API Specification standard.

GolangCI Build Version Go Report Card Coverage Status codebeat badge Go Reference Mentioned in Awesome Go

go-OAS Docs converts structured OAS3 (Swagger3) objects into the Open API Specification & automatically serves it on chosen route and port. It's extremely flexible and simple, so basically it can be integrated into any framework or existing project.

We invite anyone interested to join our GH Discussions board. Honest feedback will enable us to build better product and at the same time not waste valuable time and effort on something that might not fit intended usage. So if you can, please spare few minutes to give your opinion of what should be done next, or what should be the priority for our roadmap. ๐Ÿ’ช ๐ŸŽ‰


Table of Contents

Getting Started

  1. Download docs by using:
    $ go get -u github.com/go-oas/docs
  2. Add one line annotation to the handler you wish to use in the following format: // @OAS <FUNC_NAME> <ROUTE> <HTTP_METHOD> Examples:
    // @OAS handleCreateUser /users POST
    // @OAS handleGetUser /users GET
    
  3. Declare all required documentation elements that are shared. Or reuse ones that already exist in the examples directory.
  4. Declare specific docs elements per route.

How to use

For more explicit example, please refer to docs/examples

Add OAS TAG to your existing handler that handles fetching of a User:

package users

import "net/http"

// @OAS handleGetUser /users GET
func (s *service) handleGetUser() http.HandlerFunc {
	return func(w http.ResponseWriter, r *http.Request) {
	}
}

Create a unique API documentation function for that endpoint:

package main

import "github.com/go-oas/docs"

func handleGetUserRoute(oasPathIndex int, oas *docs.OAS) {
	path := oas.GetPathByIndex(oasPathIndex)

	path.Summary = "Get a User"
	path.OperationID = "getUser"
	path.RequestBody = docs.RequestBody{}
	path.Responses = docs.Responses{
		getResponseOK(),
	}

	path.Tags = append(path.Tags, "pet")
}

Bear in mind that creating a unique function per endpoint handler is not required, but simply provides good value in usability of shared documentation elements.

Once you created the function, simply register it for parsing by using AttachRoutes() defined upon OAS structure. E.g.:

package main

import (
	"github.com/go-oas/docs"
)

func main() {
	apiDoc := docs.New()
	apiDoc.AttachRoutes([]interface{}{
		handleGetUserRoute,
	})

If this approach is too flexible for you, you are always left with the possibility to create your own attacher - or any other parts of the system for that matter.

Examples

To run examples, and checkout hosted documentation via Swagger UI, issue the following command:

$ go run ./examples/file_output/*.go
# or uncomment line 40 and comment line 38 in internal/dist/index.html before running:
$ go run ./examples/stream_output/*.go

And navigate to http://localhost:3005/docs/api/ in case that you didn't change anything before running the example above.


Contact

Check out the current Project board or our GH Discussions board for more information.

You can join our Telegram group at: https://t.me/go_oas

Roadmap

Feature (GH issues) Description Release
Validation Add validation to all structures based on OAS3.0.3 v1.1.0
CLI Add CLI support - make it CLI friendly v1.2.0
Postman Add postman support via PM API v1.3.0
ReDoc Add ReDoc support as an alternative to SwaggerUI v1.4.0
E2E Auto-generation Go tests conversion to Cypress/Katalon suites (convert mocked unit tests into e2e tests) v1.5.0

docs's People

Contributors

kaynetik avatar padiazg avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar

docs's Issues

[RFC] Sane init & Advanced wrappers

Implement 2, or 3 layers of possible initialization?

Based on users choice, or speed of the development:

  • Add initializer for "sane defaults"
  • Add setters, instead of obviously showcasing nested structs
  • Leave possibility for advanced users with maximum flexibility for struct alteration
  • Given the last point, implement a MapTransformer interface, in which a user could pass their own map to alter the behavior of the Builder.

CI Tasks

  • Add Makefile

  • Add Linter

  • Add Build Pipeline | GH Actions

  • Add Tests to the pipeline

  • Add release tagging flow

  • Add badges for coverals/releases

[BUG] Examples run only from root

When navigating to ./examples and initiating go run *.go it fails at segmentation & nil dereference - because it's expected to be called from the root.

Update README & Docs

!Pre-Release action!

The readme should be updated to be concise, for a quick get-go.

Consider publishing GHPages/Docs to accompany it for smaller details that shouldn't be apart of the readme?

[RFC] Export swagger examples/models

As support for FE testing & unified FE mocks, support exporting swagger models, to have a single source of truth for those entities on both BE & FE.

YAML Marshal Ordering

Implement adequate ordering of the map elements, compared to standard OAS 3.0.1.

Current relevant point in the code is build.go:56::transformToMap().

YAML output is valid, but openapi lint is reporting:

Property `<T>` is not expected here

Which happens due to the nature of inbuilt maps.

FYI: Alternative to maps usage was something like this: gist link

But it proved difficult for $ref and deeply nested structs which had to be altered. Should it be revisited?

[RFC] Possible milestones?

Few RFCs proposed:

  • Postman support (build & push via PM API)
  • Go tests conversion to Cypress/Katalon suites (convert mocked unit tests into e2e tests)
  • Full on-run support for swagger, no CLI to "generate & serve", just run & enjoy

Add tests | Coverage checklist

  • Add a few example tests
  1. Routing 100% + Quick
  2. Annotations 91% (and quick tbd)
  3. Build
  4. Caller 100% + Quick
  5. Server
  6. Model Transformers
  7. Models - New() OAS

Bonus:

  • Add benchmarks for possible chokepoints

[Rel v1.4] ReDoc

Add ReDoc support as an alternative to SwaggerUI.

It should be feasible with minor adjustments to the current server, but this support will have to wait for more urgent features to be released first.

[RFC] Packages split & Unexport

    • Determine what can be an isolated package/module within the project
    • Unexport everything that shouldn't consider the end-user, and move it to internal
    • Improve overall readability and ease-of-use to make instantiation of each segment easier - consider func types for chaining sequences?

[RFC] Registration of built handlers

What easier (more transparent way) is there to register documentation handlers for each endpoint?

Also, consider using a service in order to share common endpoint setups?

[Rel v1.3] Postman

Add postman support via PM API.

Postman support (build & push via PM API).

Further research required to make a sane decision about this feature.

[Rel v1.1] Validation

Add validation to all structures based on OAS3.0.3

Precise description TBD. This will act as a parent task.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.