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.

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.

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.

 Hello! For my second quarter blog, I read a separate blog written by Yung Han Jeong, titled “Spaghetti Deconstructed: Lessons from my first refactoring“. As its name suggests, this blog talks about Yung’s personal experiences and advice pertaining to refactoring. For those who don’t know, refactoring is essentially improving existing code in a way that doesn’t affect it’s functionality. This can be as simple as changing variable names, all the way to completely restructuring the program. In our class this semester, for a very large portion of what we will be doing, refactoring is an integral part of it. I would say at this point I am pretty comfortable with the topic, however I figured that I would like some sort of anecdotal, first-hand account of someone’s actual experiences with it, as everything we have been doing has been in a classroom setting. 

Yung’s blog recounts her experiences in refactoring some of her earliest code written when she was an entry-level developer, namely in her horror at how bad it used to be. It got her thinking about what she could have done to improve her code, which inspired her to blog about the biggest changes she thinks would make the difference (she provides four examples which she calls “pasta”, “sauce”, “meatballs”, and “cheese”, I don’t think I need to explain that). Firstly (pasta), she talks about the importance of having descriptive variable names. Next (sauce), she hammers in the importance of commenting out the entirety of your code. It’s something all cs students have been pestered about endlessly, but it is one of the single most important things you can do to improve your code, being able to quickly understand what a method/class/etc. does saves so much time in the long run, outweighing the extra time you spend writing the comment. Her third point (meatballs) ties into this in that she recommends keeping most if not all debugging statements. She argues that once they served their purpose, they can simply be commented out and referenced in the future. Lastly (cheese), she emphasizes the importance of revisiting code “soon and often”. 

Admittedly, the advice Yung gives is pretty rudimentary. When I found this blog I thought it would talk about refactoring in the way we have in class, where we focus more on the structure side of things. However, reading this made me realize that this is very much refactoring as well. Sometimes the best thing you can do with your code is improve on the simple things, like naming schemes and comments, something Yung, an actual software dev, seems to find important enough to write a blog about. I am happy I found this blog; while I didn’t exactly learn anything ground-breaking, I realized that when refactoring, sometimes improving on the simple things is the best course of action to take. 

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

 Hello! For my second quarter blog, I read a separate blog written by Yung Han Jeong, titled “Spaghetti Deconstructed: Lessons from my first refactoring“. As its name suggests, this blog talks about Yung’s personal experiences and advice pertaining to refactoring. For those who don’t know, refactoring is essentially improving existing code in a way that doesn’t affect it’s functionality. This can be as simple as changing variable names, all the way to completely restructuring the program. In our class this semester, for a very large portion of what we will be doing, refactoring is an integral part of it. I would say at this point I am pretty comfortable with the topic, however I figured that I would like some sort of anecdotal, first-hand account of someone’s actual experiences with it, as everything we have been doing has been in a classroom setting. 

Yung’s blog recounts her experiences in refactoring some of her earliest code written when she was an entry-level developer, namely in her horror at how bad it used to be. It got her thinking about what she could have done to improve her code, which inspired her to blog about the biggest changes she thinks would make the difference (she provides four examples which she calls “pasta”, “sauce”, “meatballs”, and “cheese”, I don’t think I need to explain that). Firstly (pasta), she talks about the importance of having descriptive variable names. She argues that while it is enticing to have simple variable names that you might not see the need to go into detail about as you are familiar with the code, it is always worth the extra effort to either make them more descriptive, or to comment an explanation about all of them (or both!). Next (sauce), she hammers in the importance of commenting out the entirety of your code. It’s something all cs students have been pestered about endlessly, but it is one of the single most important things you can do to improve your code, being able to quickly understand what a method/class/etc. does saves so much time in the long run, outweighing the extra time you spend writing the comment. Her third point (meatballs) ties into this in that she recommends keeping most if not all debugging statements. She argues that once they served their purpose, they can simply be commented out and referenced in the future. Lastly (cheese), she emphasizes the importance of revisiting code “soon and often”. 

Admittedly, the advice Yung gives is pretty rudimentary. When I found this blog I thought it would talk about refactoring in the way we have in class, where we focus more on the structure side of things. However, reading this made me realize that this is very much refactoring as well. Sometimes the best thing you can do with your code is improve on the simple things, like naming schemes and comments, something Yung, an actual software dev, seems to find important enough to write a blog about. I am happy I found this blog; while I didn’t exactly learn anything ground-breaking, I realized that when refactoring, sometimes improving on the simple things is the best course of action to take. 

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

 Hello! For my second quarter blog, I read a separate blog written by Yung Han Jeong, titled “Spaghetti Deconstructed: Lessons from my first refactoring“. As its name suggests, this blog talks about Yung’s personal experiences and advice pertaining to refactoring. For those who don’t know, refactoring is essentially improving existing code in a way that doesn’t affect it’s functionality. This can be as simple as changing variable names, all the way to completely restructuring the program. In our class this semester, for a very large portion of what we will be doing, refactoring is an integral part of it. I would say at this point I am pretty comfortable with the topic, however I figured that I would like some sort of anecdotal, first-hand account of someone’s actual experiences with it, as everything we have been doing has been in a classroom setting. 

Yung’s blog recounts her experiences in refactoring some of her earliest code written when she was an entry-level developer, namely in her horror at how bad it used to be. It got her thinking about what she could have done to improve her code, which inspired her to blog about the biggest changes she thinks would make the difference (she provides four examples which she calls “pasta”, “sauce”, “meatballs”, and “cheese”, I don’t think I need to explain that). Firstly (pasta), she talks about the importance of having descriptive variable names. She argues that while it is enticing to have simple variable names that you might not see the need to go into detail about as you are familiar with the code, it is always worth the extra effort to either make them more descriptive, or to comment an explanation about all of them (or both!). Next (sauce), she hammers in the importance of commenting out the entirety of your code. It’s something all cs students have been pestered about endlessly, but it is one of the single most important things you can do to improve your code, being able to quickly understand what a method/class/etc. does saves so much time in the long run, outweighing the extra time you spend writing the comment. Her third point (meatballs) ties into this in that she recommends keeping most if not all debugging statements. She argues that once they served their purpose, they can simply be commented out and referenced in the future. Lastly (cheese), she emphasizes the importance of revisiting code “soon and often”. 

Admittedly, the advice Yung gives is pretty rudimentary. When I found this blog I thought it would talk about refactoring in the way we have in class, where we focus more on the structure side of things. However, reading this made me realize that this is very much refactoring as well. Sometimes the best thing you can do with your code is improve on the simple things, like naming schemes and comments, something Yung, an actual software dev, seems to find important enough to write a blog about. I am happy I found this blog; while I didn’t exactly learn anything ground-breaking, I realized that when refactoring, sometimes improving on the simple things is the best course of action to take. 

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

 Hello! For my second quarter blog, I read a separate blog written by Yung Han Jeong, titled “Spaghetti Deconstructed: Lessons from my first refactoring“. As its name suggests, this blog talks about Yung’s personal experiences and advice pertaining to refactoring. For those who don’t know, refactoring is essentially improving existing code in a way that doesn’t affect it’s functionality. This can be as simple as changing variable names, all the way to completely restructuring the program. In our class this semester, for a very large portion of what we will be doing, refactoring is an integral part of it. I would say at this point I am pretty comfortable with the topic, however I figured that I would like some sort of anecdotal, first-hand account of someone’s actual experiences with it, as everything we have been doing has been in a classroom setting. 

Yung’s blog recounts her experiences in refactoring some of her earliest code written when she was an entry-level developer, namely in her horror at how bad it used to be. It got her thinking about what she could have done to improve her code, which inspired her to blog about the biggest changes she thinks would make the difference (she provides four examples which she calls “pasta”, “sauce”, “meatballs”, and “cheese”, I don’t think I need to explain that). Firstly (pasta), she talks about the importance of having descriptive variable names. She argues that while it is enticing to have simple variable names that you might not see the need to go into detail about as you are familiar with the code, it is always worth the extra effort to either make them more descriptive, or to comment an explanation about all of them (or both!). Next (sauce), she hammers in the importance of commenting out the entirety of your code. It’s something all cs students have been pestered about endlessly, but it is one of the single most important things you can do to improve your code, being able to quickly understand what a method/class/etc. does saves so much time in the long run, outweighing the extra time you spend writing the comment. Her third point (meatballs) ties into this in that she recommends keeping most if not all debugging statements. She argues that once they served their purpose, they can simply be commented out and referenced in the future. Lastly (cheese), she emphasizes the importance of revisiting code “soon and often”. 

Admittedly, the advice Yung gives is pretty rudimentary. When I found this blog I thought it would talk about refactoring in the way we have in class, where we focus more on the structure side of things. However, reading this made me realize that this is very much refactoring as well. Sometimes the best thing you can do with your code is improve on the simple things, like naming schemes and comments, something Yung, an actual software dev, seems to find important enough to write a blog about. I am happy I found this blog; while I didn’t exactly learn anything ground-breaking, I realized that when refactoring, sometimes improving on the simple things is the best course of action to take. 

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

 Hello! For my second quarter blog, I read a separate blog written by Yung Han Jeong, titled “Spaghetti Deconstructed: Lessons from my first refactoring“. As its name suggests, this blog talks about Yung’s personal experiences and advice pertaining to refactoring. For those who don’t know, refactoring is essentially improving existing code in a way that doesn’t affect it’s functionality. This can be as simple as changing variable names, all the way to completely restructuring the program. In our class this semester, for a very large portion of what we will be doing, refactoring is an integral part of it. I would say at this point I am pretty comfortable with the topic, however I figured that I would like some sort of anecdotal, first-hand account of someone’s actual experiences with it, as everything we have been doing has been in a classroom setting. 

Yung’s blog recounts her experiences in refactoring some of her earliest code written when she was an entry-level developer, namely in her horror at how bad it used to be. It got her thinking about what she could have done to improve her code, which inspired her to blog about the biggest changes she thinks would make the difference (she provides four examples which she calls “pasta”, “sauce”, “meatballs”, and “cheese”, I don’t think I need to explain that). Firstly (pasta), she talks about the importance of having descriptive variable names. She argues that while it is enticing to have simple variable names that you might not see the need to go into detail about as you are familiar with the code, it is always worth the extra effort to either make them more descriptive, or to comment an explanation about all of them (or both!). Next (sauce), she hammers in the importance of commenting out the entirety of your code. It’s something all cs students have been pestered about endlessly, but it is one of the single most important things you can do to improve your code, being able to quickly understand what a method/class/etc. does saves so much time in the long run, outweighing the extra time you spend writing the comment. Her third point (meatballs) ties into this in that she recommends keeping most if not all debugging statements. She argues that once they served their purpose, they can simply be commented out and referenced in the future. Lastly (cheese), she emphasizes the importance of revisiting code “soon and often”. 

Admittedly, the advice Yung gives is pretty rudimentary. When I found this blog I thought it would talk about refactoring in the way we have in class, where we focus more on the structure side of things. However, reading this made me realize that this is very much refactoring as well. Sometimes the best thing you can do with your code is improve on the simple things, like naming schemes and comments, something Yung, an actual software dev, seems to find important enough to write a blog about. I am happy I found this blog; while I didn’t exactly learn anything ground-breaking, I realized that when refactoring, sometimes improving on the simple things is the best course of action to take. 

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

 Hello! For my second quarter blog, I read a separate blog written by Yung Han Jeong, titled “Spaghetti Deconstructed: Lessons from my first refactoring“. As its name suggests, this blog talks about Yung’s personal experiences and advice pertaining to refactoring. For those who don’t know, refactoring is essentially improving existing code in a way that doesn’t affect it’s functionality. This can be as simple as changing variable names, all the way to completely restructuring the program. In our class this semester, for a very large portion of what we will be doing, refactoring is an integral part of it. I would say at this point I am pretty comfortable with the topic, however I figured that I would like some sort of anecdotal, first-hand account of someone’s actual experiences with it, as everything we have been doing has been in a classroom setting. 

Yung’s blog recounts her experiences in refactoring some of her earliest code written when she was an entry-level developer, namely in her horror at how bad it used to be. It got her thinking about what she could have done to improve her code, which inspired her to blog about the biggest changes she thinks would make the difference (she provides four examples which she calls “pasta”, “sauce”, “meatballs”, and “cheese”, I don’t think I need to explain that). Firstly (pasta), she talks about the importance of having descriptive variable names. She argues that while it is enticing to have simple variable names that you might not see the need to go into detail about as you are familiar with the code, it is always worth the extra effort to either make them more descriptive, or to comment an explanation about all of them (or both!). Next (sauce), she hammers in the importance of commenting out the entirety of your code. It’s something all cs students have been pestered about endlessly, but it is one of the single most important things you can do to improve your code, being able to quickly understand what a method/class/etc. does saves so much time in the long run, outweighing the extra time you spend writing the comment. Her third point (meatballs) ties into this in that she recommends keeping most if not all debugging statements. She argues that once they served their purpose, they can simply be commented out and referenced in the future. Lastly (cheese), she emphasizes the importance of revisiting code “soon and often”. 

Admittedly, the advice Yung gives is pretty rudimentary. When I found this blog I thought it would talk about refactoring in the way we have in class, where we focus more on the structure side of things. However, reading this made me realize that this is very much refactoring as well. Sometimes the best thing you can do with your code is improve on the simple things, like naming schemes and comments, something Yung, an actual software dev, seems to find important enough to write a blog about. I am happy I found this blog; while I didn’t exactly learn anything ground-breaking, I realized that when refactoring, sometimes improving on the simple things is the best course of action to take. 

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

 Hello! For my second quarter blog, I read a separate blog written by Yung Han Jeong, titled “Spaghetti Deconstructed: Lessons from my first refactoring“. As its name suggests, this blog talks about Yung’s personal experiences and advice pertaining to refactoring. For those who don’t know, refactoring is essentially improving existing code in a way that doesn’t affect it’s functionality. This can be as simple as changing variable names, all the way to completely restructuring the program. In our class this semester, for a very large portion of what we will be doing, refactoring is an integral part of it. I would say at this point I am pretty comfortable with the topic, however I figured that I would like some sort of anecdotal, first-hand account of someone’s actual experiences with it, as everything we have been doing has been in a classroom setting. 

Yung’s blog recounts her experiences in refactoring some of her earliest code written when she was an entry-level developer, namely in her horror at how bad it used to be. It got her thinking about what she could have done to improve her code, which inspired her to blog about the biggest changes she thinks would make the difference (she provides four examples which she calls “pasta”, “sauce”, “meatballs”, and “cheese”, I don’t think I need to explain that). Firstly (pasta), she talks about the importance of having descriptive variable names. She argues that while it is enticing to have simple variable names that you might not see the need to go into detail about as you are familiar with the code, it is always worth the extra effort to either make them more descriptive, or to comment an explanation about all of them (or both!). Next (sauce), she hammers in the importance of commenting out the entirety of your code. It’s something all cs students have been pestered about endlessly, but it is one of the single most important things you can do to improve your code, being able to quickly understand what a method/class/etc. does saves so much time in the long run, outweighing the extra time you spend writing the comment. Her third point (meatballs) ties into this in that she recommends keeping most if not all debugging statements. She argues that once they served their purpose, they can simply be commented out and referenced in the future. Lastly (cheese), she emphasizes the importance of revisiting code “soon and often”. 

Admittedly, the advice Yung gives is pretty rudimentary. When I found this blog I thought it would talk about refactoring in the way we have in class, where we focus more on the structure side of things. However, reading this made me realize that this is very much refactoring as well. Sometimes the best thing you can do with your code is improve on the simple things, like naming schemes and comments, something Yung, an actual software dev, seems to find important enough to write a blog about. I am happy I found this blog; while I didn’t exactly learn anything ground-breaking, I realized that when refactoring, sometimes improving on the simple things is the best course of action to take. 

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