No announcement yet.


  • Filter
  • Time
  • Show
Clear All
new posts

  • SocketTools

    I need to do POST and GET to an HTTPS server where I send and receive JSON.
    Which SocketTool would be best?

    Haven't used Socket tools in a while...

    Any JSON Examples??

  • #2
    There's an example named "PostJson" in the examples folder which shows how to use the HttpPostJson function to submit a JSON payload and get back a response. A GET request doesn't involve submitting anything, so you would just use HttpGetData or HttpGetText (if you know for certain the response is always going to be textual).
    Mike Stefanik


    • #3
      Thanks Mike! I will look for that.


      • #4
        Hi Mike
        This is failing.
        What am I doing wrong here?

        hClient=FFFFFFFF after call.

        MSGBOX "Unable to initialize SocketTools library.", %MB_ICONERROR, "SocketTools"
        MSGBOX "SocketTools library was initialized.", %MB_OK, "SocketTools"
        END IF
        HTTP_ERROR = HttpGetLastError()
        LOCAL hClient AS DWORD
        LOCAL szHostName AS STRINGZ * 256
        LOCAL nHostPort AS LONG
        LOCAL nTimeout AS LONG
        LOCAL dwOptions AS DWORD
        LOCAL dwVersion AS DWORD
        szHostName = ""
        nHostPort = 80
        nTimeout = 1000
        dwOptions = %HTTP_OPTION_SECURE
        dwVersion = 0
        hClient = HttpConnect(szHostName, nHostPort, nTimeout, dwOptions, dwVersion)
        IF hClient = %INVALID_CLIENT THEN
        END IF


        • #5
          A thought for you Mike.

          It would be great if you could publish some samples for API and how to use your library to work with it. I have a bunch of friends that want to write code for crypto currency projects!


          • #6
            For example:

            API Key

            API key is recommend if you only need to access your own account. All API key requests must be signed and contain the following headers:
            • CB-ACCESS-KEY The api key as a string
            • CB-ACCESS-SIGN The user generated message signature (see below)
            • CB-ACCESS-TIMESTAMP A timestamp for your request

            All request bodies should have content type application/json and be valid JSON.

            The CB-ACCESS-SIGN header is generated by creating a sha256 HMAC using the secret key on the prehash string timestamp + method + requestPath + body (where + represents string concatenation). The timestamp value is the same as the CB-ACCESS-TIMESTAMP header.

            The body is the request body string or omitted if there is no request body (typically for GET requests).

            The method should be UPPER CASE.

            The CB-ACCESS-TIMESTAMP header MUST be number of seconds since Unix Epoch.

            Your timestamp must be within 30 seconds of the api service time or your request will be considered expired and rejected. We recommend using the time endpoint to query for the API server time if you believe there many be time skew between your server and the API servers.


            • #7
              I figured it out...
              nHostPort = 443


              • #8
                The HttpGetLastError function should give you a clue as to why something is failing. In this case, you were likely getting a security context error because you were trying to use port 80, but telling the API that you wanted a secure connection. As you've discovered, port 443 is what you need to use. In general, I'd recommend using the constants for clarity (e.g.: %HTTP_PORT_SECURE)

                One other thing I'd note is that the timeout is in seconds, not milliseconds. You probably don't want to wait about 16 minutes for a connection to complete or timeout. I'd recommend sticking with the default, which is 20 seconds.
                Mike Stefanik


                • #9
                  Thanks Mike!

                  Another question:

                  From HttpGetData

                  A pointer to a byte buffer which will contain the data transferred from the server, or a pointer to a global memory handle which will reference the data when the function returns.

                  Is this saying that if I provide a pointer to a pre-allocated buffer the data will be placed there


                  If I don't provide a pre-allocated buffer you will put the data in global memory and then give me the handle to the memory?

                  So are there two ways to get the data back from the function? I just need to pick one?


                  If I go the global memory route thin I should lock (GlobalLock) the memory to keep it safe until I am done with it?

                  LOCAL lpBuffer AS STRINGZ PTR
                  lpBuffer = GlobalLock(hgblBuffer)


                  • #10
                    I figured it out.


                    • #11
                      Yes, there are two ways you can request the data to be returned, one where the data is copied to a block of memory that you allocate, and another where the API will allocate a block of memory for you and return the handle. If you choose the approach to have the API allocate the memory for you, you should call GlobalLock on the handle, and make sure you free the handle when you're done with it.

                      The first approach is convenient if you're certain that the amount of data won't exceed a certain size. For example, typical responses which return XML or JSON data which aren't very large. You can just allocate the buffer yourself and we'll copy the response to that buffer. If you're unsure about how much data could be returned (e.g.: it could be a few thousand bytes or megabytes of data), the memory handle approach tends to be more efficient.
                      Mike Stefanik


                      • #12
                        By the way, I really recommend sending questions to [email protected] or using our support form on our website. I check in here now and again and I'm happy to answer questions, but sending questions to support helps us maintain a support history for you.
                        Mike Stefanik


                        • #13
                          Thanks Mike!