swagger-api/swagger-codegen

Add endpoint examples defined in the spec to API servers

Open

#5 423 ouverte le 19 avr. 2017

Voir sur GitHub
 (2 commentaires) (0 réactions) (0 assignés)HTML (5 474 forks)batch import
Enhancement: FeatureFeature List: API serversServer: C-SharpServer: ErlangServer: GoServer: HaskellServer: JavaServer: NodejsServer: PHPServer: PythonServer: RubyServer: ScalaServer: Springhelp wanted

Métriques du dépôt

Stars
 (12 701 stars)
Métriques de merge PR
 (Aucune PR mergée en 30 j)

Description

Description

Similar to what we've done for SpringMVC generator, we want to add support of endpoint examples defined in the spec to the auto-generated server stubs.

Ref: https://github.com/swagger-api/swagger-codegen/pull/5411

Endpoint example support in the server generators:

  • C# (NancyFx, ASP.net Core)
  • Elixir
  • Erlang
  • Go
  • Haskell Servant
  • JavaScript/NodeJS
  • Java (MSF4J, Spring:white_check_mark:, Undertow, JAX-RS: CDI, CXF, Inflector, RestEasy)
  • PHP (Lumen, Slim, Silex, Zend Expressive)
  • Python Flask
  • Ruby (Sinatra, Rails)
  • Scala Finch
  • Scala Scalatra
Suggest a Fix

#5411 is a good reference. If anyone wants to contribute to this task, please reply to let us know. Thank you.

Guide contributeur

Direction de recherche
Examinez la PR de référence #5411 pour comprendre comment les exemples de points de terminaison ont été ajoutés pour le générateur de serveur SpringMVC. Étudiez les fichiers de modèles correspondants (par exemple, les modèles mustache) et les classes de génération de code pour les autres générateurs de serveur listés. Pour chaque langue cible, identifiez où les données d'exemple de point de terminaison sont disponibles dans le modèle OpenAPI et modifiez le modèle pour produire les exemples. Envisagez de contribuer de manière incrémentielle, une langue à la fois.
Stack technique
java
Domaine
backendapi
Type d'issue
Fonctionnalité
DifficultéDifficulté estimée pour un nouveau contributeur, de 1 pour un très petit changement à 5 pour un travail expert.
3
Temps estiméFourchette de temps approximative pour investiguer, implémenter, tester et préparer une pull request.
1-2 jours
Statut d'activitéDisponibilité apparente de l'issue : fraîche, active, ancienne, bloquée ou en attente d'un mainteneur.
Ancienne
ClartéClarté avec laquelle l'issue explique le changement attendu, les critères d'acceptation et la prochaine étape.
Claire
Prérequis
Git
Accessibilité débutantScore de 1 à 100 estimant l'accessibilité de cette issue pour un premier contributeur.
65