New answers tagged api
0
I would try expanding the source by hosting the api on free web hosting, making the users wait is probably a bad idea.
If you make 5 different hosts and forward the users randomly to each, you won't have a problem here.
2
I'd suggest to a static constant string to both be able to map to i18n and keep expressiveness.
Something like this is nice:
{
error: 'invalid_id'
}
And you can even scope it to module to locate the origin of the error and avoid overlapping:
{
error: 'auth.invalid_id'
}
Or, you could also add the http response code inside the object, but that's ...
1
Nobody has brought this up but numbers are usually better for i18n. The client can decide what text to display. In many cases the client will have to translate the text depending on the locale, so in most cases this is easily done on the client as there are mechanisms to handle internationalization.
@Bellon's answer also sends the text as well for ...
1
Additional information from process angle:
Communicate with all stakeholders: Provide to other teams and API consumers a clear and concise communication about the reason to deprecate the API, the strategy, the plan and schedule details, versioning meaning, and alternatives, set the HTTP accordingly.
Plan and Schedule: On the plan you should have the key ...
5
I would go with text. It's OK to have a string where you only use numbers. As a rule of thumb: you should not use integers for things that are not mathematical in nature. That is, if you can do addition or multiplication on the values in a sensible way, then it's a number. Otherwise it's an identifier and you should stick with text. In practice you will ...
0
If you want to send integers, send them as integers. If you have an error code “abcde” then send strings. If “12” and “0012” are different error codes then send strings. But if you the receiver wants integers, send integers.
2
Do you need to do math on it? if errorCode>9000 etc
Do you need to pass it into anything that expects an integer?
Do you want an early error if you accidentally type an x in the code value?
If you answered no to all of these I can't see a reason why not to use strings.
As for your comment about 0012 vs 12, that's a presentation issue. The backend shouldn'...
0
{
"code": 9900,
"message": "Invalid ID"
}
Should be the most appropriate. The standard for numbers requires not to have quotes.
https://www.json.org/
http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-404.pdf
Personally, I'd suggest to follow a pattern for code values similar to the one used by HTTP, so grouping categories of ...
1
I don't know which database you're using, but is it possible to define stored procedures in different schemas (essentially namespaces) and give them access to the underlying data through synonyms? At least that's what I would try with Oracle.
If that's not possible, you could implement poor man's namespaces using prefixes, so doSomething() becomes ...
4
Stored procedures don't support versioning. You will need to make a version of your database with two sprocs with the version in the name
mySproc_v1()
mySproc_v2()
Your API can support versioning in a number of different ways. so you can have two versions of the api deployed pointing to the same database
www.example.com/api/v1.0/endpoint - calls ...
3
You have, broadly speaking, two choices:
Make the stored procedure backward compatible,
Add a second, v2, stored procedure to the database and leave the original unchanged.
The first approach can be harder to implement. You may need default values or parameters and complex logic in the stored procedure to handle both the old and new behaviours. Such a ...
0
I have worked with public API's in only one small project, but I recently learned that if one were to distribute a project with API keys inside this is a security risk.
Seriously speaking I want to congrats you for already know this so earlier in your career, because believe you or not, a lot of senior developers are still misinformed or unaware of the ...
1
The idea of a message bus is to run things asynchronously. Message exchange is not supposed to take place while a client is waiting for your response. It should happen in the background, so for example if your ProductService needs some data about users, it should listen to events from UserService about user changes, and apply them to its own local copy of ...
0
Versioning your sdks. You need a versioning strategy in place to avoid disruption/downtime.
Here's a good lead on how ING managed their versioning, there's a youtube presentation of this talk as well.
https://www.slideshare.net/PatriceKrakow/api-versioning-for-zero-downtime-devoxx-belgium-2017
2
It's hard to get around the fact that if two programs talk to each other they have to agree on the message format.
Not every change to and API requires a client change though. I normally separate out publishing the MicroService from publishing its client library.
That way if you fix a bug and have interface changes in a version, you can update the server ...
0
When creating and debugging a webservice, it certainly helps to have proper logging to see if there are any issues. If there is an issue, you can easily find out the parameters passed to reproduce it.
For a production environment, you can get swarmed by log so logging just the errors/exceptions there makes sense.
A good logging framework allows you to ...
0
Best practice is to log whatever you need. You should know your application well enough to know what information is required to troubleshoot issues. If you don't, then spend more time thinking about it.
1
What is the goal of your logging? Logging request, response, and user info is perfectly valid if your goal is to build a profile of your users. Google certainly does.
If all you want to do is debug your service it's a bit much. Your focus should be on errors not recording how things went when it worked.
My 11th grade English teacher has the best advice for ...
0
In my experience this is too much logging.
You should log errors and performance, which might be the path, response code, response time and count of http requests in the case of a REST api, but not query string parameters, request/response bodies etc.
Storing all that data has a cost and if your application is working you should never have occasion to look ...
0
You are correct that passing sensitive information in URIs is a bad practice from a security perspective. The upshot is that doing so makes it more likely that the information will be exposed e.g. in web logs.
Doing the latter, however, would leave the endpoint as URL/tokens only which could imply deleting all the tokens.
There's some merit to this but ...
0
I think its low risk. The main worry I would have is that maybe they will be calling it all the time instead of keeping their token.
But there are a couple of worries.
Do you now have to keep a db of access tokens? That ia a new attack vector
What about token expiry? do you refresh the expiry date or send an indentical token?
What about refresh tokens? arr ...
6
Think about it this way, most people are not in the habit of distributing keys to their private property (house, cars, etc.). Why? Because those keys protect critical assets, and prevent people you don't know from stealing things. You can think of the API key as the API password. Anything your application is authorized to do with the API, someone else ...
7
There are different kinds of API keys. Some API keys are designed to be made public, they're usually called something like publishable keys, and are designed to be sent out to users in web pages or application bundles. This type of API keys aren't intended for authentication, but rather simple identification. There are few use cases where this is reasonable, ...
11
It depends on what the API key does. However, if the API key is giving you access to something or controlling your access to something, why would you want other people to piggyback on the resources that you have access to? You wouldn't.
Think about it this way. I own a service and you are a user of it, perhaps even a paying customer. I give you an API key ...
2
There is no match between a user—that is a physical person—and an IP address. The same person may have its IP address change on regular basis, even when using a PC. Similarly, multiple users may share the same IP address (for instance multiple persons working in the same company).
Operating system can be spoofed. So does the MAC address, which is relatively ...
Top 50 recent answers are included
