Getting the info from exact header using wget - windows

I need to get data from Apixu using PowerShell and wget command. So, I tried this variant
wget -UseBasicParsing "http://api.weatherstack.com/current?access_key=MY_KEY&query=London"
and it kinda works, but not the exact way I want it to work. The output is:
StatusCode : 200
StatusDescription : OK
Content : {"request":{"type":"City","query":"London, United
Kingdom","language":"en","unit":"m"},"location":{"name":"London","country":"United
Kingdom","region":"City of London, Greater London","lat":"51.517","...
RawContent : HTTP/1.1 200 OK
Transfer-Encoding: chunked
Connection: keep-alive
access-control-allow-methods: GET, HEAD, POST, PUT, PATCH, DELETE,...
Forms :
Headers : {[Transfer-Encoding, chunked], [Connection, keep-alive], [x-apilayer-transaction-id], [access-control-allow-methods, GET, HEAD, POST, PUT, PATCH,
DELETE, OPTIONS]...}
Images : {}
InputFields : {}
Links : {}
ParsedHtml :
RawContentLength : 722
So, is there a way to print value of "Content" header to console?

You can take the value of any single property by using ForEach-Object -MemberName:
PS ~> Invoke-WebRequest -UseBasicParsing "http://api.weatherstack.com/current?access_key=MY_KEY&query=London" |ForEach-Object -MemberName Content
{
"success": false,
"error": {
"code": 101,
"type": "invalid_access_key",
"info": "You have not supplied a valid API Access Key. [Technical Support: support#apilayer.com]"
}
}
You can also pipe the response object directly to ConvertTo-Json which will construct a custom object as described by the JSON - ConvertTo-Json will automatically figure out to parse only the Content value:
PS ~> Invoke-WebRequest -UseBasicParsing "http://api.weatherstack.com/current?access_key=MY_KEY&query=London" |ConvertTo-Json
success error
------- -----
False #{code=101; type=invalid_access_key; info=You have not supplied a valid API Access Key....

Related

Comment on a post using linkedin api returns 403 Although i have all permissions required

i am trying to comment on a post using SocailActions Api
i am using the following permissions w_organization_social r_organization_social w_member_social
and i am logged in as a an admin of the page that i am trying to comment on its behalf
my request is :
POST https://api.linkedin.com/v2/socialActions/urn%3Ali%3Ashare%3AXXXXXXXXXX/comments HTTP/1.1
Authorization: Bearer XXXXXXXXXXXXXXXXXXXXXXXXXXXX
Host: api.linkedin.com
cache-control: no-cache,
X-Restli-Protocol-Version: 2.0.0
Accept: application/json
Content-Type: application/json
Content-Length: 136
{
"actor":"urn:li:organization:23741470",
"object" :"urn:Al:share:6664163994204549120",
"message":{
"text":"tessst"
}
}
and i am getting 403
{
"serviceErrorCode": 100,
"message": "Field Value validation failed in REQUEST_BODY: Data Processing Exception while processing fields [/actor]",
"status": 403
}
the same thing happened when i tried to use the ugcPost Api to post an new comment
any ideas what might cause this ?
i was able to solve this finally, i remove all header property except the content type and content length then it worked

SpringBoot/Kotlin and Versioning through Content Negotiation: correct approach?

I have been experimenting with Content Negotiation as backend versioning for my SpringBoot/Kotlin application. I have the following:
#GetMapping("/user", produces = [MediaType.APPLICATION_JSON_VALUE])
fun getUsers() {
//some code here
}
I have found this project combining accept" header and a "Accept-Version" custom header. I wonder whether this is the correct way of implementing a content negotiation approach and if not how can I fix it?
#GetMapping("/user", produces = [MediaType.APPLICATION_JSON_VALUE], headers = ["Accept-Version=$CUSTOM_ACCEPT_HEADER"])
fun getUsers() {
//some code here
}
object VersioningUtility {
const val CUSTOM_ACCEPT_HEADER = "vnd.sample.com-v1+json"
//here more constants as each controller can be versioned independently
}
Thank you
Yes, you can implement API versioning using content negotiation by having a custom header and header value as you have specified. However, since that is not a standard header, there are other scenarios which you might have to handle by yourself, such as:
default representation when the header is not present
exception scenarios when invalid media type values are passed as part of the header.
In case you are working with only json responses, the JSON API standard for content negotiation is to send the Accept header with the value application/vnd.api+json. Since Accept is a standard request header, using that is preferred. In case you need to handle other types of responses, you can still go ahead with the custom header.
You can implement content negotiation as below:
#RestController
class UserController {
#GetMapping("/users", headers = ["Accept=${VersioningUtility.VERSION_1_HEADER}"])
fun getUser(): ResponseEntity<Any> {
return ResponseEntity(listOf(User("Abraham Lincoln")), HttpStatus.OK)
}
#GetMapping("/users", headers = ["Accept=${VersioningUtility.VERSION_2_HEADER}"])
fun getNewUser(): ResponseEntity<Any> {
return ResponseEntity(listOf(NewUser(Name("Abraham", "Lincoln"))), HttpStatus.OK)
}
}
data class User(val name: String)
data class NewUser(val name: Name)
data class Name(val firstName: String, val lastName: String)
object VersioningUtility {
const val VERSION_1_HEADER = "application/vnd.v1+json"
const val VERSION_2_HEADER = "application/vnd.v2+json"
}
The above with enable you to have 2 versions of the GET /users endpoint with the Accept header.
When the curl request is made with v1 of the header value, the response would be according to the version v1
curl -L -X GET 'http://localhost:8080/users' \
-H 'Accept: application/vnd.v1+json'
[
{
"name": "Abraham Lincoln"
}
]
When the curl request is made with v2 of the header value, the response would be according to the version v2
curl -L -X GET 'http://localhost:8080/users' \
-H 'Accept: application/vnd.v2+json'
[
{
"name": {
"firstName": "Abraham",
"lastName": "Lincoln"
}
}
]
When an invalid header value is sent, it would respond with a 406 Not Acceptable
curl -L -X GET 'http://localhost:8080/users' \
-H 'Accept: application/vnd.abc+json'
{
"timestamp": "2020-04-01T18:33:16.393+0000",
"status": 406,
"error": "Not Acceptable",
"message": "Could not find acceptable representation",
"path": "/users"
}
When no Accept header is sent, it would respond with the default version, ie v1 here
curl -L -X GET 'http://localhost:8080/users'
[
{
"name": "Abraham Lincoln"
}
]
Even GitHub has implemented versioning with content negotiation in a similar way and you can have a look at that in their documentation.

ES query from a golang server to ES returning error while the postman request directly to ES returns the expected results

This is the request body that I for this endpoint using Postman localhost:9201/response_v2_862875ee3a88a6d09c95bdbda029ce2b/_search
{
"_source": ["_id"],
"from": 1,
"size": 10,
: {
"should": {
"match": {
}
}, {
"range": {
"_updated_at": {
"from": "36163",
"include_lower": true,
"include_upper": true,
"to": null
}
}
}]
}
}
}
To this url localhost:9201/rensedbda029ce2b/_search
And I get the results https://gist.gith
But when I make the same request from my server to ES I get an error saying "elastic: Error 400 (Bad Request): Expected [START_OBJECT] but found [START_ARRAY] [type=parsing_exception]"
These are some snippets of my code. I get the query from another util function and use that while making the call to ES.
This is the call to ES res, err = r.esConn.Search(indexName).e(requestBody.ResponsePageLength).Do(ctx)
and the query builder function is this, it takes arguments which are extracted from the body of the request to my server and builds a query based on that.
func CreateMonitoringPipeline(maxResponseTime string, responseQueries []ResponseQuery, baselineFormId string) *elastic.BoolQuery {
finalQuery := elastic.NewBoolQuery()
dateRangeMatchQuery := elastic.NewRangeQuery("_updated_at").
Gte(maxResponseTime)
finalQuery.Filter(dateRangeMatchQuery)
}
return finalQuery
}
I can't figure out why is this happening? my ES is running using the ES binary and my server runs in a docker container.
Completely new to ES and golang so please help.
UPDATE:
This is what I got when I logged my request using SetTraceLog
| ELASTICPOST /resp8ecf8427e/_search HTTP/1.1
| Host: 172.17.0.1:9201
| User-Agent: elastic/5.0.81 (linux-amd64)
| Transfer-Encoding: chunked
| Accept: application/json
| Content-Type: application/json
| Accept-Encoding: gzip
|
| 7
| ["_id"]
| 0
I can't understand what do the 7 and ["_id"] mean. Is this my request body that ES received?
Thanks for uploading the logs, you are right that the ["_id"] is the request being sent. The problem is in the request line as Source([]string{"_id"}) does not set the source field to ["_id"] as you intended but instead:
Source allows the user to set the request body manually without using
any of the structs and interfaces in Elastic.
https://godoc.org/github.com/olivere/elastic#SearchService.Source
You want to use FetchSourceContext instead:
res, err = r.esConn.Search(indexName).From(requestBody.MaxResponseTimestampCount).FetchSourceContext(elastic.NewFetchSourceContect(true). Include("_id")).Query(query).Size(requestBody.ResponsePageLength).Do(ctx)
https://godoc.org/github.com/olivere/elastic#SearchService.FetchSourceContext

Elastic Search is not working

When I am giving request to Elastic search my post and put is not working
My request
POST bird/admin/1
{
"id":"1",
"ity":"BSP"
}
It should give success
But, getting error
{
"error": "Content-Type header [application/x-www-form-urlencoded; charset=UTF-8] is not supported",
"status": 406
}
You should use application/json content type.
If you are using curl, add -H 'Content-Type: application/json'
https://www.elastic.co/blog/strict-content-type-checking-for-elasticsearch-rest-requests

How to validate response with dredd?

I'm trying to check my api implementation with my documentation written in blueprint. I've expected that dredd will fail when json returned from server will be different than specified in documentation. To check this I've copied dredd-example. First I've run dredd with original apib file to make sure that all is green. Then I've modified response in documentation and expected dredd to show me some red... But it doesn't.... it looks like tool is only checking response headers but not the response body. Here is output from console:
pass: GET /machines duration: 18ms
request:
host: localhost
port: 3000
path: /machines
method: GET
headers:
User-Agent: Dredd/0.2.1 (Darwin 13.0.0; x64)
expected:
headers:
Content-Type: application/json
body:
[
{
"_id": "52341870ed55224b15ff07ef",
"type": "bulldozer",
"name": "willyxxxxxx" #HERE IS WHERE I CHANGED RESPONSE IN DOCUMENTATION
}
]
status: 200
actual:
headers:
x-powered-by: Express
content-type: application/json
content-length: 95
date: Thu, 20 Mar 2014 08:22:40 GMT
connection: keep-alive
body:
[
{
"_id": "532aa5507dcdfff362931799",
"type": "bulldozer",
"name": "willy"
}
]
status: 200
Can I check response body using dredd? And how can I do this?
In JSON bodies Dredd is checking only for keys not for values. When you change key in the expected JSON body document, it will definitely fails.

Resources