REST Web API URL to update a resource property - asp.net-web-api

To update the resource i have exposed following reset web api url -
http://server.com/api/v1/{companyid}/resources/{resourceid}
and request body contains the resource to be updated.
I have also exposed a seperate API to update a property of same resource. From business rule perspective this is special property and cannot be updated/retrieved along with normal resource api.
So using following url to expose separate api as below -
http://server.com/api/v1/{companyid}/resources/{resourceid}/property?propertyKey=propertyValue
this does not sound good. Is there better approach?

Answer from the comments for others
PUT api/v1/{companyid}/resources/{resourceid}/{property} with the Body containing the value of the property is one way.
PUT api/v1/{companyid}/resources/{resourceid}/{property}/{propertyvalue} is another way if you want the value entirely in the URL.
Of course, http://server.com/api/v1/{companyid}/resources/{resourceid}/property?propertyKey=propertyValue is also probably fine.
As #David-Brabant mentioned don't version your API's in the URL

Related

AWS APIGW - Access static HTTP Headers for Integration Request in Mapping Template for Lambda

I am trying to modify an API GW config similar to what is found here https://oozio.medium.com/serverless-discord-bot-55f95f26f743
What I need to do is pass to lambda a custom static HTTP Header. I have defined in APIGW -> /{resource} -> Integration Request -> HTTP Headers: a header like {"Name": "application", "Mapped from": "'discord'", "Caching": false} (with single ticks as noted in the documentation for a static value)
This header never appears in the list of headers from the mapping template. I've spent the better part of a day trying to solve this.
Simplified question:
How do you access a static HTTP Header defined in Integration Request, in the Mapping Template?
TIA
After working with AWS support, this is apparently not possible.
Many Thanks for your kind patience. After our call I started to look for a possible
solution to fetch the statically set HTTP header in the mapping template, but
unfortunately could not find any solution.
I then discussed this scenario with my colleagues and also reached out to the
back-end API Gateway Service Team. It seems that this is something that is not
possible currently.
We cannot access the static header value defined in the integration request, in
the request body mapping template. If your use case needs to send the static header
in body for non proxy integration then it is recommended that you may define it
statically in the body mapping template directly.
I understand as you explained to me how you need to access the header in the mapping
template but unfortunately this does not seem to have a solution. Although the
statically set header is seen to be passed in the API Gateway logs, there is no
mechanism in the lambda service to fetch these headers.
Currently, I can ask the Service Team to consider the same as a feature request but
I wont be having a ETA available and also would need a solid reasoning since the
same can be done in the mapping template.
The workaround at this time (March 2021) has to be expressing it directly in the mapping template itself, or using Proxy for Lambda.
The following was provided as justification for the feature request.
When creating APIGW via a templating process (Such as terraform), being able to
express 'API Wide' variables is a useful tool for sending contextual information
to a backend integration. For example, a Lambda that can process requests from
multiple sources, but it needs to know which source should be used. While the
value can be statically expressed in the mapping template, having it be a
variable as part of the API allows for better visibility and management as its
an interact-able component, where as the mapping template is effectively a
complex string. This also does not need to be a header, it could simply be
"integration variables" that allow you to define simple k:v pairs that are either
passed as part of context, or accessible in $context within the mapping template.
While statically expressing it in the mapping template is a workaround, it is
only that.

Handle different URL patterns in Zuul filters

I have two types of URL patterns as below.
/gateway/secure/api/user/getUser
/gateway/nonsecure/api/user/getUser
(Context root of zuul gateway application is gateway)
Using zuul filters I'm trying to implement two different logics based on secure and nonsecure URL patterns. I've written a pre-filter and seems it's not even executing that filter for above URL patterns. I could see gateway is throwing 404. When I try to access microservice without secure or nonsecure its working as expected. Below are the property changes I've done so far.
Context root of downstream microservice is api/user
zuul.prefix=/secure
zuul.routes.user.path=/api/user/**
zuul.routes.user.service-id=user
zuul.prefix=/nonsecure
zuul.routes.user.path=/api/user/**
zuul.routes.user.service-id=user
I've already tried by giving zuul.prefix and it seems prefix is setting as globally and cant apply only for specific routes. How can I achieve this? Can anyone please advice.Thanks
As you noted, the zuul.prefix property affects all mappings and can only be defined once. So, drop the zuul.prefix property and add the corresponding prefix to each zuul.routes.*.path properties:
zuul.routes.user.path=/secure/api/user/**
zuul.routes.user.service-id=user
zuul.routes.user.path=/nonsecure/api/user/**
zuul.routes.user.service-id=user
Note that, according to the documentation:
zuul.stripPrefix only applies to the prefix set in zuul.prefix. It does not have any effect on prefixes defined within a given route’s path.

How to change scope/permissions with Microsoft.Web.WebPages.OAuth

Is there a way to change the scope/permission when using Microsoft.Web.WebPages.OAuth? The most logical place is when registering the client with OAuthWebSecurity.RegisterClient. I thought that the adding scope to the extraData parameter would possibly work, but I didn't have success with that.
Microsoft.Web.WebPages.OAuth does not expose the scope when authorizing with a client. I ended up adding custom DotNetOpenAuth clients to include my necessary scope.
The extradata is something you can pass about the provider and use it in tehe UI layer. For eg. extra data could be the icon to display when listing the provider to use for login.
Following post shows how you can write your own provider and plug it into your site
http://blogs.msdn.com/b/webdev/archive/2012/08/23/plugging-custom-oauth-openid-providers.aspx

ASP.NET MVC 3: Purpose of IgnoreRoute("{resource}.axd/{*pathInfo}"); ? deprecated?

Do I even need this rule anymore?
I don't see any requests incoming for resource.axd files (as opposed to when I ran webform applications)
WebResource.axd is an HTTP Handler that is part of the .NET Framework
that does one thing and one thing only – it is tasked with getting an
embedded resource out of a DLL and returning its content. What DLL to
go to and what embedded resource to take are specified through the
querystring. For instance, a request to
www.yoursite.com/WebResource.axd?d=EqSMS…&t=63421… might return a
particular snippet of JavaScript embedded in a particular assembly.
Its still part of the framework and you can still retrieve embedded resources using the above handler. You dont want your route handler to handle such requests and that is why it is ignored. My guess is that you can get rid of it if you are completely sure that your app/libraries that you use dont use it.

Access request parameters from a JSP View in Spring Web MVC without putting them in a model

I'd like to be able to access some HTTP GET parameters directly in a JSP, without having to pass them through a Controller+Model, but at the same time still use the dispatcher/controller/model/view mechanism for other parameters and logic.
This is because I have many HTTP GET parameters that are generated by Javascript and used also only in Javascript. My Controllers don't need them at all.
I tried ${arg}, ${request.arg}, ${requestScope.arg}, nothing seems to work.
If I bypass the dispatcher, ${requestScope.arg} works.
But is there a way to make it work with the dispatcher?
Thanks!
If that's request parameters that you want to access (and not request attributes like the title says), then the syntax is ${param.parameterName}.
If it's request attributes, then it's ${requestScope.attributeName}.
See http://java.sun.com/products/jsp/syntax/2.0/syntaxref207.html#1010522 for a quick reference.

Resources