I’m trying to test MARKET order with Spot Test Network in Postman. But I receive empty JSON as response.
Why? Do MARKET orders work on Spot Test Network as of July 2020? Was my order executed? How can I check on Spot Test Network if a MARKET order was executed?
My order params:
symbol: BTCUSDT
side: BUY
type: MARKET
quantity: 0.1
timestamp: {{timestamp}}
signature: {{signature}}
But the response is just an empty JOSN:
{}
Why?
What do I do wrong?
How to fix?
cURL code for your convenience. Just replace {TIMESTAMP}, (SIGNATURE} and {YOUR_API_KEY} with your real ones:
curl --location --request POST 'https://testnet.binance.vision/api/v3/order/test?symbol=BTCUSDT&side=BUY&type=MARKET&quantity=0.1×tamp={TIMESTAMP}&signature={SIGNATURE}' \
--header 'Content-Type: application/json' \
--header 'X-MBX-APIKEY: {YOUR_API_KEY}'
I've figured out what was the problem.
Change
POST https://testnet.binance.vision/api/v3/order/test
to
POST https://testnet.binance.vision/api/v3/order
The endpoint ending /test is for testing, which means the backend will check all parameters and return empty json if it passed all validations. Otherwise 400 will be returned along with with error messages.
Related
Problem :
Entity id decorated #PrimaryGeneratedColumn() is overwritable on put request.
Expected behaviour :
The id decorated with #PrimaryGeneratedColumn() shall not update.
Steps to reproduce :
Create an entry with this post request :
curl --location --request POST 'https://q6zre.sse.codesandbox.io/tests' \
--header 'Content-Type: application/json' \
--data-raw '{"name": "acme"}'
Copy the id from the response, add it in the put request url, and add a random wishedId in the body :
curl --location --request PUT 'https://q6zre.sse.codesandbox.io/tests/{id}' \
--header 'Content-Type: application/json' \
--data-raw '{"id": "{wishedId}"}'
The entry is updated with the wishedId.
Working example : https://codesandbox.io/s/github/desirelabs/nest-typeorm
Is there any way to prevent this ?
Thanks
I would say this is less of a TypeORM problem and more of an architecture problem. You should consider adding an Anti-corruption Layer or DDD: Anti-corruption Layer, etc. to your architecture. The pattern comes from Domain Driven Design, and the basic idea is that your REST layer should not be directly influenced by your Database layer, and there should be mapping going on in between the two to help enforce business requirements. You are using TypeORM to do that mapping, and I'm suggesting you should write your own mapping to defend your data integrity from the outside world.
I'm trying to do something very simple: add api key authorization header in a post request.
What I tried so far:
add it under headers key in requestOptions
add it when creating the client under authorization key
this is where the search space begins to expand: which key do I add? the security type apiKey? Whatever key I gave it in my spec? The actual header name? (none of those worked, btw)
Unfortunately, I could not find any helpful info in documentation (actually I could not find any documentation other than the README and the FAQ pages which do not provide disambiguation in this matter).
So, any practical example and/or point to un/official docs that show how to work with this thing would be greatly appreciated.
So, from digging around in swagger-js code, "Whatever key I gave it in my spec" is the way to go. Meaning, if your security schemes look like this:
components:
securitySchemes:
ymlSpecAuthKeyName: # <-- also swagger-js key
type: apiKey
name: X-Auth-Header-Name
in: header
and you want your request to look like this:
curl -X POST "http://your-api-url.com/doc-you-want-to-create" \
-H "X-Auth-Header-Name: api-key-header-value" \
-H "Content-Type: application/json" \
-d "{\"json-request-body\": \"goes-here\"}"
Then you should make a swagger-js client like this:
let client = await Swagger({
spec: spec,
authorizations: {
ymlSpecAuthKeyName: 'api-key-header-value',
}
});
Using GitLab API it is possible to post a comment to a commit "on a particular line of a particular file" (see here).
On Merge Request in order to add comments it's required to use the notes resource (see here) but the note object does not seem to contain any parameter to comment on a particular line.
However from the GitLab UI I'm able to add inline comments to a Merge Request in the Changes tab but when I call the API and look at the corresponding note object created from my inline comment there is nothing about the inline, it is only a regular note object without any line or line_type parameter...
Anyone knows how to use the GitLab API to add inline comments to a Merge Request ?
In order to add inline comments for merge requests, there is Discussions API: https://docs.gitlab.com/ce/api/discussions.html
Each discussion can contain a position in the code, like that:
"position": {
"base_sha": "b5d6e7b1613fca24d250fa8e5bc7bcc3dd6002ef",
"start_sha": "7c9c2ead8a320fb7ba0b4e234bd9529a2614e306",
"head_sha": "4803c71e6b1833ca72b8b26ef2ecd5adc8a38031",
"old_path": "package.json",
"new_path": "package.json",
"position_type": "text",
"old_line": 27,
"new_line": 27
},
The notes API is used to only add comments to the Merge Request.
In order to add inline comments to the source code, you must use this other API endpoint:
https://docs.gitlab.com/ce/api/commits.html#post-comment-to-commit
But this API sets the comment in the commit list. You will not see the comment anywhere in the "Merge Request" page.
Code
functions.yml
.commit_comment:
script:
- export GITLAB_TOKEN="PROJECT_ACCESS_TOKEN"
- |
commit_comment() {
curl --location --request POST "https://gitlab.com/api/v4/projects/$CI_MERGE_REQUEST_PROJECT_ID/merge_requests/$CI_MERGE_REQUEST_IID/notes" --header "PRIVATE-TOKEN: $GITLAB_TOKEN" --header "Content-Type: application/json" --data-raw "{ \"body\": \"$1\" }"
}
How to Use?
# ...
script:
- !reference [.commit_comment, script]
- commit_comment "YOUR_MESSAGE"
# ...
ℹ️ Markdown is allowed for the message
Generating Token
Go to Your Project > Settings > Access Tokens
Enter a Token name
Choose Reporter as role
Select the api scope. You can add more scopes but this is all we need here
Generate the token
P.s. Here, I have created a function to use with multiple jobs but you also directly use the curl command anywhere directly by replacing $1 with your message.
Ref
I am using the python gitlab module and this is the format to add an inline comment. Please note that adding comments will fail If the line is not modified.
import gitlab
gl = gitlab.Gitlab(ci_server_url, oauth_token)
merge_request = gl.projects.get(project_id).mergerequests.get(merge_request_iid)
position = {
"base_sha": merge_request.diff_refs["base_sha"],
"head_sha": merge_request.diff_refs["head_sha"],
"start_sha": merge_request.diff_refs["start_sha"],
"new_path": "1.py",
"new_line": 18,
'position_type': 'text'
}
disc = merge_request.discussions.create({"body": "This is a comment on line 18", "position": position})
I am trying to use a curl command to tag a commit. Is this possible? I went through the create-a-tag-object link from GitHub, but it doesn't work.
Creating a tag is a bit complicated, but if you just follow the API docs you should be fine. Note that the API docs say:
Note that creating a tag object does not create the reference that makes a tag in Git. If you want to create an annotated tag in Git, you have to do this call to create the tag object, and then create the refs/tags/[tag] reference. If you want to create a lightweight tag, you simply have to create the reference - this call would be unnecessary.
So, before you continue with creating a tag, you should know what kind of tag you want to create -- annotated or lightweight. Basically, an annotated tag is the same as a lightweight, but it also contains a message of the tag, info about the author of the tag, and the date and time when the tag was created. A lightweight tag is just a named pointer to a specific commit in your history.
Ok, so, what the API docs basically say is: if you want to create an annotated tag - you will have to make 2 API calls, and if you want to create a lightweight tag - you will have to make just 1 call. So, I'll give an example of creating an annotated tag with the 2 API calls, and if you want to create a lightweight tag - just skip the first API call and go to the second.
To create an annotated tag, you have to:
Step 1
Create a tag object using the tags API. The API docs are a bit unclear here how the parameters should be passed. What's missing is an example of the message that you need to send to the server. So, create a file called tag_object_req.json on your local disk, and put the following JSON document in it:
{
"tag": "v0.0.1",
"object": "c5f8759ffd808d4a57ea36c63960f3e2cc6fcc2b",
"message": "creating a tag",
"tagger": {
"name": "Ivan Zuzak",
"email": "izuzak#gmail.com",
"date": "2012-06-17T14:53:35-07:00"
},
"type": "commit"
}
Obviously, you have to replace the information in the document to reflect your situation. The meaning of the parameters are described in the API docs here.
After you have saved the file, you can make an API call using curl to create the tag object:
curl -v -X POST -d #tag_object_req.json --header "Content-Type:application/json" -u izuzak "https://api.github.com/repos/izuzak/test/git/tags"
So, the -v part will force curl to output all HTTP headers, the -X POST part means that an HTTP POST request must be made, -d #tag_object_req.json specifies which file will be used as the content (body) of the POST request, --header "Content-Type:application/json" specifies the media type of the request (JSON message), and -u izuzak specifies your username for authorization (and curl will ask you for your password when you make the request).
The response you get should be a 201 Created HTTP response, with the JSON message structured as this:
{
"sha": "e6d9fb6b9a13cab11923345e2400d5cf8df97267",
"url": "https://api.github.com/repos/izuzak/test/git/tags/e6d9fb6b9a13cab11923345e2400d5cf8df97267",
"tagger": {
"name": "Ivan Zuzak",
"email": "izuzak#gmail.com",
"date": "2012-06-17T21:53:35Z"
},
"object": {
"sha": "c5f8759ffd808d4a57ea36c63960f3e2cc6fcc2b",
"type": "commit",
"url": "https://api.github.com/repos/izuzak/test/git/commits/c5f8759ffd808d4a57ea36c63960f3e2cc6fcc2b"
},
"tag": "v0.0.1",
"message": "creating a tag"
}
Before continuing, notice the sha attribute of the object you just created (e6d9fb6b9a13cab11923345e2400d5cf8df97267) because you will use this value in the next step.
Step 2
Create a tag reference using the references API. The API docs are much clearer here about what the request should look like. So, you first have to create another file on the disk, named tag_ref_req.json, and put this content inside:
{
"ref": "refs/tags/v0.0.1",
"sha": "e6d9fb6b9a13cab11923345e2400d5cf8df97267"
}
However, notice that the value of the sha in this JSON depends on the type of tag you are creating. If you are creating an annotated tag, the value of the sha is the same value you got from the previous step - the sha of the tag object (e6d9fb6b9a13cab11923345e2400d5cf8df97267). However, if you are creating a lightweight tag, the value of the sha is the sha of the commit object you are tagging with the tag, because you have not created a tag object. In my case, you can see in step 1 that the commit object I am tagging is c5f8759ffd808d4a57ea36c63960f3e2cc6fcc2b, and this will be different in your case of course if you are creating a lightweight tag.
Ok, so after you have created this file and defined the sha and the name of the tag, you can make an API request in a similar way as in the previous step, using curl:
curl -v -X POST -d #tag_ref_req.json --header "Content-Type:application/json" -u izuzak "https://api.github.com/repos/izuzak/test/git/refs"
Notice that we are now making a request to https://api.github.com/repos/izuzak/test/git/refs with the second file as the content.
The response should again be a 201 Created HTTP response, and the body will be a JSON document looking like this:
{
"ref": "refs/tags/v0.0.1",
"url": "https://api.github.com/repos/izuzak/test/git/refs/tags/v0.0.1",
"object": {
"sha": "e6d9fb6b9a13cab11923345e2400d5cf8df97267",
"type": "tag",
"url": "https://api.github.com/repos/izuzak/test/git/tags/e6d9fb6b9a13cab11923345e2400d5cf8df97267"
}
}
And now you can navigate to your project on GitHub and go to "Switch branches/tags" and see your tag there.
Hope this helps!
You can also try the new Releases API
http://developer.github.com/v3/repos/releases/#create-a-release
curl \
--user <username> \
--header "Accept: application/vnd.github.manifold-preview" \
--data "tag_name=mytagname" \
"https://api.github.com/repos/<username>/<repository>/releases"
This is curl will create Releases. (But as ChucK mentioned it may create only lightweight tag, I haven't personally verified this )
curl \
--user <Your Github username> \
--header "Accept: application/vnd.github.manifold-preview" \
--data '{"tag_name": "v1.0.0", "target_commitish": "master", "name": "v1.0.0", "body": "Description of the release", "draft": false, "prerelease": false }' \
"https://api.github.com/repos/<OrganizationName>/<RepoName>/releases" -X POST
Adding this here, incase anybody come looking for this, like me.
I'd like to write a unit test for my app that simulates a conflict during replication. Is there a way to simulate a conflict using only a single CouchDB database and server?
I assume you want to get a document containing a conflict in your database, rather than a 409 Conflict response?
So, create a document in the database with a known _id:
$ curl http://localhost:5984/scratch/foo -X PUT -H "Content-Type: application/json" -d '{}'
{"ok":true,"id":"foo","rev":"1-967a00dff5e02add41819138abb3284d"}
Then use the bulk docs API with the all_or_nothing: true option to update the same document with a deliberately bad or no _rev, adding some different document attributes for good measure:
$ curl http://localhost:5984/scratch/_bulk_docs -X POST -H "Content-Type: application/json" -d '{"all_or_nothing": true, "docs": [{"_id": "foo", "abc": 123}]}'
[{"id":"foo","rev":"1-15c813a2b4b312c6915821b01a1986c5"}]
You should then have a conflict in the document:
$ curl http://localhost:5984/scratch/foo?conflicts=true
{"_id":"foo","_rev":"1-967a00dff5e02add41819138abb3284d","_conflicts":["1-15c813a2b4b312c6915821b01a1986c5"]}
You can also perform a normal query with ?new_edits=false as described by CouchDB committer Randall Leeds.
$ curl http://localhost:5984/scratch?new_edits=false -X POST -H "Content-Type: application/json" -d '{"_id": "foo", "abc": 123}'
Googled further after asking the question, and it looks like the answer is to use the all-or-nothing mode of the bulk document API.
http://wiki.apache.org/couchdb/HTTP_Bulk_Document_API
Look near the end of the page.
Just post two documents with the same _id attribute. This creates a conflict since the 2nd doc will not contain the proper _rev attribute. Remember, you need to include the latest _rev attribute in each subsequent post so that CouchDB knows you are up to date.
Also, you can create two databases on the same server and replicate between those.