Thanks for thinking of us @AstonJ 
We’ve been discussing Phoenix lessons and would welcome input from others.
@chuck what things specifically would you like to see covered? I’d be happy to set aside some time for a blog series to help yourself and others until we can formulate a plan for actual lessons (and translations).
If you’re interested in collaborating together let me know! Always happy to help folks 
Ideally, there would be complete end-to-end documentation for Phoenix for API developers. It wouldn’t assume any knowledge of Phoenix. It would be updated to reflect any changes introduced by new releases of Phoenix, i.e. it should be supported.
A lower effort alternative would be parallel sections in the current documentation with information specific to API developers.
An even lower effort alternative would be a separate guide devoted to API development.
I would and may help with these eventually, but right now I’m not far enough along on the learning curve myself.
I think they will need more specifics. Since I’m on the same boat as you - Learning Elixir and Phoenix while developing Web APIs - I’ll try to help:
It’d be great if the Phoenix guide have a section on Web APIs. This will save us time as we don’t have to find the info inside the Views section.
That section should start by stating that a great way to start is by running the generator with the no-html and no-webpack options.
It should also mention that if you’re not using a database and you don’t need bi-directional communication, you might consider not even using Phoenix at all as Elixir, Plug, Cowboy and Jason should be sufficient.
Then, it could mention that other stuff you need is the same as regular Elixir development, e.g. Supervisors, GenServers, ETS, CacheX, CVS and/or XML parsing, etc.
That’s a very short summary of what I have learned. What do you think? Am I forgetting anything important?
What does this mean to you though? What are the specific topics you’re not clear on? “Complete documentation” means something different to everyone who reads it.
Are you looking documentation down to what JSON and an API are? I’m trying to get a sense of how granular you’re looking to go.
If you were going to write a book for developing JSON APIs, what chapters would it have to have?
We’re working on a blog series over at elixirschool.com on this very thing! The first post does focus on HTML just to illustrate how simple that can be without Phoenix but there is a small section on using JSON: Building web apps with Plug.Router | Blog · Elixir School. Next post will cover deploying our sample application to Heroku followed by a post series focused on building JSON only API using Plug.Router. I’m sure we can find a way to work in a post on using Phoenix for the same task.
I’m not sure this fits in a guide to developing JSON APIs though. We have most of this content on elixirschool.com already. Maybe we would benefit from a section focused on apply of these concepts?
We started on a repo of partial projects that you can finish yourself to explore Elixir but it could certainly be improved: GitHub - elixirschool/homework: A collection of coding exercises to be completed in conjunction with the lessons available on elixirschool.com · GitHub
I was just suggesting that the Web API section should state something like “from here on is the same as any other Elixir app”, or “For all these subjects, see their specific sections”. It’s just to emphasize what everyone keeps telling you the first time you ask the question which is: “there’s no really much difference” 
Perhaps, the question won’t be asked this often then.
Great news about the new upcoming content. Keep up the good work
I gotcha! Just to reenforce to the reader that from here on out it’s Elixir as usual, the API part is “over”.
Thank you! If you have any suggestions for content or changes we’re all ears
Imagine everything taken out of Phoenix that pertained to rendering the user interface layer. All that is left is the capability to develop REST APIs. Now think of how you would document just that? The documentation would be a lot smaller than the current documentation, but there would still be a lot to document.
Definitely you would assume that your readers are very knowledgeable regarding JSON/REST APIs. That’s why they are looking at Phoenix (lite) in the first place.
Exactly. This question appears so often here, and on other sites/forums. That I think it should be answered asap.
Great. Let me collect my thoughts, and I’ll send those directly to you guys. Also, I hope to have more in the future