I have an HTTP JSON endpoint localhost:8000/resource/ that takes JSON data as input and returns JSON as output. I am now adding API Key based authorization to the endpoint. There are 2 ways to accept the API Key at this endpoint:
Method A: In the request headers
Example python code:
import requests
headers = {
'API-Key': '<my-api-key>',
}
r = requests.post('http://localhost:8000/resource/',
json={'input': <value>},
headers=headers)
Method B: In the JSON data itself
Example python code:
import requests
r = requests.post('http://localhost:8000/resource/',
json={'input': <value>, 'API-Key': '<my-api-key>'},)
I usually notice Method A being adopted. Is there anything wrong with latter approach in which the API key is passed along with the other json data?
I think it has to do with clarity, the API Key isn't really relevant to the input, it's just a form of authorization.
Large frameworks that deal with routing and such are able to filter based on specific headers, and it would be cumbersome to filter based off of a specific form of input in the request body that would require user to intervene and obtain that value for it. Headers are simpler, and suffice for simple data that would fit in a hash-table.
Related
I'm trying to make get requested with .Q.hg (HTTP get), but I need to edit the request headers to provide API keys. How can I do this?
You can try this function I wrote a few years back for a POC (similar reason - I needed to supply multiple headers). It's based on .Q.hmb which underpins .Q.hp/hg. Please note - it was never extensively tested & there are likely better alternatives out there, but it will perhaps work as a quick solution.
k)req:{[url;method;hd;bd]d:s,s:"\r\n";url:$[10=#url;url;1_$url];p:{$[#y;y;x]}/getenv`$_:\("HTTP";"NO"),\:"_PROXY";u:.Q.hap#url;t:~(~#*p)||/(*":"\:u 2)like/:{(("."=*x)#"*"),x}'","\:p 1;a:$[t;p:.Q.hap#*p;u]1;(4+*r ss d)_r:(`$":",,/($[t;p;u]0 2))($method)," ",$[t;url;u 3]," HTTP/1.1",s,(s/:("Connection: close";"Host: ",u 2),((0<#a)#,$[t;"Proxy-";""],"Authorization: Basic ",.Q.btoa a),($[#hd;(!hd),'": ",/:. hd;()])),($[#bd;(s,"Content-length: ",$#bd),d,bd;d])}
It takes 4 arguments:
Resource URL
HTTP method
Dictionary of headers
Message body as JSON object
Sending a request to a test server..
q).j.k req["https://httpbin.org/get";`GET;("Content-Type";"someOtherHeader")!(.h.ty`json;"blah");""] // no body so pass empty string
args | (`symbol$())!()
headers| `Content-Type`Host`Someotherheader`X-Amzn-Trace-Id!("application/jso..
url | "https://httpbin.org/get"
Note - I am very much new to all this. Apologies if anything is unclear.
My overriding aim is to pull out MOT history data for a large batch of vehicles from the DVLA API. I understand that this can be done using Postman, which I am using (on a 64-bit Windows laptop if at all relevant).
The DVLA provide the following instructions
====================================================
Getting started
All API interfaces are implemented as restful APIs and accessed over https.
To access API you will need an API key that uniquely identifies the source of the request. DVSA will give you an API key if it approves your application.
You should keep your API key secure, as DVSA manages throttling and quotas at an API key level.
Each request must have the following mandatory fields in the header:
Accept: application/json+v6
x-api-key:
Content-type field confirms that the response type is in JSON format, and the x-api-key field serves your API key to identify the source of the request.
Technical resources
Access the API at https://beta.check-mot.service.gov.uk/
This root URL will change when the service moves from beta to live.
These 4 endpoints equate to the 4 methods of using the API:
/trade/vehicles/mot-tests?registration={registration}
‘Registration’ is the vehicle registration number.
===================================================
In order to test that this is possible, I am entering the following single request into the bar in Postman, selecting "POST" and hitting "SEND"
https://beta.check-mot.service.gov.uk/trade/vehicles/mot-tests?Content-type=application/json&x-api-key=ABCDEFGH®istration=MYREG
n.b. no inverted commas or other punctuation surrounds the actual values for ABCDEFH or MYREG
Expected result: Some sort of JSON with MOT history for this vehicle
Actual result: {"message": "Missing Authentication Token"}{"message": "Missing Authentication Token"}
I am unclear on:
- whether I should be using POST
what the +v6 after the application is necessary (other documentation leaves it out)
Why "Accept" and "Content-type" appear to be used interchangeably in the documentation
Whether the ordering of the parameters matters
Whether this can be equally tested by simply pasting the url into a browser
Thanks for any help
Reading through the Documentation found here:
https://dvsa.github.io/mot-history-api-documentation/
It mentions that those fields should be added as Headers:
Each request must have the following mandatory fields in
the header:
- Accept: application/json+v6
- x-api-key: <your api key>
There are example cURL requests on the site to help you with creating the request.
If you use Postman's Import feature within the app (found in the top right), you can add this cURL request in the Paste Raw Text tab.
curl -H "Accept: application/json+v6" -H "x-api-key: <your_api_key>" https://beta.check-mot.service.gov.uk/trade/vehicles/mot-tests\?registration=ZZ99ABC
This will give you an example request of what it should look like. From here, you will be able to add in your own API Token and send the request.
If you are using Postman, you can use the Authorization tab right under the request to give the required mandatory header fields. Select Header from Add to drop down. You can also add additional headers information using the next tab named Headers. (for example, the accept-headers).
Edit:
Authorization:
Headers Tab
Normally, you should be getting the authorization token when you register to the site in question(x-api-key here).You need to figure out the value of that token from the initial call's response headers. According to the document which Danny shared, you will be getting x-api-key from them once they approve your request.
Edit:
Alternatively, you can use import feature as Danny suggested in his answer. At the end of the day, you need to add the values as headers instead of query parameters.
For anyone using Python with the MOT history api and getting the same error message, try GET:
import requests
url = f'https://beta.check-mot.service.gov.uk/trade/vehicles/mot-tests?registration={plate_number}'
payload = {}
headers = {
'Accept': 'application/json+v6',
'x-api-key': 'your-api-key'}
response = requests.get(url, headers=headers, data=payload)
data = response.json()
model = data[0]['model'] # get the vehicle model for example
print(model)
I am a newbie to the apigility code-connected service & was able to create a RESTful service with fetch and fetchall class method on the mapper file.
Can someone point me a good sample for insert (POST) data via REST service ?
Thank you,
Kevin
POST is going to be used for creating a new resource typically. This means that in your request you're going to want the following headers:
Accept: application/json
Content-Type: application/json
The first tells Apigility what sort of a response it is expecting. The second says that the data you'll be providing to the API will be in json format.
Apigility uses json or json+hal by default for a return and expects json for the incoming data.
When you're creating a new resource, typically you'll be persisting it in a database and as such the id of the resource will be generated by your code or database. The rest of the resource will be provided by the caller to the API. Example:
POST /api/user
{
"username": "kevin voyce",
"firstname": "kevin",
"lastname":" "voyce"
}
If you do this, you should see a response of something like
405 - Method Not Allowed
The body of the error should indicate that the method has not been defined. The error message is coming from the create method in the resource. Inside this method, you'll see an argument called $data which at this point will consist of a PHP stdClass with fields matching the stuff you passed in via the JSON body.
This is where the fields part of configuring your API in Apigility comes in. If you set up the names of the fields and put validators on the fields, Apigility will make sure that the fields that are passed in conform to and are valid according to these validators before the call is made into your API. The same applies to not just POST, but PATCH and PUT as well. This means that within your methods you don't have to worry that the input hasn't been validated (as long as you correctly configured your validators).
I want the user to have the opportunity to choose the format in which it receives a response from the server, whether it is plain text, json or xml. It's looks like I must to retrieve media_type by calling cowboy_req:meta/{2,3} and then use it for encoding a response body. But that value doesn't available in callbacks before content_types_provided (malformed_request, is_authorized, forbidden...).
Should I dublicate a cowboy logic and write my own code to determine media_type?
Or ignore all callbacks which had executed before the media_type has been determined.
Or maybe should I to place my response message into request metadata and encode it in the onresponse hook, then replace response body?
How should I do that?
I think you are not quite wright. Straight from init/3 and rest_init/3 functions the Request parameter is "full request", and you can read any header or meta in each callback.
And personally i would go with Header over Meta (since there is already Content-Type header defined, and Headers should take presence over Meta).
In general the REST callbacks in cowboy should only give you easily understandable workflow for handling request, with additional default response codes. In is_authorized/2 all you need to do is check authorization, simply return true or false (as part of tuple), and cowboy will either move forward with you logic or return 401 code. Checking is someone allowed to make request should not be determined on response format, but still, if you would like to do it, just read this Meta from Req parameter, and return true/false based on it.
And the only difference with content_types_provided/2 is that you return kind of bindings between Content-Types header values and your functions. I think all you need could be based on this official example
i am creating a rest api in which there is a need for transferring the apikey and a signature in the http headers. Now i can supply the required parameters inside the http header and a controller reads it out nicely but i was wondering if there is a better way of doing this.
We transfer the values of the apikey and sha1 signature in the HTTP Authorization header and retrieve this by using.
request.getHeader("AUTHORIZATION").split(',').
inject([:]) { map, token ->
token.split('=').with {
map[it[0]] = it[1]
}
map
}
The result is a map which contains the key/value pairs
Is there a better way of doing this?