Preferences UPDATE, CREATE, DELETE about mailjet-apiv3-java

[Gormador]

Hi @kaveiros,

Not all HTTP verbs are available for each resource. And that makes sens because not all resources should be create-able or delete-able for example.
Make sure that the resource you are trying to work with has the verb available. This kind of information is available on the API reference page.

Also, if you find a resource that isn't correctly implemented in the java wrapper, the best is still to mention it in the issue ;-)

Cheers,
Gaëtan

[kaveiros]

Thank you for the answer Gormador
There is an issue here, that is exactly what i mentioned. Your documentation for PREFERENCES class says it supports and got to have .Delete and .Create and .Update and .Get and .List. There is only .Get and .List implemented.
Any specific comment on that?
There is a much similar issue at CAMPAIGNSTATISTICS and at APIKEYTOTALS, both of which do not have the .Get function for their View part. Only .List is implemented.
Remaining yours

[Gormador]

Hi @kaveiros,

My bad, I misunderstood your question.

At the moment, their is a mismatch between the metadata used by the java wrapper and the one used by the reference. However, the java wrapper is the most up to date one and contains a change regarding the available public operations on the preferences resource. This means that, by design, it is no longer possible to perform a POST, PUT or DELETE on this resource, only GET.

Regarding the campaingstatistics and apikeytotals resources, they don't have an ID per say. The apikeytotals resource is bound to the API Key pair you are using when issuing the call and thus only ever exists once in a given context, which means that the .GET function isn't necessary. The reference page will be updated to better reflect this particularity.
For the campaingstatistics resource though, thinks are a bit different. It has no property named ID but the one called CampaignID acts as one. However, from the java wrapper point of view, this doesn't suffice to generate a proper .GET function.

If necessary, I can come up with a temporary fix and supply you with a distribution of the wrapper that allow the operation.

Anyway, thank you for reporting the issue!
Cheers.
Gaëtan

[kaveiros]

Thank you for the reply Mr.Gaetan
Those functions on the preferences resource that are no longer available in the wrapper, do they exist in general?
Do you mean that only the documentation is not up to date(because you wrote "no longer") or that those features are not available in the java wrapper context but available elsewhere and in another way?
If they are, i would be delighted to have a temporary fix that will be working, but i will need it in the near future, maybe after i come along other issues of the same nature when i have almost finished working with your excellent project
Cheers again

[Gormador]

Regarding the preferences resource, what I meant is that what is available in the java wrapper is the correct version of the API: it isn't possible to perform POST, PUTor DELETE on this resource anymore. For internal reasons, only GET remains.
The documentation will be updated accordingly.

Every preference listed in this resource is set from your Mailjet Dashboard.

Hope this helps. If my answers satisfy you, don't hesitate to close the issue.
Gaëtan

[kaveiros]

Thank you very much for all the answers Mr Gaetan
They were very helpful.
I will implement only what is available regardless of the documentation, which needs a thorough update.
Remaining yours

[Gormador]

Hi @kaveiros,

Any reason why you reopened the issue ?

[kaveiros]

Hi, it is ok for now. I have just opened it just in case I meet new issues,
so I won' need to open it again. I have a work in progress and I might need
your help. That is all. Thank you ☺

On Tue, Jul 28, 2015 at 12:54 PM, Gaëtan Philippot <[email protected]

wrote:

Hi @kaveiros https://github.com/kaveiros,

Any reason why you reopened the issue ?

—
Reply to this email directly or view it on GitHub
#14 (comment)
.

[Gormador]

In that case, I would still prefer that you open a new issue for each different one you encounter :-)
This makes them more easy to track for us.

Closing this one, and happy coding!

[kaveiros]

Ok, we will do it the way it is easier for you. Thanks!☺

On Tue, Jul 28, 2015 at 2:48 PM, Gaëtan Philippot [email protected]
wrote:

In that case, I would still prefer that you open a new issue for each
different one you encounter :-)
This makes them more easy to track for us.

Closing this one, and happy coding!

—
Reply to this email directly or view it on GitHub
#14 (comment)
.