RESTFUL APIs usually give you a set of endpoints to perform CRUD (Create, Read, Update, Delete) actions on different entities. We usually have a function in our project for each of these endpoints and these functions do a very similar job, but for different entities. For example, let’s say we have these functions:<\/p>\n\n\n\n
\/\/ apis\/users.js\n\n\/\/ Create\nexport function addUser(userFormValues) {\n return fetch(\"\/users\", { method: \"POST\", body: userFormValues });\n}\n\n\/\/ Read\nexport function getListOfUsers(keyword) {\n return fetch(`\/users?keyword=${keyword}`);\n}\n\nexport function getUser(id) {\n return fetch(`\/users\/${id}`);\n}\n\n\n\/\/ Update\nexport function updateUser(id, userFormValues) {\n return fetch(`\/users\/${id}`, { method: \"PUT\", body: userFormValues });\n}\n\n\/\/ Destroy\nexport function removeUser(id) {\n return fetch(`\/users\/${id}`, { method: \"DELETE\" });\n}<\/code><\/pre>\n\n\n\nand a similar set of functions may exist for other entities like City<\/code>, Product<\/code>, Category<\/code>, … . However, we can replace all of these functions with a simple function call:<\/strong><\/span><\/em><\/p>\n\n\n\n\/\/ apis\/users.js\nexport const users = crudBuilder(\"\/users\");\n\n\/\/ apis\/cities.js\nexport const cities = crudBuilder(\"\/regions\/cities\");\n\n\/\/ apis\/products.js\nexport const cities = crudBuilder(\"\/products\");<\/code><\/pre>\n\n\n\nAnd then use it like this:<\/p>\n\n\n\n
users.add(values);\nusers.show(1);\nusers.list(\"john\");\nusers.update(values);\nusers.remove(1);\n\nproducts.update(values)<\/code><\/pre>\n\n\n\n
advantages<\/span><\/h4>\n\n\n\nWell, there are some good reasons for writting code that way :<\/p>\n\n\n\n
- It reduces the lines of code ?-? code that you have to write and someone else has to maintain when you leave the company.<\/li>
- It enforces a naming convention for the API functions, which increases code readability and maintainability. You may have seen function names like
getListOfUsers<\/code>, getCities<\/code>, getAllProducts<\/code>, productIndex<\/code>, fetchCategories<\/code> etc. that all do the same thing: “get the list of an entity”. With this approach you’ll always have entityName.list()<\/code> functions and everybody on your team knows that.<\/li><\/ul>\n\n\n\nSo, let’s create that <\/strong><\/em><\/span>crudBuilder()<\/span><\/code><\/strong><\/em> function and then add some sugar to it.<\/strong><\/em><\/span><\/p>\n\n\n\nCRUD builder<\/h4>\n\n\n\n
For the simple example above, the crudBuilder<\/code> function would be so simple:<\/p>\n\n\n\nexport function crudBuilder(baseRoute) {\n function list(keyword) {\n return fetch(`${baseRoute}?keyword=${keyword}`);\n }\n\n function show(id) {\n return fetch(`${baseRoute}\/${id}`);\n }\n\n function create(formValues) {\n return fetch(baseRoute, { method: \"POST\", body: formValues });\n }\n\n function update(id, formValues) {\n return fetch(`${baseRoute}\/${id}`, { method: \"PUT\", body: formValues });\n }\n\n function remove(id) {\n return fetch(`${baseRoute}\/${id}`, { method: \"DELETE\" });\n }\n\n return {\n list,\n show,\n create,\n update,\n remove\n }\n}<\/code><\/pre>\n\n\n\nIt assumes a convention for API paths and given a path prefix for an entity, it returns all the methods required to call CRUD actions on that entity.<\/p>\n\n\n\n
PS:<\/span><\/strong> A real-world application will not be that simple! There are lots of thing to consider when applying this approach to our projects:<\/strong><\/p>\n\n\n\n- Filtering:<\/strong> list APIs usually get lots of filter parameters<\/li>
- Pagination<\/strong>: Lists are always paginated<\/li>
- Transformation:<\/strong> The API provided values may need some transformation before actually being used<\/li>
- Preparation:<\/strong> The
formValues<\/code> objects need some preparation before being sent to the API<\/li>- Custom Endpoints:<\/strong> The endpoint for updating a specific item is not always
`${baseRoute}\/${id}`<\/code><\/li><\/ul>\n\n\n\n