AFAIK if the REST API using the headers for version purposes, customer need
only to change the header part only when the version update.IMO If we want
we can use the custom header instead of the accept header as for the W3
protocol standards accept header used for specify the media type.(As Imesh
m
So if I am a client who is currently using the REST API of Stratos I will
have to change my client to send the version in the header as mentioned in
this thread in order to use the previous endpoints - Assuming that these
endpoints will be maintained till next release.
However, As per the discuss
Sorry, if I wasn't clear Imesh. Yes, we will support both. Accept header
can be used in a scenario where you want to explicitly mention the API
version when accessing via default API path. If you wish to use the URL
context, you shouldn't be required to set the Accept header.
On Mon, Oct 6, 2014 a
Got it! Shall we support both Accept header and URL context for this?
Thanks
On Mon, Oct 6, 2014 at 2:39 PM, Nirmal Fernando
wrote:
> Hi Imesh,
>
> Yes, GitHub API does that way https://developer.github.com/v3/versions/
>
>
> On Mon, Oct 6, 2014 at 2:35 PM, Imesh Gunaratne wrote:
>
>> +1 Regar
+1 Regarding point 2: using Accept header to specify the API version, is
this being done by any other known APIs? For my understanding Accept header
is used for specify the media type [1].
[1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html
On Sun, Oct 5, 2014 at 9:27 PM, Nirmal Fernando
Hi Imesh,
Yes, GitHub API does that way https://developer.github.com/v3/versions/
On Mon, Oct 6, 2014 at 2:35 PM, Imesh Gunaratne wrote:
> +1 Regarding point 2: using Accept header to specify the API version, is
> this being done by any other known APIs? For my understanding Accept header
> is
Although snake_case improves readability, camelCase is actively enforced
with style guidelines for Java. So it would be best to keep using camelCase
to maintain a consistent code base.
Regards,
Chamila de Alwis
Software Engineer | WSO2 | +94772207163
Blog: code.chamiladealwis.com
On Mon, Oct 6
I think it is better to use camelCase since we are using java as our
underline language
On Mon, Oct 6, 2014 at 10:05 AM, Gayan Gunarathne wrote:
> I think camelcase is better as we are using java for developed the REST
> API.I guess lot of APIs use this as they following naming conventions of
>
I think camelcase is better as we are using java for developed the REST
API.I guess lot of APIs use this as they following naming conventions of
the underlying language they are using.Also there are some arguments that
snake-case will improve the readability , it may help when documentation
and sam
Thanks guys for the pointers. I'll create Jiras for all of these.
On Mon, Oct 6, 2014 at 12:00 AM, Isuru Perera wrote:
> I also agree with all points.
>
> On Sun, Oct 5, 2014 at 11:09 PM, Akila Ravihansa Perera <
> raviha...@wso2.com> wrote:
>
>> Hi,
>>
>> +1 for all the suggested points.
>>
>>
I also agree with all points.
On Sun, Oct 5, 2014 at 11:09 PM, Akila Ravihansa Perera
wrote:
> Hi,
>
> +1 for all the suggested points.
>
> I would like to add few more to the list to be considered.
>
> 1. Provide useful error messages for back-end API exceptions.
>
> 2. Use of snake_case instea
Hi,
+1 for all the suggested points.
I would like to add few more to the list to be considered.
1. Provide useful error messages for back-end API exceptions.
2. Use of snake_case instead of camelCase in APIs. It is much more readable.
3. Support gzip compression.
4. Enable Cross-site Resource
All,
Let's discuss how we could do $subject properly. AFAIS currently we don't
have any versioning in our REST API, but we have consumers of our REST API.
1. We can make the default API version to be the latest version, i.e. v2.
So, if someone send a request to //cartridges , it would find
//v2/
13 matches
Mail list logo
