REST stands for Representational State Transfer and API is application programing interface. Simply put, when there are multiple systems working together, a RESTful API allows a person to query or edit information in the system. I recently read a javaguides post on how to set up properly scalable API’s and wanted to share a short summary.

Tip 1: Domain Model-Driven Design
This means you should have the structure mirror the real-life pieces. So if, for example, you want the items of an order, the endpoint should look like “/orders/{id}/items”. Also, don’t nest it too deep, it will add needless complexity.

Tip 2: Choose HTTP methods appropriately
The 4 main methods and their use cases are; GET for getting data, POST for posting a new object to the database, PUT for putting a new object in place of an existing object, DELETE for deleting objects in the database. There is also PATCH which can be used patch an existing object. If you are using GET to modify an object you are adding unnecessary complexity. I personally will be adapting my use case of PUT after understanding the difference with PATCH

Tip 3: Implement Impotence Properly
A method is idempotent if no matter how many times it is called after the first, there is no behavior change from the first call. If you call DELETE multiple times on the same object then only that object should be deleted. GET is already idempotent, it will always get the object’s data regardless of whether you already called GET. PUT and PATCH should be implemented similarly to DELETE. The hiccup is with POST, because simultaneous calls are possible (two people can create new objects with the same identifier) logic to handle these calls needs to be made.

Tip 4: Chose the correct HTTP status calls
When a call is made, there are codes for the result. They are; 200 for a valid request, 201 for an object being created, 400 for an incorrectly formatted request, 401 if requester is unauthorized, 403 for a forbidden request, 404 if the object request is not found, and 500 for a server-side error. I am going to research more about how the permissions are set up when someone makes request and the logic behind blocking certain requests.

Tip 5: Versioning
Include which version of the API the request is using, maybe put it in the path “/v1/users”. They also list alternatives such as having a query parameter “/users?=v1” or adding a HEADER to the request that includes the version number. I never thought about adding versioning to the request but it makes sense to allow for previous versions to still request.

Tip 6: Use Semantic Paths
Singular resources use singular nouns and the path should be using the resources.
DON’T: POST /v1/loginUser
DO: POST /v1/users/login

Tip 7: Support Batch Processing
Something like:
POST /v1/users/batch
to allow for multiple users to be made in one POST.

Tip 8: Use query parameters for flexibility
You can add the ability to sort the data requested, or filter it, using queries. So:
/v1/users?age=gt:20
and
/v1/users?sort=name:asc
This is some awesome functionality and I cannot wait to implement it in my own system.

Link:
https://www.javaguides.net/2024/12/top-8-tips-for-restful-api-design.html

From the blog CS@Worcester – Coder's First Steps by amoulton2 and used with permission of the author. All other rights reserved by the author.

Quick recap of the first post, Miriam Posner saw an Agile team working and as an outsider decided to research more about the process. The article started with the defining of programmers as software engineers, an attempt to add structure to the confusing new field. From there was the “waterfall” development process, a term coined as a joke that was picked up by the management and used until the inflexible nature nature caused one too many projects headaches. A new movement was made by 17 managers who wrote the “Agile Manifesto” in February 2001.

Picking up from there Miriam goes into a little more detail on “waterfall” shortcomings as developers see it, the largest of which appears to be that any slowdown was seen as a ‘deviation from management’s careful plan’ because software development was inherently stable, at least from management’s pov. Agile was supposed to be about removing long-term, higher level plans set in stone in favor of short-term, quick-paced goals that would give more flexibility for developers. Remove useless meetings about every little thing so developers can actually fix the problems at hand. Miriam notes that at this time there were few qualified devs, so they had all the power and could have asked for unions or complete IP ownership. Instead they asked for more efficient working conditions so they could do their jobs.

While this sentiment from coders culminated in the 2001 manifesto, according to the Agile consultants Planview it took until 2012-2015 for more than 50% of active development teams to characterize themselves as “Agile”. So that was it right, new mindset and all’s hunky-dory. Except it wasn’t.

In a cruel twist of fate, Miriam noticed a flaw in that Agile team that she had been watching be so efficient and intriguing. They didn’t seem to be getting much work done. What had happened was that due to throwing out the top-down approach to project management, no one on the coder’s side had a solid concept of the project in its completed form. They had thrown out the baby with the bath water. Add on to the fact that, while definitely anti-management Agile was in a way very pro-corporate. The entire mindset was let developers put their all into the project, which in turn is believed to have contributed to the recently seen burnout rate increases. On top of this is the issue that, due to Agile’s inherently non-structured nature as a mindset, there’s no one thing someone can point to to say “this is not good we need to change it.” Since nothing is actually defined in Agile, everything is subjective and thus at the whim of whatever the company decides.

From this article I have come to see that flexibility in my future work is necessary, don’t try to plan every part from day one. However it is equally important to try to start with a skeleton, something that I can add my features to so that I know both where my projects are at as well as what it can become. Hopefully this adjusted mindset will allow me to continue doing what I love for a long, long time.

Link:
https://logicmag.io/clouds/agile-and-the-long-crisis-of-software/

From the blog CS@Worcester – Coder's First Steps by amoulton2 and used with permission of the author. All other rights reserved by the author.

This article is a beginning-to-end write up of the Agile methodology by Miriam Posner, an Assistant Professor at UCLA. She starts with a pov of someone watching an agile team in action, complete with all the user stories, story points, stand ups, a whiteboard, post-it notes, and sprints. For those who have not been introduced to this software development process, ‘stories’ are descriptions of features with ‘points’ showing the difficulty of implementing said features. ‘Stand ups’ are start-of-the-day meetings done standing up for quickness, the whiteboard is to organize each story point, represented by post-it notes, into the stages of ‘in-progress’, ‘done’, ‘backlog’, etc. ‘Sprints are just quick two week long work periods that help to break down the project into digestible chunks.

While this might seem rather much from to some people, others might have an opinion closer to Miriam, who found it to be efficient and intriguing. As such she researched the origins of Agile and learned the complicated history of managers and software developers. I will try to keep this summary brief while hitting all the major points.

Miriam starts with the buildup to Agile. It started in the 50’s and 60’s, most ‘experts’ said building the computer was the hard part and programming it would be trivial. The sheer enormity of their incorrectness led to a push in the field to adopt the name (and stricter processes) of engineering, leading to the coining of the term ‘software engineering’. The idea was that by following engineering techniques the experts would “transform the arcane and error-prone craft of computer programming to meet the highest standards of the engineering profession.” The next people to step in were the businesses who looked to hire these new ‘software engineers’. They created a framework of control where one person defines the project and breaks it up into steps, which are in turn handed to engineers to build and test before moving on to the next step. This was derogatorily called the “waterfall” method, so of course upper management took the name and method and ran with it. This method started to fail due again to people who were not programmers believing they knew what programming entailed. The main problem was that whenever any issue came up in the code, every step needed to be redone which meant the timeline would be increasingly muddled.

Next came Agile, created by “17 middle-aged white guys dressed in khakis and dad jeans” in the Agile Manifesto. In their words:
“We are uncovering better ways of developing software by doing it and helping others do it.

Through this work we have come to value:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.“

I would like to continue this dive but I am out of words.

Have a good day.

Link:
https://logicmag.io/clouds/agile-and-the-long-crisis-of-software/

From the blog CS@Worcester – Coder's First Steps by amoulton2 and used with permission of the author. All other rights reserved by the author.

I just recently finished learning about git in a classroom setting, so every step from forking to cloning to branching and staging then committing into pushing ending with pulling. All the parts to get the gist of git, but nothing in the way of advanced use. Enter this article written by Gitlab.

As its title suggests, “15 Git tips to improve your workflow” has 15 total tips in regards to git, so lets go through some of them together.
1. Git aliases; amazing function, to think that rather than checkout, branch, or commit I could use a custom name. This is, in my opinion, great for new devs since once they grasp the concept of what a command does they can alias it to something that makes sense to them.
2. Visualizing repo status with git-prompt.sh; needs to be downloaded but definitely a useful tool for people like me who benefit from a more visual experience.
3. Command line commit comparisons; definitely more of a practical command that is helpful to see your workflow. Definitely going to be using this one to help me track what I actually worked on and might even download the Meld tool they mentioned.
4. Stashing commits; another practical command that makes sense just for a dev to know. If you have to push a sudden fix in the middle of adding a feature you can stash the changes made for the feature, commit the fix and then just pop the stash to get back all the previous work.
5. Pull frequently; nothing to add.
6. Auto-complete commands; tab to automatically finish a word is also applicable in search engine prompts as well. So useful for a new dev since if they forget the command but remember the first letter they can just flick through the commands until they find what they were looking for.
7. Set a global .gitignore; create a list of files to remove from commits and put it on the exclusion list, nice and simple.
8. Enable autosquash by default; had to look this up, apparently the squash command merges commits into one big commit. Personally not too sure of the use case so will have to test it out at a later date.
9. Delete branches locally that remote removed when fetching/pulling; as part of fetch, there is a prune attribute that will work this functionality and it just needs to be set to true.

Obviously there are 6 more tips and they are: Use Git blame more efficiently, Add an alias to check out merge requests locally, An alias of HEAD, Resetting files, The git-open plugin, and The git-extras plugin. I will not go over them here but definitely give the article a read if you are interested.

Link:
https://about.gitlab.com/blog/2020/04/07/15-git-tips-improve-workflow/

From the blog CS@Worcester – Coder's First Steps by amoulton2 and used with permission of the author. All other rights reserved by the author.

The first time I was taught about ‘Smells’ in code it was in connection Robert C. Martin’s “Agile Software Development, Principles, Patterns, and Practices“. For those who have not read it, starting from Rigidity we have Fragility, Immobility, Viscosity, Needless Complexity, Needless Repetition, and Opacity. All of these are categories of red flags in code, they are problematic because over time they make the code “hard to understand, modify, and maintain”. In an earlier post of mine, I talked about design patterns which are proven solutions to common coding problems. So when I saw an article talking about smells that can come from these design patterns I was intrigued. This eventually lead me to find out that the Singleton design pattern specifically is considered by many to be never good to use.

In an article titled “Examining the Pros and Cons of the Singleton Design Pattern“, Alex Mitchell first explains how the goal of the singleton design pattern is to “ensure a class has only one instance, and provide a global point of access to it.” He then goes on to list the pros, which, for those who do not know or remember, are; it insures only one instance exists throughout the code, it allows for that one instance to be called globally, and it limits access to that instance. Then he gets to the cons, first of which is it violates the single responsibility principle. Next up is the pattern’s tight coupling followed by how it complicates testing and finished with it obscuring dependencies. He then offers an alternative to singeltons in the form of Monostate or dependency injections and then a nice conclusion to wrap it up.

Lets go in order for the cons. Con #1: on a second look this seems obvious, the singleton class is simultaneously controlling its creation and managing access to itself. Con #2: again on second blush its because there only being one instance of the object means you cant use polymorphism or alternate implementations. Con #3: you cannot test in isolation since a singleton persists globally across tests. Con #4: the dependencies are not explicit when the singleton is used. The Monostate pattern allows for multiple instances to exist while having the same logical state, so while config1 and config2 can both change configValue, getting configValue from either config1 or config2 would return the same value. Dependency injection is, as far as I understand it, passing the singleton into the class that uses it, so rather than referencing the singleton it just has the singleton inside the class.

From this article I have come to a better understanding of dependency injection and will probably be using this framework in my future code since apparently a lot of code still uses the singleton pattern and dependency injection seems to best handle existing singletons.

Link:
https://expertbeacon.com/examining-the-pros-and-cons-of-the-singleton-design-pattern/

From the blog CS@Worcester – Coder's First Steps by amoulton2 and used with permission of the author. All other rights reserved by the author.