OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

odata message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: [OASIS Issue Tracker] Updated: (ODATA-425) Clarify rules around parameter overloads and return types


     [ http://tools.oasis-open.org/issues/browse/ODATA-425?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ralf Handl updated ODATA-425:
-----------------------------

    Component/s: OData ABNF Construction Rules

> Clarify rules around parameter overloads and return types
> ---------------------------------------------------------
>
>                 Key: ODATA-425
>                 URL: http://tools.oasis-open.org/issues/browse/ODATA-425
>             Project: OASIS Open Data Protocol (OData) TC
>          Issue Type: Bug
>          Components: OData ABNF Construction Rules, OData CSDL, OData Protocol , OData URL Conventions 
>    Affects Versions: V4.0_CSD01
>         Environment: [Applying]
>            Reporter: Michael Pizzo
>            Assignee: Ralf Handl
>             Fix For: V4.0_CSD02
>
>
> Functions and actions today support overloads. Actions overloads must differ by binding parameter, function overloads must differ by a unique combination of parameter names.
> We don't say anything today about whether or not different overloads of the same function/action can return the same type.
> There are scenarios where it is interesting for multiple function/action overloads to return the same type (for example, a "GetByID" function or "Create" action bound to a collection of entities of a certain type). However, supporting overloads within a path makes it impossible for a simple parser to know the types of the segments; something a parser with metadata information should be able to do. As a general rule, the segments of a path should be strongly typed.
> There is a fairly simple solution to these two seemingly incongruous requirements; the scenarios in which it is interesting to vary the return type by overload are exactly the scenarios in which we have a binding parameter. And, if we have a binding parameter, and we know the type of each segment, we know the overload from parsing just the path.
> The one exception to this rule is the fact that we currently support a legacy style of passing parameters by name in the query string without defining aliases in the path. For example, we currently support:
>     ~Customers/GetById?id='ALFKI'
> This third way of binding parameters is only supported for a function/action in the final segment and its only usefulness is that a service could advertise a function/action, and the client could call it without having to parse the path and see what names were chosen for the parameters.
> The solution to this scenario is to require that advertised functions/actions utilize parameter markers named according to the parameter names defined in metadata. So, for example, if a function "GetById" takes a parameter named "Id", then the advertised form of the function, following convention, would be:
>     ~Customers/GetById(id=@id)
> and the client would call by providing the id parameter in the query string:
>     ~Customers/GetById(id=@id)?@id='ALFKI'
> This simplifies the current model by removing a third variation of parameter passing that is restricted only to a narrow usage and at the same time ensuring that the functions within a path are always strongly typed.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://tools.oasis-open.org/issues/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]