I am having trouble retrieving isochrones for public transport using the HERE Maps API.
Specifically, we are using the public transport API with isochrone search feature as described here:
https://developer.here.com/rest-apis/documentation/transit/topics/resource-isochrone-search.html
When we make a request, and use the key allocated to us, we get a 403 permissions error.
If we use the API Explorer/Playground (https://developer.here.com/api-explorer/rest/public_transit/isochrone-search) with the default/demo keys (already in place), then we get a 200 OK response. If we insert our own keys, the request appears to time out/not provide a response.
Any ideas on what we may be doing wrong?
Edit: Using a HERE Maps trial (90 day) account to test functionality.
For using Public Transport API, you need some special agreement with data supplier even for evaluation. Use the Contact us link to request additional permission.
https://developer.here.com/contact-us
https://developer.here.com/rest-apis/documentation/transit/topics/coverage-information.html
Related
I am migrating my code to the GS7 API and when making reverse geocoding requests I get place type results (resultType=place) that prevent me from getting the closest address or street names to the coordinate. Therefore, I need to avoid or filter place type results in the request (resultType=place), to get the same response as with the previous API.
I am making the request in each API with similar parameters and I get different results. What I want to achieve is to get the street address closest to the coordinate in the GS7 API request. I leave you the requests with both API's as an example to help me understand what I'm doing wrong or what I should do.
GS7 Reverse Geocode
request: https://revgeocode.search.hereapi.com/v1/revgeocode?apiKey=[apikey]&in=circle:20.57732,-103.36033;r=100
response: 'Grupo Cipsa, Anillo Periférico Sur, Toluquilla, 45610 Tlaquepaque, Jal, México'
API HERE Reverse Geocoding:
request: https://reverse.geocoder.ls.hereapi.com/6.2/reversegeocode.xml?apiKey=[apiKey]&gen=8&prox=20.57732,-103.36033,100&mode=retrieveAddresses
response: 'Anillo Periférico Sur 6258, Toluquilla, 45610 Tlaquepaque, JAL, México'
I really appreciate your help.
I can currently issue the following request: https://api.coinbase.com/v2/prices/spot?currency=USD and receive a json response with the current (spot) price of BitCoin (BTC).
What I want is to retrieve that information for Ether (ETH). I note that the HTTP request that I am using does not specify BTC, it just defaults to that.
I have reviewed the Coinbase API without success in locating an answer.
I was just wondering if anyone is aware of an HTTP request to obtain that data, or if this request is not currently supported via HTTP.
tia
The Coinbase API docs, https://developers.coinbase.com/api/v2#get-spot-price shows the following URI structure for getting the spot price for Bitcoin (BTC) or Ethereum (ETH), which is different from what you have posted.
https://api.coinbase.com/v2/prices/:currency_pair/spot
The part of the url indicated as :currency_pair is a string containing
the symbol for the coin, a hyphen and then 'USD', such as BTC-USD or ETH-USD.
I am able to get BTC and ETH spot prices from the api with the following:
https://api.coinbase.com/v2/prices/BTC-USD/spot
https://api.coinbase.com/v2/prices/ETH-USD/spot
Status code 400 Bad Request is used when the client has sent a request that cannot be processed due to being malformed.
Status code 404 Not Found is used when the requested resource does not exist / cannot be found.
My question is, when a client sends a request to an endpoint my API does not serve, which of these status codes is more appropriate?
Should an endpoint be considered a "resource", and thus a 404 be returned? My issue with this is that if the client only checks the status code, they cannot tell the difference between a 404 indicating that they got to the correct endpoint, but there was no result matching their query, versus a 404 indicating that they queried a non-existing endpoint.
Alternatively, should we expect that a client has prior knowledge of all available API endpoints, and thus treat their request as malformed and return a 400 if the endpoint they are trying to reach does not exist?
Maybe this depends on whether the endpoints are REST or not. If they are REST endpoints, the client should not need prior API knowledge, but be able to learn about all relevant API endpoints by navigating the API from a single root endpoint. In such a case, I guess 404 would be more appropriate.
In my specific case right now, this is an internal (non-REST) HTTP API, where I expect the client to have prior knowledge of all API endpoints, so I am leaning towards 400, to avoid issues where 404 from accessing the wrong endpoint could be misconstrued as a 404 indicating that what they sought from the correct endpoint could not be found.
Thoughts?
As a convenience, many modern APIs provide human-readable endpoints for developer convenience. The intent of REST, however, is that URLs are treated as opaque - they may happen to contain semantic content, but can't be relied upon to do so. There's no such thing as a "malformed" URL. There's only a URL that points to something and a URL that doesn't.
Now, that's the REST dogma (and arguably also the HTTP 1.1 spec). That doesn't mean it's what you should do. If you have a single internal client for your API, and that's not going to change, you have a lot of flexibility in designing your own standards. Just make sure to document them, especially those that might confuse the guy straight out of college that they hire to replace you when you move on.
I have to write sign on peoplecode to make a service call by passing token (sent from third party) to API and get the responce (if token is valid responce will have username) in json format to create a PS_TOKEN.
I am fresher to peoplecode. How can I run HTTP POST request by passing token and get the response using Peoplecode?
You would create a synchronous service operation in the Integration Broker. The Integration Broker works best if you are sending XML or JSON. If this is just a regular HTTP POST with fields then it can cause some issues with the Integration Broker. I had a similar case and could not get the basic HTTP Post to work but instead ended up using HTTP POST multipart/form-data and was able to get that to work.
Steps I had to do to make this work.
Create a Message (document based or rowset based are both possible)
Create Service Operation and related objects
Create Transform App Engine to convert the Message to a HTTP POST multipart/form-data
Create a routing and modify the connector properties to send the content type of multipart/form-data. Also call the Transform app engine as part of the routing.
The issue with a application/x-www-form-urlencoded POST is that it seems PeopleSoft does another url encoding after the Transform, which is the last time you can touch the output with code. This final url encoding was encoding the = sign in the form post which made the format invalid.
Your other option would be to write this is Java and call the Java class from within PeopleSoft (or mix the Java objects in with PeopleCode). If you choose to go this way then the App Server needs to have connectivity to your authentication server. My only experience with this is I had a client that used this approach and had issues under heavy load. It was never determined the cause of the performance issue, they switched to LDAP instead to resolve the issue.
My users enter a few information fields in an iOS app.
This information must be validated on my server, which has a RESTful API.
After validation the UI of the iOS app changes to indicate the result.
Neither GET, PUT, or POST seem to be appropriate, because I'm not getting a resource, and neither is a resource created or updated.
What is the best fitting REST operation to implement this validation?
I use the same scenario as you and use PUT for it. You have to ask yourself: "when I send the same request twice, does this make a different state on server?" If yes, use POST, if no use PUT.
My users enter a few information fields in a iOS app. This information
must be validated on my server, which has a RESTful API. After
validation the UI of the iOS app changes to indicate the result....I'm
not getting a resource, and neither is a resource created or updated.
Since you aren't saving anything (not modifying any resource), I'd think this is technically more RPC than RESTful to me.
The following is my opinion, so don't take it as gospel:
If the information is simply being submitted and you're saying yes or no, and you're not saving it, I'd say POST is fine..
If information were actually being saved / updated, then choosing the proper HTTP method would be a lot more relevant.
POST = CREATE / SUBMIT (in an RPC context)
PUT = UPDATE (or CREATE if there is nothing to UPDATE)
I recommend using a ValidationResource and two requests. Each instance of this resource represents the validation of a set of data. The workflow:
1. Create new ValidationResource
Request: POST /path/to/validations
data to validate as the body
Response: 201 Created
Location: /path/to/validations/<unique-id-of-this-validation>
2. Look up result
Request: GET /path/to/validations/<unique-id-of-this-validation>
Respons: 200 OK
body: {'valid': true} or {'valid': false}
This is a RESTful approach in which the Validation is a Resource with server state.
Google proposes use of Custom Methods for REST API
For custom methods, they should use the following generic HTTP
mapping:
https://service.name/v1/some/resource/name:customVerb
The reason to use : instead of / to separate the custom verb from the
resource name is to support arbitrary paths. For example, undelete a
file can map to POST /files/a/long/file/name:undelete
Source: https://cloud.google.com/apis/design/custom_methods
So for validation the URL should be POST /resource:validate
I believe it is similar to GET entity but since we need to send data to validate and sending confidential data in URL is wrong habit as only payload data is ciphered by TLS, the only way left is POST or PUT.
However you may save or update the data in validate(eg. "verified":false). Based on requirement, you can go for POST or PUT (recommended POST if no update)
POST /user/validate-something
It seems like you're not doing it the correct way, if the validation is at the server-side then it should happen while submitting the data using a POST method. Then you'll validate that data, if validation fails then you can raise a 400 BAD REQUEST error, else you can create the resource.
This approach is more RESTful, as the POST method is properly used to create a resource or to raise 400 if validation fails