Roadmap suggestion

[peteraba]

Hi @gernest,

First of all thanks for this project, I find it pretty handy and I find the code structure nice as well. I have a made a few modifications to it to better fit my need, but before I contribute back I'd like to discuss my ideas with you.

Features I already added:

1. Enabled various HTTP Methods.
2. Enabled imitating errors by optionally providing response code probabilities.
3. Make 201 the default response code for POST calls to make it more REST-compliant (http://www.restapitutorial.com/lessons/httpmethods.html)

Features I'm considering adding:

1. Reading an initial set of endpoints from a directory based on a CLI flag / Environment variable. (Currently I call a bash file on startup that will create the endpoints via curl, not the nicest workaround)
2. Reading a swagger file and creating endpoints automatically. (This might be out of scope, but I'd find it useful.)
3. Adding optional request validation based on the swagger file read previously. (I'm least sure about this one, but this would potentially make the error imitation
4. Support for more API frameworks.

What are your thoughts?

In case you wondered, this is how my API structure currently looks:

// API is the struct for the json object that is passed to apidemic for registration.
type API struct {
	Endpoint                  string                 `json:"endpoint"`
	HTTPMethod                string                 `json:"http_method"`
	ResponseCodeProbabilities map[int]int            `json:"response_code_probabilities"`
	Payload                   map[string]interface{} `json:"payload"`
}

(Changes so far are 100% backwards compatible)

[gernest]

Hey, thanks for feedback. I think the changes are good. So, we will need to breakdown, and implement the features incrementally in small patches to allow me to do review.

More discussion will be held on the patches (PR) since this is rather a long list and it is easy to miss small details.

One thing, can you expand more about ResponseCodeProbabilities and why do we need it?

How about we start with number 3(Make 201 the default response code for POST ) ?
Looking forward to your PR.

[peteraba]

I'm very pleased with you being so available.Thank you!

Well, depending on which #3 your suggesting it might not make sense without #1 or #2. :)

I need ResponseCodeProbabilities to be able to test error handling on my UI.

I"ll split my changes to 1+3 and 2 for the ones I already have to make it easier for you to review. Then I'll add PR for #1 from the proposed

[peteraba]

Btw, I have one more feature request which is not super mandatory but could be handy: being able to change the endpoints on the fly. Right now we just reject repeated registrations for the same endpoint.

[gernest]

Uh! I see. I get it now. I agree, we can change the registration object to reflect on which method the response should match.

So, I think ResponseCodeProbabilities will be an overkill for now.

type API struct {
	Endpoint                  string                 `json:"endpoint"`
	HTTPMethod                string                 `json:"http_method"`
	Payload                   interface{}            `json:"payload"`
}

Looks much convenient , we don't want to limit the payload to map[sting]interface{} there are cases you want to serve array of objects instead of maps.

[gernest]

Btw, I have one more feature request which is not super mandatory but could be handy: being able to change the endpoints on the fly. Right now we just reject repeated registrations for the same endpoint

Lets go slowly, one feature at a time. Maybe you can open a separate Issue for each feature so it can be easily discussed/tracked

[peteraba]

Looks much convenient , we don't want to limit the payload to map[sting]interface{} there are cases you want to serve array of objects instead of maps.

Well this sounds fine to me in general but not something I need right now.

[peteraba]

Hi @gernest, thanks for the quick code reviews so far. I just wanted to let you know that I'll stop working on the project for now until further feedback. What exists as a PR already covers all my current needs and I think if you'd prefer to keep this project simple, swagger support can even go into a different project which would use apidemic under the hood.

[gernest]

@peteraba thanks for the contribution. Glad you find this project useful.

[peteraba]

So I kind of had to create two new PRs to fulfill my needs:

1. I needed UUID generation, but added some number and boolean generation on the way
2. I needed to be able to return lists (as you mentioned above).

With these PRs in place I think I'll have everything I need for now.

[gernest]

Thanks a lot for helping me out. I'm happy that someone finds this useful

[peteraba]

@gernest and I thank you for the fast responses. It's been a very smooth experience to contribute so far!