In this blog post, I will go over some of the best practices with REST API design, especially considering performance and security at must for most API consumers. It is worth notice that proper API design will ease the maintenance for many services and applications running on a web browser, as the worst case scenario will be more difficult to maintain and becomes different from what everyone expect.

In summary, the post introduces the crucial ways to design the REST APIs properly, which there are accepted conventions to follow so we won’t run into the problems down the road. Some example practices can be Accept and respond with JSON, where JSON is standard for transferring data, as well as built-in methods for Javascript to encode and decode JSON either through the Fetch API or another HTTP client. Other practices are usage of nouns instead of verb for endpoint path names, since it could conflict with HTTP method which are already the verbs, as well as many other practices such as handling error codes, maintain good security practices, and caching data to improve performance, and versioning the APIs.

The reason I choose this article is because there are many ways to experiments with REST API, with the aim to design a web application that meet consumers need, especially end-user experiences. In most cases, we want to deliver the up-to-date user experience within the web applications, and making sure to handle things that are unexpected. In other words, we need to keep track on features in our web applications, monitoring bugs that occur to many users, and monitor versioning appropriately according to the semantic versioning. In my experience, programming and maintaining a REST API project would take very careful steps to count on user experience, as well as what to and not to access. The best example is the good security practices, which are the process of obtaining SSL/TLS security. The good boundaries for the user is to not access any more information beyond what they expected, because when doing so, they could access into another user’s information, as well as information from the admins of the web server.

From what I learned from the article, applying these practices will help me learn more about making a clean REST API project, maintaining the project in the future long run so users will always have access to their needs. As the project grows, it will often requires a higher demand in terms of backend features, hence careful handling is needed to meet all the expectations overall.

Source: https://stackoverflow.blog/2020/03/02/best-practices-for-rest-api-design/

From the blog CS@Worcester – Hello from Kiet by Kiet Vuong and used with permission of the author. All other rights reserved by the author.

In this blog post, we will highlights some important details between Cohesion and Coupling. The definition of the two concepts can be difficult to understand at first, but then it is helpful to imagine a picture of how elements are interconnected, leading to further understanding as Cohesion and Coupling are correlate to each other.

In the blog summary, first of all is how they clarify the complicated definition of these two concepts. Cohesion is about how elements belong together, but it does not depend on the number of connections between elements, which is what coupling is all about. The blog post also shows the pictures that helps us imagine of how loose and tight the elements are, which can be ideal when figuring out the correct way to organize module. In other words, it should leads to high cohesion and low coupling. And finally is how to sum up to the point that why high cohesion does not only make the system easy to understand and change, it also reduces the level of coupling.

I personally choose this post because it is helpful to understand how to apply these two concepts carefully. In object-oriented programming, for example when making a class in Java, we should know when we declare too many properties that could make the class ultimately “do everything”. For example, declaring a bookstore class that do the following properties: add, remove, sale, and receipt. As we create multiple properties like this, we notice that there are properties shouldn’t be necessary, such as sale and receipt, and instead should break down into each individual class. That’s what affect the cohesion, where breaking each properties into each individual class will promote higher cohesion and lower coupling. Therefore, we call each classes a cohesive class.

This concept of Cohesion and Coupling also makes me imagine of how to organize properties in one class that looks easier to maintain. In my experience, not always when declaring a class is a cohesive class, as I can’t determine if some related properties in that class should breaks down into new classes. Therefore, it’s difficult to maintain for larger projects, making it look complicated at a glance. What I learned about these concepts is helpful to me so I can visualize how I should organize classes and properties, by applying the definition of cohesion and coupling, as high and low for each can affects future maintenance and for the overall functionalities of the project.

Source: https://blog.ttulka.com/how-cohesion-and-coupling-correlate/

From the blog CS@Worcester – Hello from Kiet by Kiet Vuong and used with permission of the author. All other rights reserved by the author.

This blog post I’ll talk about some benefits that Web Development offers, comparing to the software that’s originally installed in a client machine. There are a vast amount of services and applications, such as social media applications or email services, mostly accessible through an application that has to be downloaded in a client device. However, this creates the following compatibility issue: What if you don’t own a compatible device that you need to download a specific software? For example, there are software such that it’s only available on PC. Again, “available on PC” means for PC users only, other client users like Mac or Linux won’t be usable.

For the summary, this blog post points out the convenience of web system development in terms of customization, easy integration, accessibility, and maintenance, as well as several major advantages on web system compared to having software installed on the computer. I select this particular resource to emphasize that you’re able to access resources directly on the website, rather than having it installed on your local machine. This eliminates the compatibility issues such as between Operating Sytems or CPU Architectures, such as applications that can only work on x86_64, amd64, but unable to work with arm64. Hence this shrinks the boundary of working on multiple devices.

One helpful thing the post also pointed out is ease of maintenance. In my experience, maintaining an application requires rebuilding software resources, bug fixing, recompiling, etc.. which takes a large amount of time and requiring end user to update the app. That is also to mention about old hardware, since constant updating on an application will slows the device down over time, and the app will requires more powerful hardware. However, there are also some amounts of people can’t afford for new hardware. Think of it as you own the best hardware and you wanted to use it for more than ten years, and only buy a new one when the old one is broken. Therefore, it would be best to consider building software on a web system, since once an upgrade is available, it may be applied through the host server rather than having to upgrade each computer. This facilitates the installation of new software and upgrades and maintenance from a single location.

In conclusions, many services and applications we’re using today considered web system as an option, providing seamless experience with all you need is a web browser. In the near future, web system development can be a perfect option to centralize all the latest features, keeping user friendliness and fully accessible anywhere.

Source: https://riseuplabs.com/web-system-development-process/

From the blog CS@Worcester – Hello from Kiet by Kiet Vuong and used with permission of the author. All other rights reserved by the author.