<\/p>\n\n\n\n
HTTP APIs are very loose by definition: there\u2019s no standards body, no API validator and not always someone there to tell you when you may be doing something incorrect. At ReadMe we have lots of experience in building, consuming and viewing APIs created by others. We even have our own open source API Explorer<\/a> which is used by all of our projects to try out APIs in the browser.<\/p>\n\n\n\n I asked engineers in the ReadMe team, \u201cWhat are some common issues or pitfalls you see when using APIs?\u201d This is a definitely a non-exhaustive list, but avoiding some of these pitfalls will make your APIs more \u201cstandard,\u201d intuitive, and easy to use. We came up with the following faux pas:<\/p>\n\n\n\n When you create an API endpoint you should consider accepting either<\/em> query parameters or body parameters, but not both. Since GET requests can\u2019t have bodies, the best way to pass in parameters and filters is via query string. For POST requests (and other non-idempotent methods) you should prefer bodies.<\/p>\n\n\n\n This is an example of using both query and body params, for a POST request:<\/p>\n\n\n\n <\/p>\n\n\n\n1. Sending a Mixture of Query Params and Body Params<\/h2>\n\n\n\n