Comments (2)
Ultimately, my goal is to JSDoc the entire Restivus API, and apiDoc any autogenerated endpoints (both of which are on my makeshift roadmap). I come from the school of thought that another developer shouldn't have to understand your implementation just to work with your API. For JSDoc, I'm under the impression that the *
is necessary after the opening ###
of a block for parsing of those comments. Comments without that would be ignored. It isn't required in apiDoc, but it doesn't interfere with the output, so I figure it would be best to just keep things consistent between all block comments (which I clearly haven't done here :) ).
The reason that some methods have it and some don't is completely arbitrary at this point. Every public method (and maybe even some of the handy or more complex "private" methods) should be properly documented (to make journeys such as the one you are about to embark on much easier). This is, admittedly, the first open source project I've been a part of, and sometimes I struggle between maintaining balance in the level of documentation I'm comfortable with and my users' needs for updates and bug fixes. That causes some of these inconsistencies to break through. I just need to make an effort to generate the docs and go through and add all the necessary detail (e.g. @params
, @returns
, etc.). Now that it appears I have another active contributor, I will make an effort to do this asap.
from meteor-restivus.
I filed issue #54 to make the comments consistent. Thanks for raising the question! Any discussion on this can continue over there now.
from meteor-restivus.
Related Issues (20)
- Restivus is not a constructor HOT 1
- Restivus.configure is not a function
- HTTP.call inside api issue
- Is it possible to read Content-type: text/plain data HOT 3
- Simple question: Mutual or two way certificate authentication
- First Logging in is not required when using meteor restivus HOT 1
- How to consume a REST api that needs username/password authentication in node.js HOT 1
- onLogInFailure
- Getting 400 Bad Request on Mup Deployed
- Try login with user who does not have password, crashes server
- API should close connection by default HOT 2
- Need corsHeader configurations for CORS
- Role permissions don't work with meteor-roles v3
- Unable to upload multipart file
- Upload multipart file
- Support Meteor 2.3 HOT 1
- Meteor 2.3 not supported HOT 2
- Reason: CORS header ‘Access-Control-Allow-Origin’ missing
- CORS header ‘Access-Control-Allow-Origin’ missing if http status code is not 200
- URL params issue
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
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.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from meteor-restivus.