Issue 44 - Cisco Spark API Updates & Package Refactoring to Improve Future-Proofing #47
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
No other param can be used with this one. The Spark error message is pretty clear: > GET by ID cannot also other query filters, or a 'max' parameter
Add the following new Spark attributes to the `Person` object class: type nickName invitePending loginEnabled Update any docstrings that don’t look right. ;-)
Ensure all currently documented Spark API request parameters are represented in the package’s API. Refactor the request methods to defer request-construction errors to the Spark-API (future proofing and simplifies the number of exception types that need to be caught). Refactor parameter type checking to utilize a common package utility function, which raises `TypeError`s when parameter types are incorrect (more accurate exception representation - TypeError as opposed to AssertionError).
Add docstrings to the Room data model and ensure all 'known' attributes return their value or `None`.
Use common `request_parameters` name for future-proofing keyword arguments.
Apply structural changes to the RoomsAPI and ensure all parameters are up-to-date.
*args are passed in as a tuple, which needs to be converted to a list so that the `items` dictionary can be appended before processing.
Apply structural changes to the RoomsAPI and ensure all parameters are up-to-date.
Apply structural changes to the MessagesAPI and ensure all parameters are up-to-date.
Apply structural changes to the TeamsAPI and ensure all parameters are up-to-date.
Apply structural changes to the TeamMembershipsAPI and ensure all parameters are up-to-date.
Add a new `WebhookEvent` class to represent Spark generated webhook events. Apply structural changes to the RoomsAPI and ensure all parameters are up-to-date.
Apply structural changes to the RoomsAPI and ensure all parameters are up-to-date.
Apply structural changes to the RoomsAPI and ensure all parameters are up-to-date.
Apply structural changes to the RoomsAPI and ensure all parameters are up-to-date.
Apply structural changes to the RoomsAPI and ensure all parameters are up-to-date.
mentionedPeople should be a string not a list.
This was referenced Oct 29, 2017
Closed
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Resolving issue #44 (and then some...)
All of the API wrappers and data models have been reviewed and updated to match the latest Cisco Spark API capabilities. -and- We have completed a significant internal restructuring to improve all of the API wrappers:
All API methods that accept parameters and post-data have been updated to consistently accept optional (
**request_parameters) keyword arguments. So, if Cisco releases an API update tomorrow with some new awesome parameter... You can go ahead and use it. We'll update the code later so that it shows up in your IDE as soon as we can.New WebhookEvent - Webhook posts to your bot or automation can now be modeled via a new
WebhookEvent. Just pass the JSON body that Spark posts to your web service to theWebhookEvent()initializer and you can use native dot-syntax to access all of the attributes.Exceptions - some changes to what exceptions are raised...
TypeErrorrather than anAssertionError.ValueError.Exception handling should be very straightforward now. The only exception that you should have to catch and handle at runtime should be the
SparkApiError's, which are returned when Cisco Spark responds with an error code. By the way, these were recently updated to show you the full request and response body, when an error occurs. Any other errors should show up and be addressed when you are writing and debugging your code.