With a few articles (Vue Twitter Bot & React Twitter Bot) recently talking about creating automated Twitter bots for posting articles for a particular topic, I thought I would chip in and write a basic library for any .NET clients. It is a fully async library using .NET Standard.
Turnerj
/
forem-dotnet
.NET API interface for Forem apps. Forem is the platform which powers DEV and other online communities.
Forem API for .NET
API interface for Forem apps. Forem is the platform which powers DEV and other online communities.
API Support
We attempt to support all the API endpoints per the Forem/DEV API, which includes:
- Articles
- Users
- Podcasts
- Videos
Where available, the library supports pagination and page size controls If there is an API endpoint that isn't currently supported, feel free to open an issue or create a PR.
Getting Started
Installation
To install the library run the below on Nuget Manager Console:
Install-Package Forem.Api -Version 0.4.0
Usage
-
For Some of the methods, DEV API key
apiKeyis required to be passed to authenticate you as a user To obtain one, check the authentication section GET API KEY -
Using DI, Add the service to the container just by doing the below:
services.AddForemApi(new Uri("https://dev.to/"))
-
Configure your
HttpClientDI by adding…
It is early days as the API is likely going to change a bit and probably will need an API key at some point but might help some people get started easier.
You can grab it on NuGet here.
Happy to work with the DEV team to make sure this library supports the current and future APIs for the site. 🙂
Top comments (9)
Hi James! Well done! I feel like more tools and clients will appear this year :-)
The great thing about having a public API is to witness what the community will come up with! I remember Ben saying they will likely open up the API in 2019 so hold tight :D
A technical question: the fact that it's async means that the whole app has to be async? I'm not familiar with modern .NET.
Usually the things go in the other direction in open source. A third party library pops up, it gets used by many people and form a community around it and then possibly it gets "officially" adopted by the mother project, or at least endorsed on their GitHub page.
A couple of examples: Python's json and multiprocessing were added way back in 2008 to the standard library because the respective third party projects (simplejson and multiprocessing) were used by everyone and it made sense to make them part of the language. Ruby's arel was heavily used by Rails and a ton of other projects for many years before Rails officially decided to adopt it and move it under its umbrella.
This is mainly because "adopting" third party code is always a gamble. You have to have intimate knowledge of the project, a few successful use cases, a very active maintainer and a developed community. It's not your case because you just started but when you adopt a third party library you also adopt its issues and technical debt. Playing devil's advocate: what happens if a maintainer gets bored after six months? The core team implicitly takes a vow to be on top of the library no matter what. We all know how hard it is to be on top of open source projects :-) Another helpful thing is usually competition, there are a ton of JSON libraries for Python :D
In the meantime my suggestion is: work on it, publish it, document it, add the missing endpoints little by little and attract a community around it, so it becomes the .NET library to interact with dev.to, you don't need an official sigil ;-)
Thanks Rhymes!
Any code that calls the library should be async though it is technically possible to avoid it (but it isn't recommended). Any other code that doesn't call the API doesn't need to be async though.
With everything else you mentioned, I do understand where you are coming from. In my experience, I have seen libraries written and published then repository names change, package names change, links broken etc from this type of action changing in the future. I want to avoid all that future mess and have where I would consider the final location etc.
If it was an "official" package, probably would be able to work a bit closer with the API devs to make sure I have the current and future functionality covered in a timely manner.
As I imagine this will be one of several libraries across several languages that will be written for dev.to, I want to make sure I work with whomever to make sure that the experience is consistent.
That said, you're right, I should keep documenting and publish what I have now so people can consume it regardless. 🙂
Got it, it works like everywhere else :D
BTW, I've put it on NuGet like you suggested 🙂
nuget.org/packages/DevTo.Api/
Well done!
This is great I was just thinking I would like to do some automation against DevTo, and was there an API. Is there API docs or are you capturing actions via the browser/some other tool?
I hope you don't mind, might be inspired to try and make an implementation in Python. :)
Just commented on Aaron's about the same thing but basically, there is no formal documentation that I could find - I based it partly on a comment from Ben, some guesswork and going through the source code of Dev.to
You should 100% totally make an implementation in Python 😁
Nice!
Are there API docs for dev.to? I'd be happy to help add some functionality if needed but I can't for the life of me find the docs anywhere 🤣
Nah, I worked it out myself from a comment from Ben, some guesswork and going through the source code to the site. I think because the API is still being developed, there is no formal documentation on it yet.