“Phoenix Product Codex” updated: brands, nested routes, plaintext responses

The first update of my Phoenix Product Codex book on building a production-ready REST API with Elixir and the Phoenix framework has been published. Here’s what’s new since the first release:

1. Various improvements to Chapters 1 to 3, such as the implementation of a :legal_name field for the %Supplier{} struct that gets conditionally populated depending on the EU VIES response.
2. The all-new Chapter 4, with the primary focus on modeling the brands table and implementing the /api/brands route.

In Chapter 4, we also:

• Implement a custom validation function for foreign-key values that works around SQLite’s limitation regarding Ecto.Changeset.foreign_key_constraint/3.

• Learn how nested routing works in Phoenix.

• Implement nested routes for GET requests that return nested JSON for a specific brand (/api/brands/:brand_id/supplier) and a specific supplier (/api/suppliers/:supplier_id/brands).

• Implement a route that returns the value of any field of a resource as plaintext with a GET request to /api/:resource/:id/:field in plaintext or, in the case of an error, an error in plaintext that’s generated by a custom exception we create. This makes the API usable by consumers that cannot parse JSON, i.e. also in a spreadsheet such as Excel or LibreOffice Calc.

In the next chapter, dropping in the next couple of weeks, we’ll continue working through the ERD of the database and the API’s endpoints by modeling the categories table and implementing the /api/categories route, possibly (TBD) also including the modeling of a parent-child association between %Category{} records (i.e., categories and their subcategories), as a precursor to being able to use the API as the Single Source of Truth for a hierarchical display on a web app.

We will not limit ourselves to just these core tasks, but also pluck one or two side-topics from the list in the “Coming soon” section (available in the book sample on Leanpub ) and work on them–most likely, on the multilingual descriptions. This means that we will start work on the rest of the Taxonomy context, as well as on the basics of content management, by implementing Ecto and polymorphic associations to manage various string fields (e.g., descriptions) in different languages across the various entities (Supplier, Brand, Variant, etc.)

• The book is available as PDF and ePub on Leanpub
• Join the discussion on elixirforum.com