Philosophy and Architecture¶
This page contains information on why and how ripozo is architected.
Ripozo is designed first and foremost behind the belief that Hypermedia APIs are the way everything should be developed. With hypermedia APIs and good client consumers, boilerplate code is removed and a developer is free to focus on making the difficult decisions and writing the business logic, not the boiler plate code. It should be noted that ripozo goes beyond CRUD+L. CRUD+L is a good step in the right direction, but it still requires too much knowledge on the client side still. With true Hypermedia, the client doesn’t need to how to construct URLs or what the actions available on a given resource are. The server can simply tell you.
Unopinionated (unless you want it to be)¶
Ripozo doesn’t make design decisions for you. Ripozo is a tool that is capable of being used in any existing web framework. It can be used with any database. Any Hypermedia protocol can be used. If you really wanted to, though we don’t recommend it, you could even render raw HTML with a tool like Jinja2. You could even theoretically skip the web application all together and use it directly instead of through a web api. Long story short, Ripozo doesn’t care how it is used. It can be plugged in for a small part of your application or used exclusively.
Extensible and Pluggable¶
Ripozo is extensible/pluggable. Just because ripozo itself doesn’t make design decisions for you doesn’t mean that it shouldn’t be batteries included, we just believe that the batteries included versions should be split out into other packages. Hence its extensibility. There are already packages that make it easy to use both Cassandra and SQL databases via cqlengine and SQLAlchemy. There’s an adaption of ripozo for integration with Flask. We didn’t want to make design decisions for you. But we figured that if you wanted something more opinionated, we’d make it easy to extend ripozo. As a side note, we really hope that you open source any ripozo based packages that you create and let us know. After all, let’s keep our open source world DRY.
Alright, so you’re probably tired of hearing about all our self righteous talk about ripozo’s philosophy and want to know how you can actually use it to start building awesome APIs. Ripozo has four basic pieces: Dispatchers, Adapters, Resources, and Managers. tl:dr; version: Dispatchers handle incoming requests and direct them to Resources. Resources perform the business logic, optionally using a Manager to interact with a database. The Resource returns an instance of itself to the dispatcher which determines which Adapter to use. The adapter then takes the Resource instance and formats it into an appropriate response. The dispatcher then returns this response.
Now for the more detailed descriptions...
In this base ripozo package, the dispatcher is simply an abstract base class with a few convience methods. Since the handling of incoming requests is dependent on the framework you are using, and we don’t want to make design decisions for you, we thought that this would be a bad place for making opinionated decisions. However, the upside is that it is very easy to create dispatchers. In fact, a Flask dispatcher has already been created and is only one file less than 100 lines long. In the future we will be adding more webframework specific dispatchers and plan on making a framework of our own that is specific to ripozo.
Resources are the bread and butter of ripozo. They determine the business logic of an application. Resources should be reusable across all ripozo dispatch and manager extensions. In other words, you should be able to take your ripozo resources that you originally developed for Flask and plug them into a Django application.
Managers are more or less the state keepers of the application. They are primarily responsible for providing a common interface for basic CRUD+L actions exposed in the restmixins module. Additionally, they should be capable of inspecting the record being persisted and providing default fields for that resource.
Adapters determine the format in which to return a response. They take a resource instance and generate what the response should look like. For example, you could have an adapter that returns a SIREN response and another adapter that returns a HAL response. The best part is, that these are entirely reusable. That means that you can support as many adapters as are written by anyone in the world with no extra work on your part outside of installing the extra adapter packages. This is extemely useful because you can write your logic once and not have to worry about duplicating your code so that the front-end web team can use SIREN and the mobile team can use basic CRUD+L.