Author Archives: rainiery

Rest API Design

The topic I’ll be writing about this week is Rest API design which is one of the topics listed to be covered in the class syllabus, though we haven’t covered it yet if at all. It’s also worth noting that the following information is taken from the websites linked above. Rest API design or simply Rest stands for REpresentational State Transfer and is an architectural style for distributed hypermedia systems. The purpose of Rest is to create web services that have reliability, fast performance, and the ability to grow by reusing components that are managed and updated without affecting the larger system. There are six guiding restraints that an API must follow to implement Rest. The first is “client-server” which states that the client and server should be completely separate in order to improve scalability and portability. The second is “stateless” which means that each call should contain all the data needed to complete itself. The third is “cacheable” which means that the storage of cacheable data should be encouraged. The fourth is “uniform interface” which means the interface should follow four constraints: identification of resources; manipulation of resources through representations; self-descriptive messages; and, hypermedia as the engine of application state. The fifth is “layered system” which means ordering components in a layered system. The sixth and optional constraint is “code on demand” which means REST allows code or applets to be transmitted via API for use within the application.

            Rest API design is generally used to increase performance and make web services that implement is easier to use. For example, the first constraint “client-server” as I already mentioned earlier increases scalability and portability. The second constraint “stateless” reduces the amount of work a server or a client needs to do depending on which is calling. The same applies to the other constraints; they all improve on a web service in some way or another. Of the sources I’ve looked at, I could only find one major drawback which is that you can lose the ability to maintain state in REST, such as in between session. But even then, it’s not that big of a drawback since one of the constraints of REST is refraining to use states so it’s an intentional design choice. So overall, Rest API design is an architectural style that sets out to accomplish a specific goal and does it well with minimal drawbacks. And from what I’ve read, there is really no reason to not use it if states aren’t required and the goal of the designer is to save resources.

From the blog CS@Worcester – Rainiery's Blog by rainiery and used with permission of the author. All other rights reserved by the author.

Software Frameworks

            The link above leads to a website article that explains what a software framework is while giving some examples. The two main reasons I chose to write about this topic is because of one, it’s listed as one of the topics to be covered in class and two, I’m not too familiar with the definition of a software framework. According to the article, a software framework is essentially a set of tools that act as a foundation for software developers. These may include preset classes, APIs, compilers, code libraries, and predefined functions among other things. Examples of software frameworks include Microsoft’s .NET framework, Android Application Framework for Android, Cocoa Touch for iOS, and Cocoa for Mac OS X.

            From the definition given, the practicality of a software framework seems pretty apparent to me. Rather than creating classes and functions from scratch that will most likely see reuse, set them together in a ready to use package in order to save time and effort. It’s similar to how someone would buy ingredients at the supermarket rather than making each one from scratch. I’d imagine that software frameworks also have the added benefit of increasing portability for software that uses a specific framework. Take for example my computer which has .NET framework on it. If I were to create a piece of software using .NET, then another machine which has a similar version of same framework would be able to run my software with no additional setup needed. To be fair this is only speculation on my part; I haven’t checked whether or not this is true yet. But then again, I remember having to install a newer version of .NET framework in order for my computer to run software correctly so I might be on the right line of thinking.

In the case of porting software to machines with different operating systems, I’m not sure what role frameworks would take. I am pretty confident that software frameworks aren’t limited by operating systems. One example being Java Collections Framework or JCF for short which, as far as I know, isn’t limited to an operating system like .NET is. When a difference of frameworks is a factor, I assume that a software developer would have to make up for a lack of a framework’s components in a machine in some way. And that’s on top of the usual changes needed for porting software between operating systems.

From the blog CS@Worcester – Rainiery's Blog by rainiery and used with permission of the author. All other rights reserved by the author.

Thoughts on YAGNI

The link at the very bottom is an article focusing on a design philosophy YAGNI which is one of the topics we’re supposed to cover in class, though we haven’t gotten to it yet as of my writing this. The name is an acronym of “You Ain’t Gonna Need It” which is basically means if the situation doesn’t immediately call for something to be done, then don’t bother with it. The acronym’s meaning is also the main reason why I chose to write about this topic; it sounded funny to me. The article goes on to describe four “costs” that YAGNI mitigates. The first is the cost of build which is the time and effort spent on analyzing, programming, and testing something. The second is cost of delay which is the cost of pushing back other priorities in order to work on what is deemed more important. The third is cost of carry, the complexity that something brings to software and how that modifying and debugging more difficult. And the last is cost of repair which is self-explanatory. By only working on what is immediately important, the chances of wasting time or changing the program are reduced significantly.

What I find interesting about YAGNI is that in a way, it’s telling people to wing it. The biggest reason for that is because in everyday life, sometimes plans change because of unforeseen circumstances. Let’s take for example someone meticulously planning out a program while taking multiple scenarios into consideration and designing different components to compensate. But it later turns out that many of these scenarios are either unlikely or are taken care of by other things outside of the program that this person didn’t even know about. That in turn causes cost of carry because of all the components complicating the core program, cost of build from the time and effort wasted on designing and implementing these components. These are a lot of headaches that are solved by just being lazy and that’s kind of funny to me.

Something else I noticed is that YAGNI is a really simple design philosophy, to the point where it isn’t strictly constrained to software design. Another example I’ll bring up is how when I was younger, I would waste time writing essays by agonizing over small minute details. And a piece of advice I would often get is to write out my first draft no matter how horrible and worry about fixing the details when the time comes. That isn’t to say that drafting out an outline isn’t important; this applies both to essay writing and software design. The truth is that there should be a balance between YAGNI and other design principles which the article does acknowledge even though it does downplay it.


From the blog CS@Worcester – Rainiery's Blog by rainiery and used with permission of the author. All other rights reserved by the author.


Hello, my name is Rainiery and I’ve started this blog for the class “Software Construction, Design & Architecture” as well as for my career down the line.

From the blog CS@Worcester – Rainiery's Blog by rainiery and used with permission of the author. All other rights reserved by the author.