Skip to content

Resource types / patterns for Path Item Objects #588

Closed

Description

@ralfhandl

OData services mainly consist of "entity sets" which are collections of "entities" that are uniquely identified by their key property values within their entity set.

So a "read-only entity set" will support

  • GET on the set, with a predefined set of query options for paging ($top, $skip), filtering, sorting, free-text search, ...
  • GET on the individual entity by specifying the entity set plus the key property values

And "updatable entity sets" will in addition support

  • POST on the set to add new entities
  • PATCH and DELETE on individual entities

Basically an OData-aware client only needs the entity set name, the structure definition for each entity, and the "readonly/updatable" information to know the path templates and expected request and response bodies, allowed headers, possible response codes etc.

Spelling this out for OData-unaware clients takes a lot of highly repetitive content in the /paths section.

It would be great to have resource types or parameterized templates/patterns for Path Item objects that would allow to specify

/Products:
ReadOnlyEntitySetOfType
{ $ref: #/definitions/Product }
/People:
UpdatableEntitySetOfType
{ $ref: #/definitions/Person }

Please note that we foresee (well, actually have :-) services with dozens or hundreds of entity sets, so this would significantly reduce the size of the OpenAPI documents.

Activity

  1. webron commented on Mar 1, 2016

    @webron
    Member

    Parent issue: #560

  2. fehguy commented on Apr 11, 2016

    @fehguy
    Contributor

    @OAI/tdc removing from OpenAPI.Next proposal and making a future consideration.

  3. webron commented on Apr 12, 2016

    @webron
    Member

    Agreed.

  4. ralfhandl commented on Jan 25, 2024

    @ralfhandl
    ContributorAuthor
  5. added
    Moved to MoonwalkIssues that can be closed or migrated as being addressed in Moonwalk
    on Jan 29, 2024
  6. handrews commented on Jan 29, 2024

    @handrews
    Member

    As noted in the previous comment, the best place to continue this is in the Moonwalk repository, in the linked discussion. Closing out of this repo - @ralfhandl if you think there's something that we might consider here for 3.x please comment and I'll be happy to re-open.

  7. ralfhandl commented on Jan 29, 2024

    @ralfhandl
    ContributorAuthor

    Let's tackle it in Moonwalk first and then check whether we want to downport it to 3.x

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Moved to MoonwalkIssues that can be closed or migrated as being addressed in Moonwalk

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions