Comparing version 1.0.2 to 1.0.3
{ | ||
"name": "yukon", | ||
"version": "1.0.2", | ||
"version": "1.0.3", | ||
"description": "Self-discovering API-driven web components", | ||
@@ -5,0 +5,0 @@ "main": "yukon.js", |
@@ -122,3 +122,3 @@ # yukon API framework | ||
## Features for future consideration | ||
+ __Other forms of async data gathering.__ Currently yukon only knows how to make REST API calls. But it woudn't take much work to extend this behavior to any sort of asynchronous data store - such as a Mondo DB or Redis cache. | ||
+ __Other forms of async data gathering.__ Currently yukon only knows how to make REST API calls. But it woudn't take much work to extend this behavior to any sort of asynchronous data store - such as a Mongo DB or Redis cache. | ||
+ __Sequential API calls.__ Currently yukon makes all API calls in parallel. We've been fortunate in that we haven't needed dependent API calls yet. | ||
@@ -125,0 +125,0 @@ + __API error handling.__ It seems that there can be a huge variation in error behavior, and even in what constitutes an API error (status code-based?), from web-app to web-app. So for now I've punted on advanced API error handling, and let the app deal with it in the API callback. But if something like a standard is more or less agreed-upon, I will be happy to add flexible error handling. |
License Policy Violation
LicenseThis package is not allowed per your license policy. Review the package's license to ensure compliance.
Found 1 instance in 1 package
License Policy Violation
LicenseThis package is not allowed per your license policy. Review the package's license to ensure compliance.
Found 1 instance in 1 package