Since we are using Go's httptest to simulate our IntelOwl server through by creating a mock test server from httptest.Server and using httptest.ServeMux as a router to implement our mock responses on the specified endpoint

Right now we need are initializing the test server with every test. By using gorilla/mux we can implement a request method-based router from which we only need to set up the test server once and keep using that for every test!

To implement a common setup and teardown we can use TestMain. For more information, you can read about it here.

Divide the project into a proper structure like pyintelowl. In this structure we will have the following:

• intelowl
• tests
• examples
• docs
• .github
• go.mod
• README.md

intelowl

this directory will hold the service objects such Tags.go, Jobs.go

tests

this directory will hold the unit tests of each service

examples

this directory will hold a basic example and an advanced example on how to effectively use go-intel

docs

this directory will hold all of the documentation related to the project. Inspiration will be taken from pydragonfly

.github

This will hold the github actions for CI-CD

go.mod

This file will hold all the dependencies needed for project if any are required.

• Implement error handling by dividing the errors into a struct called intelOwlError

• It will implement the go error interface so it's a proper Go error

Basic Concept

• Dividing the errors into an error helps with not overcomplicating things by making several errors again and again
• Simplifies things and is easy to maintain and scale
• Easy methods to get the data and relevant JSON.

Add up a Pull Request template similar to the one present in intelOwl

Description:
Playbooks could be high-level abstraction to an IntelOwl analysis. Pre-written playbooks that define a flow like:

 given an IoC -> run these particular analyzers -> run these particular connectors, etc.

More at: intelowlproject/IntelOwl#628

Useful reference: https://golang.org/doc/tutorial/create-module

• Barebones go.mod, go.sum files
• basic project structure with proper documentation for the IntelOwlClient struct and it's functions which can be published to https://pkg.go.dev/.
• maybe some github actions/workflow files which publishes to pkg.go.dev ? (I lack knowledge here since I haven't published a go package before so any kind of help is appreciated)

Can this be made an enum? Let's create an issue for this.

Originally posted by @sp35 in #36 (comment)

Currently in gointelowl_test.go the API token are exposed, it is desired to store them in a .env file and then use

Right now, Go-IntelOwl has only basic features. Are there any plans to turn it into a proper CLI? This would help us mature the library further as we go as we ourselves would come across multiple use cases related to this. I would love to help work this out if there are any plans.

While I am at it, I would also set up pre-commit for this project like there exists for IntelOwl and PyIntelOwl.

Since while accessing any property of a package, the client will write the package name, so there is no need to include package name in the content name.

e.g. in the file client.go, we have a struct named IntelOwlClientOptions. Whenever the client needs to access it, he/she writes :-

gointelowl.IntelOwlClientOptions{}

Here, the word IntelOwl is repeating 2 times! Instead, we can write :-

gointelowl.ClientOptions{}

The names of the contents of the package must be renamed to follow the conventions and avoid unneccessary long names.

Here is a screenshot from official golang blog

We should try to follow the same workflow of all the other projects:

• using master branch only for pushing new releases from the develop branch
• using develop branch as base repository and create new branches for new features from this branch
• adding linters for go code
• configure dependabot correctly
• enable code-ql for go
• enable them in github actions
• others I could have missed

Separate the API endpoints to their specific resource and make a service object in separate files. Furthermore, provide optional struct parameters.

• Separate the endpoints into service objects.
• Add their optional structs.
• Integrate context into the methods.

Add proper documentation. It will consist of the following:

• Getting Started
• Installation
• How-tos
• Basic & Advanced examples
  It will be a combination of IntelOwl and pydragonfly's documentation

Implement the builder pattern for making the requests in the Go Client!

I don't like approach of just appending functions to the IntelOwlClient struct.

This SDK should be created following the approach given in this blog-post, especially the "Service Objects" heading.

This approach is very similar to how we (at Certego) wrote pydragonfly recently using the django-rest-client framework (also written by us).

Better handling of mocks for service tests

Originally posted by @sp35 in #35 (comment)

Separate the API endpoints to their specific resource and make a service object in separate files. Furthermore, provide optional struct parameters.

• Separate the endpoints into service objects
• Add their optional structs

Add github actions for linting code and running the tests.

Like in Java we have Constants classes to keep all of your constants such as

1. Endpoints
2. Methods (GET, POST)
   It would be a good approach to add this as it is much more manageable, and idiomatic.

• Implement integration tests