
Common REST API mistakes and how to avoid them - mooreds
https://blog.logrocket.com/common-api-mistakes-and-how-to-avoid-them-804fbcb9cc4b/
======
gargarplex
Version your API from day one (instead of company.com/api, support
company.com/api/v1). This makes it a lot easier to support legacy users.

~~~
zeeZ
Don't put your API on the same Domain as your website. Use api.company.com or
a dedicated domain instead of company.com/api.

~~~
philwelch
Interesting. What's the rationale?

~~~
paulddraper
Flexibility. A CNAME is easier than a reverse proxy.

Security. Don't share cookies with your site.

~~~
philwelch
What if sharing cookies with your site is the intended behavior, e.g. for
API's that you're calling directly from your frontend?

------
hhas01
Article has nothing to do with “REST”.

Thankfully so, because 110% of what is written about “REST APIs” is an
absolute bag of shit. #OxyMoron

~~~
philwelch
Actually using the “REST” abstraction and taking it seriously is perhaps one
of the most common mistakes!

------
Madeindjs
Great advices but in my opinions I prefer to stick with
[https://jsonapi.org](https://jsonapi.org) specifications . There is good
librairies to serialize JSON objects into JSON API compliant objects.

~~~
brillout
Or Widcard API ([https://github.com/reframejs/wildcard-
api](https://github.com/reframejs/wildcard-api)) for Node.js <-> Browser

(Disclosure: I'm Wildcard's author.)

------
postalrat
Why do so many prefer strings over unix timestamps? Do they like making things
that much more complicated for the sake of human readability?

~~~
nooyurrsdey
ISO 8601 should solve both. Human readability and standrzied time with zone

~~~
philwelch
There are also use cases where Unix timestamps/UTC are actually the wrong
solution.

