BlogAPI design

An SDK should speak the language

The clients share the same API, but their calls follow the conventions of the language you are writing in.

I want the SDKs to feel like code you would have written in that language. Sharing an API shouldn't mean forcing a Python application to look like JavaScript.

For example, a postal lookup in JavaScript takes an options object:

const place = await parse.postal('SW1A 1AA', { country: 'GB' });

The same lookup in Python uses a keyword argument:

place = parse.postal("SW1A 1AA", country="GB")

Both clients send the same request. The difference is how you express it in your application. Python also has AsyncParseAPI when you want the same methods with await, while the regular client stays synchronous.

Nested methods follow that idea too. JavaScript and Python can use parse.country.states("US") naturally. In Go, the method is CountryStates. The endpoint relationship stays recognizable without reproducing another language's object structure.

The response follows the same approach. Python returns dictionaries. Swift returns typed structs with optionals for nullable fields. You still get the API's field names and values, but you work with them through the types you already use.

The SDK page has the install instructions for each language. Once the client is set up, method names follow the endpoints, and the client handles URL encoding and the API-key header. The part you should be thinking about is what your app wants to do with the result.