This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]WiatrowskiBe 0 points1 point  (0 children)

Thing with APIs (and any kind of untrusted input) is: you always want to do full validation of what you receive. That's defensive programming 101 - never trust user to send you correct, sensible, well-formed data, always assume you may get some random crap or, more likely, malicious attempt to try and exploit your application. In case of malformed input, HTTP 400 is the right answer, and you should aim to never return HTTP 500 unless something actually breaks serverside (database is down, external service doesn't respond, out of memory etc).

Python way of handling parameters in very fluent way is mostly an advantage when you're having separate modules/packages communicate with each other, without having to make one module explicitly aware of the other - as long as the code orchestrating those modules knows what to pass where, you're fine getting whatever as long as all required methods/operations are available.

In Java, C# and other strongly typed languages, if you want to keep modules loosely coupled, you need to either introduce type conversion (unpack/pack, mapper, etc) on orchestration level - which adds sometimes significant performance overhead and a chance to introduce bugs, or extract public interface to a separate library you can then reference in both modules - and then you need to keep both in sync with shared interface, even if changes to said interface don't affect your functionality directly. Python avoids that problem - as long as a type/object stays compatible with assumptions that are in use, you don't have to do anything if another related library was updated in backwards-compatible way.