Hello all who are reading this, on this post I’ll be discussing a blog that I found in the link just below this paragraph. This particular blog post written by Douglas Minnaar gives a great overview of REST API’s and the knowledge necessary to build them in a structured manner. The blog begins defining the REST acronym, who defined and coined the term, and why one might use the REST style.

https://dev.to/drminnaar/rest-api-guide-14n2

This first part covering the general fundamentals provided a clear and concise picture of how one should structure a REST web structure. In the first part it covers specifically the six architectural constraints of REST. One of the more important constraints I thought was the concept of a Uniform Interface and the ‘principle of generality’ which describes avoiding making a complex interface when simplicity would be far more advantageous across multiple clients.

Another constraint covered was the Layered System. In the blog it is described as more of a restraint for the client, that they should be decoupled in a way that allows the server to work without the client assuming what the server is going to do. It allows the server to pass it through stages like security and other tiers without the client checking back or communicating with it to verify as to not disrupt the process or possibly break security.

Part two shows an HTTP API to go further into the constraints described in part one and how to define the contracts for resources. I felt this part went by a little bit too fast without accurately describing more about what a contract is or what your resources should be but it did show some great points on their naming conventions and how best to rank them, these being techniques I’ll want to apply later should I work further with a REST API. The other sections of part two includes status codes, which I already had learned about in class, and content negotiation. Content Negotiation was very short and only really described as to pay attention to primarily json or xml and throw a 406 code otherwise.

The third part actually gave an example project based off his guide and the Richardson Maturity Model, which in part one is described as a leveled list into how ‘mature’ or as how I read it, how well designed a model is based off how many URI’s a service has and if it implements multiple HTTP methods or status codes. The architecture of the project uses the Onion architecture which I found interesting and almost immediately understood only because of how an onion is structured. The “Ranker” project is mostly an application of the REST architecture and by circumstance is also a movie ranker? It mostly allows you to manage users, movies and ratings but the core of this project is to demonstrate REST and the Richardson Maturity Model and its methodology.

 I felt like this particular blog post gave me some new concepts to think of when working on a REST API as well as some general formatting properties.

From the blog CS@Worcester – A Boolean Not An Or by Julion DeVincentis and used with permission of the author. All other rights reserved by the author.