Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Current »

This is a partial copy of README.md that can be found in the repo.

Basicly

This version is not to be found in the master branch. Checkout develop/4.0 to follow it. Each thing build (except the initial embryo where the major ideas are imported and improved from v3.0) SHOULD ha ve a task, a branch, a commit, reviews and so one. If this API should be publicly available you have to push yourself with requirements. This is the one.

Besides, this release will be much more based on PSR4 autoloading. This means that each endpoint can be autoloaded, which 3.0 did not fix. Also, being able to composerize API endpoints is another goal for this project. Like the NETWORKTOOLS endpoint.

Ideas

The API itself is from it's initial birth database-less. This means the API base should be run freely without any connections at all. However, as there is endpoints that probably should be authenticate against there will be an implementation of this. And this is one of the reasons why things are taking time; the libraries used is another project bases, built to be able to move around between platforms even if correct drivers is missing on them.

The same idea lies ahead of other libraries. Most of the projects found online has some problems; they have to be configured from scratch. The most common example I've found this far is communications libraries that takes care of webcalls. There are several libraries that fix this communications - Zend, Guzzle, Curl to mention some. But this is always time exhausting, to for many years ago I wrote my own library - today called NetCurl. This library was written to adapt to available drivers with focus on curl. If curl was available, curl was the first option to use. If it wasn't, the library was supposed to choose streams, etc. The purpose was to scan for proxies automatically, and collect them to the DNSBL Historical summary. There was also a SoapClient that was born later on, very much to handle other communications too (like Resurs Bank ecommerce APi's).

Most of the other suggested libraries had to be configured from scratch. The above library mostly did do this for you. It went extremely verbosed and parsed data out to best available format. If the websided returned JSON data, it returned a JSON object to work with and so on. This is to be implemented in APIv4 too. However, v6.0 is about to get a bit old and nasty so v6.1 is planned - also here with a PSR4 base. But for now, this is actually irrelevant as we start running on v6.0

Where to find everything about v4.0

  • No labels