Adding examples to endpoints
See original GitHub issueI’m looking for a way to add examples.
I’m trying to add them with Blueprint.doc
, but it seems they are thrown away by Blueprint._prepare_doc
.
Is there some other way?
Issue Analytics
- State:
- Created 5 years ago
- Comments:14 (9 by maintainers)
Top Results From Across the Web
Step 2: Endpoints and methods (API reference tutorial)
Here's an example of the endpoints for the Relationships resource in the Instagram API: The endpoint is usually set off in a stylized...
Read more >Adding Examples - Swagger
Examples can be read by tools and libraries that process your API in some way. For example, an API mocking tool can use...
Read more >REST API Best Practices – REST Endpoint Design Examples
2. Use Nouns Instead of Verbs in Endpoints. When you're designing a REST API, you should not use verbs in the endpoint paths....
Read more >Specifying examples - Postman Learning Center
Examples show your API endpoints in action and give more details on how requests and responses work. You can add an example to...
Read more >What Is an API Endpoint? (And Why Are They So Important?)
For this example, you can use two Twitter API operators — from: and has:links — to only see tweets from certain accounts that...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
I’ll make the int -> string change independently. I’d rather be sure about what the doc requires before doing it.
Regarding this change, I think it is complete. I just need to take the time to clean it up, maybe find a better attribute name. Then update changelog, release, etc.
No, I think they do propagate already.
I just meant adding private attributes to external objects is a smell.
Generally, I’d rather have
than
so as not to modify the view function object.
But the key (the view func) registered by a decorator would be wrong when the next decorator returns another view func.
By the time you want to get the doc dict, all you have is the decorated func object and the key in the mapping may be the func object before another decoration, so the link is lost.
No big deal. Let’s keep view func object attributes for now.