On 08/28/2016 01:49 AM, Joseph Magen wrote:

On Fri, Aug 26, 2016 at 10:47 AM, Dominic Cleal <domi...@cleal.org <mailto:domi...@cleal.org>> wrote:

    On 26/08/16 06:58, Joseph Magen wrote:
    > I created a RFC for a plugin called foreman_api_v3
    >
    <https://github.com/isratrade/rfcs/blob/master/0000-foreman-api-v3.md
    <https://github.com/isratrade/rfcs/blob/master/0000-foreman-api-v3.md>>
    and
    > the initial repo atgithub.com/isratrade/foreman_api_v3
    <http://github.com/isratrade/foreman_api_v3>
    > <https://github.com/isratrade/foreman_api_v3
    <https://github.com/isratrade/foreman_api_v3>>. If the community
    accepts,
    > I am happy to move this repo to theforeman/foreman_api_v3
    >
    > I choose to make this a plugin rather than a PR so it is
    optional for
    > users and doesn't affect the core code.

    Please consider calling it something else that won't cause
    confusion for
    users with Foreman's own API versioning.


I can rename the plugin to *foreman_jsonapi* and change to version to v21 (meaning v2.1 since it inherits from v2), so it would look like this

GET api/api/v21/hosts

what happens when we get to version 21 of the api which in my calculations will occur around 2325? :)


What do you think?


    --
    Dominic Cleal
    domi...@cleal.org <mailto:domi...@cleal.org>



On Fri, Aug 26, 2016 at 11:36 PM, Tomas Strachota <tstrach...@redhat.com <mailto:tstrach...@redhat.com>> wrote:

    On 08/26/2016 07:58 AM, Joseph Magen wrote:

        Hi all,

        I created a RFC for a plugin called foreman_api_v3
        <https://github.com/isratrade/rfcs/blob/master/0000-foreman-api-v3.md
        <https://github.com/isratrade/rfcs/blob/master/0000-foreman-api-v3.md>>
        and
        the initial repo at github.com/isratrade/foreman_api_v3
        <http://github.com/isratrade/foreman_api_v3>
        <https://github.com/isratrade/foreman_api_v3
        <https://github.com/isratrade/foreman_api_v3>>. If the
        community accepts,
        I am happy to move this repo to theforeman/foreman_api_v3

        I choose to make this a plugin rather than a PR so it is
        optional for
        users and doesn't affect the core code. The initial repo only
        includes
        the GET `index` and `show` actions. The PUT/PATCH/POST/DELETE
        actions
        need to be added. Also, there are currently no functional
        tests in the
        repo, so a lot more work needs to be done.

        Note that I inherited V2 so that V3 controllers look like this

        module Api
          module V3
            class DomainsController < V2::DomainsController

        but the response is changed.

              def index
                super
                render json: @domains,
                       fields: @fields_hash,
                       include: @include_array,
                       each_serializer: DomainSerializer
              end

        For some background, the Foreman API v2 is more than 3 years
        old. When I
        implemented v2, I used conventions that I thought were good at
        the time.
        The katello had some slightly different conventions, and we
        weren't
        always in sync. This created some challenges for Satellite6 as
        a single
        RH product.

        The goal of JSON API is to create a standardization that is
        *Flexible,
        Consistent, and Fast *-- we can all agree with these goals.


    Thanks for sending that, Joseph. Jsonapi.org is nice specification
    and I like how it structures the data. The ability to include
    additional resources into the response is very handy and making
    the katello and foreman api consistent would be good too. But that
    alone wouldn't be enough to make switch to jsonapi. In my opinion
    main painpoints of the current api v2 are elsewhere. Firstly I
    miss adding associated resources without having to send all what's
    currently included. Second main issue is inconsistent error
    responses (we've improved with that but it's still not ideal).
    Jsonapi.org has cures for both [1] [2], so I'm not against at all
    that but we mustn't stop just at changing the output format.


Please explain the other pain points in v2 besides [1] [2]

    Speaking about the format change, since getting consistent with
    katello is one of motivations for the change, I'd like to hear
    from somebody with expertise in that field how difficult would be
to bend the UI code to use the new format.
    Just to make sure we actually won't unintentionally put more
    obstacles in katello's way.


I assume you mean using RABL to generate the new output format when keeping the same v2 controllers. IMHO, this would be a bigger headache for both Koreman and Katello. This would still lead to v3 since there are breaking changes. Maybe I don't understand your question fully.

    If we decide that jsonapi is the way to go for v3 I think it would
    be better to implement it as part of the foreman core. We can
    clearly mark it as devel preview with no guarantees, let it evolve
    alongside with v2 and freeze when we're happy with it.


I don't see the advantage of implementing a new api as part of core until if/when it is stable and has community adoption.


    [1] http://jsonapi.org/format/#crud-updating-relationships
    <http://jsonapi.org/format/#crud-updating-relationships>
    [2] http://jsonapi.org/format/#errors
    <http://jsonapi.org/format/#errors>

        Here's some more links that could be helpful in addition
        to http://jsonapi.org/

        
http://blog.arkency.com/2016/02/how-and-why-should-you-use-json-api-in-your-rails-api/
        
<http://blog.arkency.com/2016/02/how-and-why-should-you-use-json-api-in-your-rails-api/>

        *JSON API <http://jsonapi.org/> is a great solution to not
        waste hours
        on reinventing the wheel in terms of your API responses
        design.* It is a
        great, extensible response standard which can save your time -
        both on
        the backend side and the client side. Your clients can
        leverage you’re
        using an established standard to implement an integration with
        your API
        in a cleaner and faster way.

        *Building a Rails API with the JSON API Spec
        
*http://www.slideshare.net/SonjaPeterson2/building-a-rails-api-with-the-json-api-spec
        
<http://www.slideshare.net/SonjaPeterson2/building-a-rails-api-with-the-json-api-spec>

        I look forward to hearing you feedback and receiving
        contributions to
        the repo.

        Joseph Magen (@isratrade)
        Red Hat



--
You received this message because you are subscribed to the Google Groups "foreman-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to foreman-dev+unsubscr...@googlegroups.com <mailto:foreman-dev+unsubscr...@googlegroups.com>.
For more options, visit https://groups.google.com/d/optout.


--
You received this message because you are subscribed to the Google Groups 
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to foreman-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to