You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, high-level POST requests return API objects while low level requests return response objects, with empty bodies. For example, createVerifiedPersonal returns a Customer, while the equivalent low level request returns a response with an empty body and a location header pointing to the created resource. This is impractical, uncommon, and inconvenient design; it forces the caller to make a second request to retrieve the created data. Unnecessary networking overhead and poor performance. The low level POST should return a body containing the created data.
If you're wondering "why doesn't he just use the high-level request then?" well - that's because the high level request design is also not preferable. Each function requires the JSON attributes to be passed in as a function parameter. FYI - 5+ function parameters is a major code smell (imagine someone swaps placement for first/last name, etc. -- it becomes unwieldy and increases chances of making mistakes). These functions should take strongly typed request objects as parameters. Not individual parameters. Anyway, the design of this SDK leaves a lot to be desired, and for the price-point, I'm pretty disappointed.
I'm hoping your team will consider these pain-points and consider making some improvements.
The text was updated successfully, but these errors were encountered:
andrewlaunchsite
changed the title
Improvement Suggestion - Make low level POST request body non empty
Improvement Suggestion - Make low level POST response body non empty
Jun 3, 2023
Hello @jcoon97
Currently, high-level POST requests return API objects while low level requests return response objects, with empty bodies. For example, createVerifiedPersonal returns a Customer, while the equivalent low level request returns a response with an empty body and a location header pointing to the created resource. This is impractical, uncommon, and inconvenient design; it forces the caller to make a second request to retrieve the created data. Unnecessary networking overhead and poor performance. The low level POST should return a body containing the created data.
If you're wondering "why doesn't he just use the high-level request then?" well - that's because the high level request design is also not preferable. Each function requires the JSON attributes to be passed in as a function parameter. FYI - 5+ function parameters is a major code smell (imagine someone swaps placement for first/last name, etc. -- it becomes unwieldy and increases chances of making mistakes). These functions should take strongly typed request objects as parameters. Not individual parameters. Anyway, the design of this SDK leaves a lot to be desired, and for the price-point, I'm pretty disappointed.
I'm hoping your team will consider these pain-points and consider making some improvements.
The text was updated successfully, but these errors were encountered: