You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In the merged PR feat(CustomParams): Added support for custom query parameters #92 from Mar 29, 2020, the custom query options were added to the HttpParams after operations such as select, filter, etc. Not sure about anyone else, but our endpoints (in the event that they require custom parameters but also support select/filter/expand operations) require the custom query options to come first in the request, s.a:
In the merged PR feat(CustomParams): Added support for custom query parameters #92 from Mar 29, 2020, the custom query options were added to the HttpParams after operations such as select, filter, etc. Not sure about anyone else, but our endpoints (in the event that they require custom parameters but also support select/filter/expand operations) require the custom query options to come first in the request, s.a:
http://localhost:61868/route/v1/Reports?effectiveDate=2018-06-30&$select=effectiveDate,startedDate&$filter=startedDate
As opposed to:
http://localhost:61868/route/v1/Reports?$select=effectiveDate,startedDate&$filter=startedDate&effectiveDate=2018-06-30
in which the custom param effectiveDate=2018-06030 will not be properly recognized at the end of the query string.
Can we reorder this and enforce it as the first parameter in the request? Thanks
The text was updated successfully, but these errors were encountered: