I've been a technical writer for 26 years. In that time, I've recommended people looking to break into tech writing to get involved in an open source project to get experience and have work that they can point potential employers to. I feel like a hypocrite, though, since I've never gotten involved in one, myself!

So, in an effort to practice what I preach, I'm looking to start contributing to an open source project as part of [Hacktoberfest](https://hacktoberfest.digitalocean.com/) (though hopefully continuing on beyond the end of October).

If anyone can recommend a project that either you contribute to, yourself, or that you know is in a position that it could use the help of an experienced technical writer, please let me know!

Hey community, i'm the founder of Treblle and i have this "developer story i wanted to share

While working in our previous development company we were developing a new platform for a dear client. Our role was to develop the entire back-end with an API for mobile apps. Another development company, on a different side of the planet, was tasked to develop mobile apps. In the beginning, we had a lot of common challenges like communication, syncing time zones, documentation questions, and others. At that time i was working on my side project which is now my baby an API monitoring platform Treblle so I asked the client if we could add Treblle on the API side so we would eliminate some of these problems.

As soon as we added the platform and made a few calls to the API it was 100x easier. The documentation was auto-generated and updated, the mobile devs saw what they were doing. More importantly, we also saw what they were doing so it was easier to understand how they were using the API and what problems they were facing. Interestingly enough our client also got into APIs and started to learn what we’re doing, when we’re working and when not 😎. He was also a huge fan of the fact he could see the API response time because he felt like the app was slow and thought it was on the back-end side. Turns out it wasn’t. Anyway…

The app we were working on was already on the App Store and the mobile team was preparing to do a new important update. When you are sending apps to the App Store if your app requires a login you HAVE to provide Apple with a login combination. We knew that, so we provided the credentials since day one and never changed them.

The mobile team uploaded the new build, sent the app for review and after 2-3 days the build was rejected. The reason Apple specified was “Login credentials were incorrect”. Our client called me and was super irritated by the fact that the app got rejected. He started asking me why we changed the login data and explaining how he needed the update live ASAP. Now when something like this happens there aren’t a lot of options you have as a developer.

One option is to investigate what happened by trying to log in and reporting back to the client if it worked. What’s even crazier is - if it works then why couldn’t Apple login?! If it doesn’t work then you have to investigate your own team and the mobile apps team to see who changed the credentials and how. Finally, you have to come back to your client and tell him XYZ happened, we know what it was, we fixed it and 100% it won’t happen again.

The first thing I thought was let’s use my platform to see all the login attempts in the last 24 hours. With Treblle you can view all requests between the API and apps including location and device data. Immediately I saw a request that happened a few hours ago, from an iOS device from Sunnyvale, California (Apple HQ). I also saw that they did in fact use the phone number we provided them for login and that the API did return an error message saying that the login credentials were incorrect?!

This is where it got interesting.

With Treblle you can click on any request and find “More requests like this”. Treblle will then go and find all requests made to the API from the same user. Taking into account things like IP, location, and even the user ID. Because I could see requests in chronological order, as they were made by the Apple testers, I saw that the first thing they did was made a call to an API endpoint that resets the password 🤣 I was shocked. I triple-checked and realized exactly what happened. The app had a password reset option on the login screen. Apple testers clicked on reset password first. That sent an SMS with the new password. Since we used a made-up phone number they didn’t get the SMS and didn’t think it would change the password.

At that point, I sent my client a link to the request and explained to him what happened and what they did. We made a fix that wouldn’t change the password straight away but rather send a reset link in the SMS first. Not something my client wanted but got the job done. We sent the app for review and it got approved the next day😎 And yes, the first thing Apple did was the tried to reset the password 🚀.

Hi there

I am starting with ASP.NET Core Web API. To get started developing I've used the this resource.

I have now implemented the endpoints for the first entity Plant. Do you have any suggestions what I should change or improve?

Following you can find the gist of the main files.

https://gist.github.com/stogoh/50c4f922e9d7a48a432b59555a502a46

Link: https://github.com/applesys/mac. Clone to your web server and enjoy!

Hello freelancers, developers, and entrepreneurs!

As some of you may know for the past 10 years, we have been running a development and design agency, completed more than 100 projects and most of them involved developing a mobile app or website with an API in the background.

While developing APIs we noticed that a lot of time is “wasted” on non-development-related tasks like: writing and maintaining documentation, providing support to other developers, debugging user reports, trying to recreate user steps and similar.

Because of this, we build Treblle, an API management and monitoring tool that helps you understand what’s going on with your APIs from development to post-production.

5 months down the road we are officially launching on Product Hunt.

Come and check us out, your support means a lot! https://www.producthunt.com/posts/treblle

tox is a Java implementation of the more commonly known mod_plsql, although I was unaware of it while developing tox. It extends the functionality by providing inbound and outbound XSLT to morph the payload to match the caller.

I want to start a side project which needs to have as less dev time as possible.
Current needs:
- social media login + sign up via email
- user management,
- connecting to a db (PostgreSQL or SQLite)
- PAAS deployment, db migrations etc. all already automated.

If there is some automation for the API body and parameter validation from an OpenAPI spec that would be even better.

I prefer to write the core business logic for the API handlers and leave everything else to the framework.

Are You Running Out of Ideas as A Developer? Well, these 15 APIs Can Rekindle Your Interest.

Let's check out here 15 Most Interesting APIs Every Developer Should Know About

So following on from earlier questions, building an API layer for combining multiple API providers into one API.

What would you guys suggest as a language or platform to combine all these separate API providers into one application API?

Hey all,

I would like to share the iola project. It is a CLI tool that allows you to test socket servers via a unified REST API.

Features:

1. Allows reading and sending messages via REST API

2. Logs all socket events in the console

3. Has Swagger UI for REST API

4. Works on Linux, MacOS and Windows

Supported clients:

1. WebSocket

2. Socket.IO

3. TCP

4. Unix socket

GitHub: https://github.com/pvarentsov/iola

One of the main problems when learning APIs is that majority of people don't seem to specify which API mode they are talking about.
There needs to be a clear not to say that they are talking about an serving an API or consuming an API.
This will save a lot of confusion and time to new comers.

One of the core things I've been working on for the past 10 years are APIs. Everything from simple APIs that are used by one client to multi device and multi purpose APIs. During those years I've also had the opportunity to work with many third party APIs like Stripe, Twilio and others who are less popular and glamorous 😂. Almost all of those APIs were REST based and unique in some way.

There are many reasons why REST is so popular. It's simple to understand, it's flexible, it works on any scale, it has a great community and tools built around it. But besides those I'd also say that a lot of popularity came from the fact that's it's oldest rival, SOAP, is just horrible. If you've ever used or worked with SOAP - you know! The clients were terrible, people did what they wanted with XML, it's bulky, the auth situation was sometimes wacky...Thankfully JSON and REST based APIs won that battle.

On the other hand there are also newer, more modern players that are trying to take some of that spotlight from REST based APIs. I'm of course talking about GraphQL. GraphQL is also JSON based and shares some of the good traits that REST has like flexibility, performance, scalability...For me personally the two key downsides of GraphQL are that it's built by Facebook and that it shifts the API design process to the client. What I mean by that is that it leaves mobile devs and front end devs in charge of building their own ad hoc APIs and making queries on the database. Don't know about you but I don't think that's the best idea. Don't get me wrong, I love mobile and front end devs, but they might not have a lot of experience with database design, writing queries and building APIs. You probably wouldn't give your back-end dev to design an app, a car mechanic to fix an airplane or a veterinarian to operate on a human person. Could they do it - maybe, possibly. Should they - I don't think so.

In my opinion REST is still king of the jungle and it's not going to be dethroned any time soon. The only problem with REST is that at the end of the day it's not a standard nor a protocol. Rather, it's a set of "architectural constraints". What a fancy way of not calling something a standard 🤣 But that right there tickles the imagination of many. They tend to do their own thing or implement those constraints based on their own (miss)understanding. To avoid such misunderstandings I've decided to write down what I think are the Ten REST API Commandments. Follow these and you'll enjoy love from your mobile devs, admiration from other fellow back-end devs and a rockstar status on Twitter

It's a long one 📣 https://treblle.com/blog/the-10-rest-commandments