Category Archives: CS-343

A look at REST API designing

Hello, for this quarter’s blog I read “The Day My Role-Based REST API Design Collapsed (and What I Learned)” by Sidharth Devaraj. Per the title, the blog talks about REST APIs, specifically Sidharth’s experience with them when he was new to backend development, and his reflections on a key mistake he made when designing his first REST API. To quickly summarize what that is; per GeeksForGeeks a rest API “…is a type of API (Application Programming Interface) that allows communication between different systems over the internet. REST APIs work by sending requests and receiving responses, typically in JSON format, between the client and server”. Following the theme of my previous blog, this is a topic pertinent to what we have recently been doing in class, and sometJhing I would like to see a human perspective on to gain insight about how I may utilize it in the future. 

Sidharth starts by explaining that he needed to make an API for an application he was working on. He mentions that when he was initially planning things out, he decided that he wanted to focus on keeping things organized and easy to understand. To accomplish this, his API was categorized into something that he, at the time, thought was pretty smart: user roles. These different roles would then act as routes for items to be used by those roles, i.e. /admin/… would host administrative objects, and /customer/… would host items used by a customer. At first glance this seems like it could be a pretty good idea, and Sidharth was pretty happy with what he thought up. However, he didn’t account for a crucial situation; what if both admins and customers both needed to interact with the same resources? It simply wouldn’t be feasible. The more resources created, the more issues arise. He ends his blog by pointing to the importance of a key design principle of REST: focus on resources, not roles. 

At first I thought this was a pretty bad mistake. If he had only thought a bit about how a role can’t be used by two different groups, he wouldn’t have made it in the first place. But then I thought about something; what if when initially building the application, none of his resources were needed by the two different groups? If he was testing things, in that situation he would never run into any issues, and wouldn’t be made aware of the flaws of his design. Only once the API started scaling did it become prevalent. I initially thought the blog was a pretty good read, but nothing special. It was more or less just “follow the design principles” without much more substance than that. However, reading into it a bit more it also touches on the importance of future-proofing your designs. Initially, Sidharth’s API worked great. Had his requirements not changed, he would have accomplished his goal of keeping it organized and easy to understand. However, as those requirements changed, new issues that weren’t present before arose. Scaling your work isn’t something I really think about much, when working on projects I really only think about how they can accomplish the present goal. But, in a professional environment, requirements will never be static, and this is something I really should get into my head. This blog definitely reminded me of that. 

From the blog Joshua's Blog by Joshua D. and used with permission of the author. All other rights reserved by the author.

A look at REST API designing

For this quarter’s blog I read “The Day My Role-Based REST API Design Collapsed (and What I Learned)” by Sidharth Devaraj. The blog talks about REST APIs, specifically Sidharth’s experience with them when he was new to backend development, and his reflections on a key mistake he made when designing his first REST API. To quickly summarize what that is; per GeeksForGeeks a rest API “…is a type of API (Application Programming Interface) that allows communication between different systems over the internet. REST APIs work by sending requests and receiving responses, typically in JSON format, between the client and server”. Following the theme of my previous blog, this is a topic pertinent to what we have recently been doing in class, and something I would like to see a human perspective on to gain insight about how I may utilize it in the future. 

Sidharth starts by explaining that he needed to make an API for an application he was working on. He mentions that when he was initially planning things out, he decided that he wanted to focus on keeping things organized and easy to understand. To accomplish this, his API was categorized into something that he, at the time, thought was pretty smart: user roles. These different roles would then act as routes for items to be used by those roles, i.e. /admin/… would host administrative objects, and /customer/… would host items used by a customer. At first glance this seems like it could be a pretty good idea, and Sidharth was pretty happy with what he thought up. However, he didn’t account for a crucial situation; what if both admins and customers both needed to interact with the same resources? It simply wouldn’t be feasible. The more resources created, the more issues arise. He ends his blog by pointing to the importance of a key design principle of REST: focus on resources, not roles. 

If he had only thought a bit about how a role can’t be used by two different groups, he wouldn’t have made it in the first place, right? But then, what if when initially building the application, none of his resources were needed by the two different groups? If he was testing things, in that situation he would never run into any issues, and wouldn’t be made aware of the flaws of his design. Only once the API started scaling did it become prevalent. I initially thought the blog was more or less just “follow the design principles” without much more substance than that. However, reading into it a bit more it also touches on the importance of future-proofing your designs. Had his requirements not changed, Sidharth would have accomplished his goal of keeping his API organized and easy to understand. However, as those requirements changed, new issues that weren’t present before arose. In a professional environment, requirements will never be static, as such scaling is very important. This is something I really should think about more.

From the blog Joshua's Blog by Joshua D. and used with permission of the author. All other rights reserved by the author.

We should Refactor our code

Code Refactoring and why should refactor your code by Lazar Nikolov

For this blog post, I chose to write about Code Refactoring. Nikolov starts off by expressing the idea that software does not expire, but it rots over time. The program continues to work, but as we add quick fixes, messy code, and shortcuts, it begins to become harder to work with. What is refactoring? In simple terms, refactoring is the process of cleaning and improving code without changing what the program actually does. To do this we must find code smells and technical debt and then begin removing them.

Code smells are not bugs that causes problems to your program. Instead they are warning signs that something is wrong with the design even though the code runs. Some examples of this can be having very large functions that try to do more than it should, confusing names, and complex logic that is hard to follow. Code written this way is often closely tied together. This could cause changing one small thing to break another part.

Technical debt is what happens when we choose the fast and easier solution like a shortcut to fixing a problem. This happens when we’re rushing to meet a deadline or don’t have coding standards. As a result we pay the price later with extra work since the code is hard to fix and improve on.

When should you refactor your code? Some signs are repeated code, having many bugs, or you are unable to add a new feature since the existing code is hard to work with. This relates to a term we’ve learned in class known as DRY (Don’t Repeat Yourself) and AHA (Avoid Hasty Abstractions). DRY says we should not repeat the same logic many times in our code. AHA reminds us we shouldn’t create abstractions early on.

This blog made me realize how much I relate to this topic. As someone who can say they often procrastinate and usually does assignments at the last minute. I’ll write quick code that “just works” so I can finish my assignments. I rarely think about how I can improve or add to it later. But I now understand that these shortcuts will definitely turn into technical debt. Moving forward, I’m going to watch for code smells more often as I work on projects. My goal is to write more optimized, cleaner code that would be better in the long run.

From the blog CS@Worcester – wdo by wdo and used with permission of the author. All other rights reserved by the author.

REST API Best Practices

In class, we have continued the usage of REST API, and we will only continue to use it. Through homework assignments and class activities, I’ve gotten more comfortable with REST API, but will need to have a good understanding of it as it is a vital part of my capstone project next semester. I found this blog of Stack Overflow that listed some best practices for REST API design that I was previously unaware of or did not have full knowledge of. 

Nest Endpoints That Contain Associated Info

If your database has objects that contain other objects, it is a good idea to reflect that in the endpoints. An example from guestInfoBackend would be “/guests/:uuid/assistance/”. This URI is used to access the “assistance” object inside a specific guest. But note that having multi-level nests can get out of hand. A bad example would be having an endpoint that looks like: /articles/:articleId/comments/:commentId/author. It is better to use the URI for the specific user within the JSON response as follows: “author”: “/users/:userId”.

Return HTTP Response Codes Indicating What Kind Of Error Occurred

HTTP response codes help to eliminate confusion when an occurs. Response codes give the API maintainers enough information to understand the problem that has occurred. The blog also showed some other common codes that were not discussed in class:

  • 401 Unauthorized – user isn’t not authorized to access a resource; usually returns when the user isn’t authenticated.
  • 403 Forbidden – user is authenticated, but not allowed to access a resource.
  • 502 Bad Gateway – invalid response from an upstream server.
  • 503 Service Unavailable – something unexpected happened on the server side; this could be anything from server overload to some parts of the system failing.

Messages also need to be attached to response codes so that maintainers have enough information to troubleshoot the issue, and that attackers can’t use any of the error content to launch attacks.

Maintain Good Security Practices

The communication between client and server should be private. A good way to secure your REST API is by loading an SSL/TLS certificate onto the server. They are very low cost or even free to use, so it is a no-brainer to strengthen security. It is also a good idea to apply the principle of least privilege. Each user should have role checks or more granular permissions. The admin should not have an issue adding and/or removing permissions and roles from users.

Version APIs

In order to prevent clients from being broken while making changes to the API, different versions of the API should be available. This way, old endpoints can be phased out instead of forcing everyone to switch over to the new version at the same time. This is important for public APIs and is how most apps today handle making changes.

Source

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

From the blog CS@Worcester – Blog del William by William Cordor and used with permission of the author. All other rights reserved by the author.

Refactoring Code

When looking for some ideas with what to write about for this blog post, I settled in on refactoring code. For starters I know what it is and why we do it, but I wanted to go more in depth by looking at other resources and what they have to say about it. One of the first sources I came across was a blog post called “How to create a culture of continuously refactoring code?” by Stas Wishnevetsky. This post from Medium revealed something that for some reasons wasn’t so obvious to me and this was that refactoring isn’t a one and done kind of thing. Instead, it is more of a routine and should be done as one to keep code maintained properly and to make sure it remains easy to use.

The first thing that really struck me when reading this article was talking about code like it is something physical and biological. This comparison was made to show how code can “decay” and “rot”. While the code itself doesn’t break down and fall apart with time, there are multiple reasons that make it seem like it does. These reasons include: coding abilities improving over time, business needs and scale fluctuating, and deliberate tech debt. The article then goes on to explain why we should refactor and the end goal of maintaining stability and creating improvement.

I guess I have never had the need to deal with refactoring my code since most the time I program one time assignments and never had the need to upkeep some kind of program. I have, however experience my abilities improving while creating a project and have had some parts be sloppy while later improvements are better done. I suppose I should have gone back and refactored those early parts but the bottom line is that I’ve never had the need to. I would also run into problems trying to make small changes which would be risky in my program. This is one of the many pains explained in the article I read and makes lots of sense.

I know going forward in my career refactoring will become very prominent in my work and understanding it more now makes me feel better about it. This also really shows the amount of effort that is put into big programs we use on a day to day basis. Starting the practice of constantly and consistently refactoring my code, even simple projects, will be super beneficial for me going forward.

From the blog CS@Worcester – Works for Me by Seth Boudreau and used with permission of the author. All other rights reserved by the author.

Blog Post #4

Title: Building Secure Web Applications

Blog Entry:

This week, I developed the issue of web application security- a growing serious field in the software development. With the growing interconnectedness of applications and the increasingly data-driven nature of the application development process, the importance of user information and system integrity is equal to the one of the functionality or performance. The subject is related to the course goals related to the design of systems, software quality, and secure coding practices.

During my research, I paid attention to the general weaknesses that programmers have to deal with, including cross-site scripting (XSS), SQL, and insecure authentication systems. Such weaknesses are usually brought about by a failure to look into security requirements at the initial design phase. As an illustration, the inability to check input correctly may enable attackers to inject bad codes or access classified information. Security by design is based on the idea that protection must be implemented at each stage of development instead of viewing security as an a posteriori.

During my research, I paid attention to the general weaknesses that programmers have to deal with, including cross-site scripting (XSS), SQL, and insecure authentication systems. Such weaknesses are usually brought about by a failure to look into security requirements at the initial design phase. As an illustration, the inability to check input correctly may enable attackers to inject bad codes or access classified information. Security by design is based on the idea that protection must be implemented at each stage of development instead of viewing security as an a posteriori.

I also reviewed the industry best practice of enhancing application security. The common attacks are prevented with the help of techniques like the parameterized queries, the enforcement of the HTTPS protocol and encryption of the sensitive data and the use of the secure authentication frameworks. Periodical code inspection, automated testing, and standard compliance, such as the Top Ten guide by the OWASP, make code developers responsible to the creation of more robust systems. I was also informed that a healthy security culture in a development team, wherein the whole team takes the responsibility of securing the data of its users, is as valuable as any technical measures.

This subject matter was echoed in our discussions in the classroom on software reliability and maintainability. Secure code is just like clean code in that the code will be used over a long period. I was intrigued by the fact that the same principles of design made it more secure such as the principles of clarity, simplicity, and modularity. A well-organized system, which is simple to audit, has fewer chances of concealing undetectable weaknesses.

Reflection:

This study has made me understand that the need to develop applications that are secure is not just a technical one, but also a moral obligation. The developers should be able to consider the risks and the safety of users in advance. Security should not be at the expense of usability but rather it should complement usability to produce software that the user can trust. This attitude has motivated me to follow safe coding practices early in my work which includes validating inputs, data handling and sound frameworks.

In general, this discovery broadened my perspective on contemporary software design to include aspects of performance and functionality. Security is a key component of quality software engineering like never before. With these principles combined, I am more confident that I will be able to create applications that are efficient and scalable, besides being user-safe in the ever-digitized world.

Next Steps:

Next time, I will test some security orientated tools in the form of penetration testing systems and auto vulnerability scanners. I will also consider reading more on OWASP guidelines as a way of enhancing my knowledge on emerging threats and mitigation controls.

From the blog CS@Worcester – Site Title by Yousef Hassan and used with permission of the author. All other rights reserved by the author.

Blog Post #4

Title: Building Secure Web Applications

Blog Entry:

This week, I developed the issue of web application security- a growing serious field in the software development. With the growing interconnectedness of applications and the increasingly data-driven nature of the application development process, the importance of user information and system integrity is equal to the one of the functionality or performance. The subject is related to the course goals related to the design of systems, software quality, and secure coding practices.

During my research, I paid attention to the general weaknesses that programmers have to deal with, including cross-site scripting (XSS), SQL, and insecure authentication systems. Such weaknesses are usually brought about by a failure to look into security requirements at the initial design phase. As an illustration, the inability to check input correctly may enable attackers to inject bad codes or access classified information. Security by design is based on the idea that protection must be implemented at each stage of development instead of viewing security as an a posteriori.

During my research, I paid attention to the general weaknesses that programmers have to deal with, including cross-site scripting (XSS), SQL, and insecure authentication systems. Such weaknesses are usually brought about by a failure to look into security requirements at the initial design phase. As an illustration, the inability to check input correctly may enable attackers to inject bad codes or access classified information. Security by design is based on the idea that protection must be implemented at each stage of development instead of viewing security as an a posteriori.

I also reviewed the industry best practice of enhancing application security. The common attacks are prevented with the help of techniques like the parameterized queries, the enforcement of the HTTPS protocol and encryption of the sensitive data and the use of the secure authentication frameworks. Periodical code inspection, automated testing, and standard compliance, such as the Top Ten guide by the OWASP, make code developers responsible to the creation of more robust systems. I was also informed that a healthy security culture in a development team, wherein the whole team takes the responsibility of securing the data of its users, is as valuable as any technical measures.

This subject matter was echoed in our discussions in the classroom on software reliability and maintainability. Secure code is just like clean code in that the code will be used over a long period. I was intrigued by the fact that the same principles of design made it more secure such as the principles of clarity, simplicity, and modularity. A well-organized system, which is simple to audit, has fewer chances of concealing undetectable weaknesses.

Reflection:

This study has made me understand that the need to develop applications that are secure is not just a technical one, but also a moral obligation. The developers should be able to consider the risks and the safety of users in advance. Security should not be at the expense of usability but rather it should complement usability to produce software that the user can trust. This attitude has motivated me to follow safe coding practices early in my work which includes validating inputs, data handling and sound frameworks.

In general, this discovery broadened my perspective on contemporary software design to include aspects of performance and functionality. Security is a key component of quality software engineering like never before. With these principles combined, I am more confident that I will be able to create applications that are efficient and scalable, besides being user-safe in the ever-digitized world.

Next Steps:

Next time, I will test some security orientated tools in the form of penetration testing systems and auto vulnerability scanners. I will also consider reading more on OWASP guidelines as a way of enhancing my knowledge on emerging threats and mitigation controls.

From the blog CS@Worcester – Site Title by Yousef Hassan and used with permission of the author. All other rights reserved by the author.

Blog Post #4

Building Secure Web Applications

Title: Building Secure Web Applications

Blog Entry:

This week, I developed the issue of web application security- a growing serious field in the software development. With the growing interconnectedness of applications and the increasingly data-driven nature of the application development process, the importance of user information and system integrity is equal to the one of the functionality or performance. The subject is related to the course goals related to the design of systems, software quality, and secure coding practices.

During my research, I paid attention to the general weaknesses that programmers have to deal with, including cross-site scripting (XSS), SQL, and insecure authentication systems. Such weaknesses are usually brought about by a failure to look into security requirements at the initial design phase. As an illustration, the inability to check input correctly may enable attackers to inject bad codes or access classified information. Security by design is based on the idea that protection must be implemented at each stage of development instead of viewing security as an a posteriori.

I also reviewed the industry best practice of enhancing application security. The common attacks are prevented with the help of techniques like the parameterized queries, the enforcement of the HTTPS protocol and encryption of the sensitive data and the use of the secure authentication frameworks. Periodical code inspection, automated testing, and standard compliance, such as the Top Ten guide by the OWASP, make code developers responsible to the creation of more robust systems. I was also informed that a healthy security culture in a development team, wherein the whole team takes the responsibility of securing the data of its users, is as valuable as any technical measures.

This subject matter was echoed in our discussions in the classroom on software reliability and maintainability. Secure code is just like clean code in that the code will be used over a long period. I was intrigued by the fact that the same principles of design made it more secure such as the principles of clarity, simplicity, and modularity. A well-organized system, which is simple to audit, has fewer chances of concealing undetectable weaknesses.

Reflection:

This study has made me understand that the need to develop applications that are secure is not just a technical one, but also a moral obligation. The developers should be able to consider the risks and the safety of users in advance. Security should not be at the expense of usability but rather it should complement usability to produce software that the user can trust. This attitude has motivated me to follow safe coding practices early in my work which includes validating inputs, data handling and sound frameworks.

In general, this discovery broadened my perspective on contemporary software design to include aspects of performance and functionality. Security is a key component of quality software engineering like never before. With these principles combined, I am more confident that I will be able to create applications that are efficient and scalable, besides being user-safe in the ever-digitized world.

Next Steps:

Next time, I will test some security orientated tools in the form of penetration testing systems and auto vulnerability scanners. I will also consider reading more on OWASP guidelines as a way of enhancing my knowledge on emerging threats and mitigation controls.

, , , ,
, , , ,
, , , , 



From the blog CS@Worcester – Site Title by Yousef Hassan and used with permission of the author. All other rights reserved by the author.
					

		
		
	


	

				

			
						

				Blog Post #4
			

								


				

			
Building Secure Web Applications


Title: Building Secure Web Applications


Blog Entry:


This week, I developed the issue of web application security- a growing serious field in the software development. With the growing interconnectedness of applications and the increasingly data-driven nature of the application development process, the importance of user information and system integrity is equal to the one of the functionality or performance. The subject is related to the course goals related to the design of systems, software quality, and secure coding practices.


During my research, I paid attention to the general weaknesses that programmers have to deal with, including cross-site scripting (XSS), SQL, and insecure authentication systems. Such weaknesses are usually brought about by a failure to look into security requirements at the initial design phase. As an illustration, the inability to check input correctly may enable attackers to inject bad codes or access classified information. Security by design is based on the idea that protection must be implemented at each stage of development instead of viewing security as an a posteriori.


I also reviewed the industry best practice of enhancing application security. The common attacks are prevented with the help of techniques like the parameterized queries, the enforcement of the HTTPS protocol and encryption of the sensitive data and the use of the secure authentication frameworks. Periodical code inspection, automated testing, and standard compliance, such as the Top Ten guide by the OWASP, make code developers responsible to the creation of more robust systems. I was also informed that a healthy security culture in a development team, wherein the whole team takes the responsibility of securing the data of its users, is as valuable as any technical measures.


This subject matter was echoed in our discussions in the classroom on software reliability and maintainability. Secure code is just like clean code in that the code will be used over a long period. I was intrigued by the fact that the same principles of design made it more secure such as the principles of clarity, simplicity, and modularity. A well-organized system, which is simple to audit, has fewer chances of concealing undetectable weaknesses.


Reflection:


This study has made me understand that the need to develop applications that are secure is not just a technical one, but also a moral obligation. The developers should be able to consider the risks and the safety of users in advance. Security should not be at the expense of usability but rather it should complement usability to produce software that the user can trust. This attitude has motivated me to follow safe coding practices early in my work which includes validating inputs, data handling and sound frameworks.


In general, this discovery broadened my perspective on contemporary software design to include aspects of performance and functionality. Security is a key component of quality software engineering like never before. With these principles combined, I am more confident that I will be able to create applications that are efficient and scalable, besides being user-safe in the ever-digitized world.


Next Steps:


Next time, I will test some security orientated tools in the form of penetration testing systems and auto vulnerability scanners. I will also consider reading more on OWASP guidelines as a way of enhancing my knowledge on emerging threats and mitigation controls.


, , , , 


, , , , 


, , , , 





From the blog CS@Worcester – Site Title by Yousef Hassan and used with permission of the author. All other rights reserved by the author.
					

		
		
	


	

				

			
						

				The art of REST API design
			

								


				

			
Something I have personally never worked on as a developer is REST API. AWS is a piloting force in the sphere of web development so there was no better place to read up on this subject than there. Going through you can really see why REST API is so vital to the modern web.


An overview of REST API design principles, methods, and benefits, illustrating key concepts for web development.


What is an API?


API stands for Application Programming Interface, this defines the rules you must follow to communicate with other software systems. 


API is a gateway betweek:


    

  • Clients: Users who want to access information from the web
    • 

  • Resources: The information that different applications provide to their clients.
    • 



What is REST?


REST stands for Representational State Transfer, this is a software architecture that imposes conditions on how an API should work. It was originally created as a guideline to manage communication on complex networks. As a result one architecture developers can use is RESTful API.


Here are some of the principles of the REST architectural style:


    

  • Uniform interface

      

    • Indicates the server transfers information in a standard format
      • 

    • 4 architectural contraints:

        

      • Requests should identify resources
        • 

      • Clients have enough info in the resource representation to modify or delete the resource if wanted
        • 

      • Clients receive info about how to process the representation further
        • 

      • Clients receive info about all other related resources they need to complete a task.
        • 

      

      • 

    

    • 

  • Statelessness

      

    • A communication method in which the server completes every client request independently of all previous requests
      • 

    

    • 

  • Layered System

      

    • Client can connect to other authorized intermediaries between the client & server, and it will still receive responses between the server
      • 

    

    • 

  • Cache-ability

      

    • Able to store some responses on the client or on an intermediary to improve response time
      • 

    

    • 

  • Code on demand

      

    • Servers can temporarily extend or customize client functionality by transferring programming code to the client.
      • 

    

    • 



Benefits to REST API:


Here are the few of the benefits AWS includes:


    

  • Scalability
    • 

  • Flexibility
    • 

  • Independence
    • 



How it works:


The basic functions are similar to browsing the internet, here are the general steps towards any REST API call:


    

  1. The client sends a request to the server
    2. 

  2. The server authenticates the client and confirms permissions to make request
    3. 

  3. The server receives request and processes it
    4. 

  4. The server returns a response to the client.
    5. 



The client request contains these main components:


    

  • Unique resource identifier
    • 

  • Method

      

    • GET

        

      • Access resources at URL
        • 

      

      • 

    • POST

        

      • Send data to server
        • 

      

      • 

    • PUT

        

      • Update existing resources on the server
        • 

      

      • 

    • DELETE

        

      • Request to remove resource
        • 

      

      • 

    

    • 

  • HTTP headers

      

    • Data
      • 

    • Parameters

        

      • Path: Specifies URL details
        • 

      • Query: Requests more info about resource
        • 

      • Cookie: Provides authentication
        • 

      

      • 

    

    • 



Final Thoughts:


My understanding of REST APIs was very limited but leave it to the best in the business to have all the information necessary to learn. I definitely think it would take time to implement nonetheless but having this basic understanding is important in the end. If you want to learn more yourself visit this page on AWS.


, , 



From the blog Petraq Mele blog posts by Petraq Mele and used with permission of the author. All other rights reserved by the author.