Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
I have multiple servers and I'm building an app to control them, check their status, etc. I want to create an endpoint that allows me to turn the server on/off, however, I'm not sure how to properly design the REST API.
Currently, let's say I have a Server resource and the endpoint to control it is /api/servers/{id}/start and /api/server/{id}/stop. They are used by simply sending an empty POST request which turns the server on and off.
This works fine, but I'm not sure whether it is a clean design of the API. I haven't been able to find any recommendations on this topic.
What approach would you recommend in this situation?
Thank you!
This works fine, but I'm not sure whether it is a clean design of the API. I haven't been able to find any recommendations on this topic.
It is fine, but it could probably be better.
Short version: instead of POSTing an empty message to a specialized resource, prefer to POST a detailed message to the resource you expect to change.
Long version: any time you are trying to figure what to do in REST, the right starting point is to think about how you would do it with plain old web pages.
On the web, you would open a page that has a list of different servers; each of those servers would probably have some sort of status indicator, and links for each of the changes you might want to make. Following that link would bring you to a form, which might be pre-populated with data. You would change any necessary defaults, and then submit the form, and the browser would create the HTTP request that tells the web server to restart server #7, or whatever. TADA.
Notice that neither the browser, nor human being, need to know in advance which URI to use, because that information is included in the representation of the web page. The browser needs to know how links work, and how forms work. The human being needs to know which link to follow, and how to interpret the input controls in the form, but it is the server that decides what the identifiers are, and what key/value pairs should be used in the request body, and so on.
Given that, how do you decide what the target of the form action should be? One possible answer is to consider the implications of caching. RFC 7234 says that a successful POST will invalidate any cached representations of the target-uri. So if you POST the request to the webpage that you expect to be changed by the request, then you get the appropriate caching behavior "for free".
The cache invalidation rules are not flexible - they are designed to support the common case. If you have many cached pages that will be changed by a request, then you'll need to choose which one of them is most important for updating.
Matching those ideas to your case: it's probably the case that the most important document changed by your forms is /api/servers/{id}, so that's the document that should be the target of your form submissions
POST /api/servers/1
Content-Type: text/plain
STOP
POST /api/servers/1
Content-Type: text/plain
START
Related
I want to implement a tool (a website that can edit a user's own websites) that receives uploads from the browser and stores them in a website specified in the request. However, I want to protect the user from other sites creating requests to my endpoint and doing dirty things with the user's data.
The industry standard for this is to include a randomized token in every rendering of the page, submit it together with the input data, and check the validity of the token on the server side before processing the submitted request.
Is there an automated mechanism for this in the Boomla framework, or is something like this planned?
Implemented, no. Planned, yes.
Currently (v0.9.1), I believe Boomla does check the Referer header, but it stops there. So long, maybe you could implement a cryptographic solution yourself?
How pressing is the issue for you?
Consider that currently, side effects are not possible (eg. send data), thus data leaks are not possible, it won't cause data loss, since we have built in version control. (We are going to expose a casual version control mechanism that works automatically, without commiting, so you'll be backed up even without commiting.) Thus, in effect, your users are safe.
Please disagree if you think otherwise.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
I have been doing a work in outsystems platform.
My works is a recruitment application where you add candidates to your app with a curriculum. You then choose the best ones to schedule an interview with, and eventually you can hire them to your company. Well, I don't known if you guys really need to know what my app is about, or what it does but I can explain better or eventually show it if it helps with my problem.
Well what I want is:
- When I register a candidate, I add a name, an email address, and a phone number. With this email, Outsystems offers a widget that can find all networks referred to that person (by email), that widget (I am not sure if this is the correct name for this tool, maybe API is more correct) can be found in Logic and inside the folder called Dependencies, that widget is called FullContact. To use that API you must create a new action. I did it and I filled the mandatory parameters called Email with Candidate Email. I am not sure what to put in APIKey parameter, I tried a lot of things and when I publish and test it I always have the same error called 403 Forbidden. What I am doing wrong?
I am not sure if this question is supposed to be done here, if it is not just tell me and I can delete the question and search somewhere else.
what I have is this: app print
I am not sure what to put in APIkey, I saw an example and the person that did it added an assign and an ajax refresh. Do I need it to? And this is the error I get when I test the app enter link description here
I never worked with FullContact before but from some researches I learned the following:
Overview: The FullContact Developer APIs are used to manage and enhance contact information.
Authentication: All requests to all endpoints require you to specify your unique API key. The API Key is assigned to you by FullContact and is used to identify and authorize each request. Your API key should be kept private, and should never be displayed publicly.
To signup and get your free trial: https://portal.fullcontact.com/signup
Note: FullContact isn't free, you can only apply for a trial or pay.
Pricing: https://www.fullcontact.com/developer/pricing/
Where did you get that action from? Was it from the LinkedIn Connector perhaps? If so, you might be lacking authentication. Check the documentation from available in the sample eSpace.
We have Intermec CK71 mobile devices (WiFi). There will always be a scenario in which the device sends a request (GET, PUT, or POST), then loses connection. What methods can we use to prevent duplicate PUTs or POSTs? How does the client device know whether or not the server processed its request before losing the connection?
I have seen similar posts like this but the marked answer doesn't go into much detail. I'm not even sure where to begin. Should I be looking into caching (ETag, last modified), or some type of handshaking?
The client device has the .Net Compact Framework 3.5 on it and is hitting the server via its Web API 2 endpoints.
If someone can point me to the right direction or offer any suggestions it would be much appreciated. Thanks.
I am not using REST but as far as I read the information there is no easy way to get an acknowledge and avoid duplicate POST.
As with other high level API frameworks you are tied to what the API offers and it looks like the designers did not think about connection aborts.
The easiest way to workaround this seems to use an unique ID with every post and check the server for knowing these UID before re-posting. If the server does not response with OK for an POST, you have to assume the connection has broken or other things went wrong. Then query the server for the UID you posted to know if the pervious POST was succesful before you try another POST with the same data and UID.
Possibly there is some transaction encapsulation available with REST as available for sql server. A 'transaction' protocol would ensure that a POST has been processed succesfully or will be 'rolled' back, if something failed.
Sorry, but I do not know much about REST.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
I am developing an application that needs a backend, so I choose parse because I do not have the capacity to write a truly great backend myself.
Now I want to migrate my data from parse to my own system, because parse.com is owned by facebook (privacy concerns, etc), and because it is shutting down. Does parse provide a way to efficiently do that?
EDIT
Parse announces Shutdown of Services.
Best practices and options for migrating from Parse to ? AWS, or other system, vs creating new backend based on parse.com code.
This shouldn't be difficult at all if your own backend can handle an upload of a JSON file.
Parse allows you export your data in a JSON formatted file.
All you have to do is go to the "Settings" tab in your Parse Dashboard - then click the "Export Data" tab. This will then give you a URL for you to retrieve the .zip of this JSON file.
You will then just have to import your data to your new backend.
If you move your data from Parse to another location i.e. Mongo or another PaaS provider, you will still need to update the client code. If you have a mobile app, and your end users don't bother to update their app, then how do they connect to the new datasource (DB)?
You would need to build this migrate functionality into your client from the 1st public version to be sure to capture all users, so you can flip the switch. That's a lot of work, you have to write your own wrapper for the Parse API or REST calls.
If your app is serving HTML from the server i.e. a PhoneGap app, with server side page rendering, then you are de-coupled from the app executable on the end users phone/tablet. MeteorJS has hot code push to solve this.
But trying to migrate data without having a plan in place from the get go is pretty much horrible. You could send a notification to all the old clients that need to update their mobile app, telling them to update, and shutting down the Parse backend, but that's not a great user experience. If they don't have notifications turned ON... You could code an alert/msg to popup based on you populating a field in the parse DB, poll to check it every few mins. Still not smooth.
You mobile client code would need to updated accordingly. I wrote up a part 1 of a blog on these considerations for migrating over from Parse to Couchbase Mobile stack and the reasons why.
Overall there will be some work to do as you would need to either copy over the entire datebase and then let the user to update their client app when appropriate to attach to the new backend. Getting everyone on the new system is required now as Parse is shutting down so a consideration is to create a requirement product feature with a new version number for upgrade.
We are currently working on a web client that communicates with the server using AJAX with JSON. The client is based on gwt, and communication is over https.
The communication can be easily inspected by browser tools - is there some reasonable approach to hide this from the user, i.e. securing the protocol?
Other than standard authentication and encryption techniques used by all browsers, whatever method you come up with, it must be initiated by your JavaScript client. This means that a good hacker can deconstruct your JavaScript and figure out how you submit data.
Security usually deals with either third parties trying to intercept communication or pose as legitimate users, or malicious users trying to get access to where they are not supposed to. Once you verified that a user is legitimate, why would you try to hide user's data from the user? Maybe you can describe your use case.
EDIT:
The only way to prevent bots is to ask a question that only a human can answer (e.g. Captcha) somewhere in the workflow (i.e. before submitting important data). It's usually annoying for users, but there is no other way. Since you build a gaming platform, ask your designer to come up with some fun verification.
Just to Round off Security Checklist
1) HTTPS - you have got it set up already :)
2) Json and XSS/XSRF Web Security -
https://developers.google.com/web-toolkit/articles/security_for_gwt_applications#json-xsrf
https://developers.google.com/web-toolkit/articles/security_for_gwt_applications#json
3) BOT attacks - A decent captcha - Captcha in GWT Widget
4) Miscellaneous - https://groups.google.com/forum/?fromgroups=#!topic/google-web-toolkit/_gViO5aZ-WQ