
How to design APIs that don't suck - gafaar
https://medium.com/@anupcowkur/https-medium-com-anupcowkur-how-to-design-apis-that-dont-suck-922d864365c9
======
vmasto
_If you have a method called getUser and it throws an error when it can’t get
a user, It’s much easier on the consumer to spell this out explicitly with a
name like getUserOrThrowError_

I think this is bad advice honestly. Who does this anyway?

~~~
dudul
Plenty of languages have this convention. For example, in Elixir it's
customary to have something like `getUser` that returns either {:ok, the_user}
or {:error, reason} alongside `getUser!`, the `!` indicating that in case of
error it will throw.

Of course, a better approach is to not throw at all, and leverage a type
system to force the consumer to deal with potential error: `getUser:
Try[Option[User]]` for example. More verbose, and forces you to handle all the
cases, but safer and less error prone.

------
dudul
Don't agree with all the items, but it's refreshing to read a post where "API"
is not used as a synonym for "REST API" or even "Web API".

------
greew
I like that it isn't directed at any specific language but can be taken for
whichever language the reader wants. Mostly good advice!

