Problem Description
Currently Mpesa API responses are returned as JSON strings by MpesaLib and left for the end user to deserialize into their own objects. This requires the developer to know the structure of the JSON response in order to be able to deserialize a response into a C# object.
Proposed Solution
While this would be open to debate there are two solutions that can be adopted:
Create and include the response objects into the library and advice developer on how to deserialize api responses into their respective reponse objects. (This is a quick win)
Deserialize the JSON string response into the respective response objects and return the response objects instead of the JSON string. In this case to avoid breaking existing functionality it would be nice to add this as an opt-in functionality using extension methods.
Why Was this not included in the beginning?
Reason is simple - ultimately the developer wants a JSON object to use in a web/mobile app. If the client application is directly handling the response for example with JavaScript then deserializing and then serializing is an overkill. But if there is some business logic that needs to work on the response data before forwarding to client then deserialization into a walkable C# object would be necessary.
ayiemba
commented
4 years ago
Problem Description Currently Mpesa API responses are returned as JSON strings by MpesaLib and left for the end user to deserialize into their own objects. This requires the developer to know the structure of the JSON response in order to be able to deserialize a response into a C# object.
Proposed Solution While this would be open to debate there are two solutions that can be adopted:
Create and include the response objects into the library and advice developer on how to deserialize api responses into their respective reponse objects. (This is a quick win)
Deserialize the JSON string response into the respective response objects and return the response objects instead of the JSON string. In this case to avoid breaking existing functionality it would be nice to add this as an opt-in functionality using extension methods.
Why Was this not included in the beginning? Reason is simple - ultimately the developer wants a JSON object to use in a web/mobile app. If the client application is directly handling the response for example with JavaScript then deserializing and then serializing is an overkill. But if there is some business logic that needs to work on the response data before forwarding to client then deserialization into a walkable C# object would be necessary.