I'm in the process of developing a system which is heavily dependent on a web service which is designed according to REST principles. The connection is over HTTPS, and my issue is finding a good way to identify clients. There are several users from several different companies with several different access levels.
The backend/middleware is written in PHP, and up until now, I have used the $_SESSION to identify users.
After reading more about REST services, I learned that REST services should be stateless and every call should provide all information necessary to handle that call. I interpreted this in the direction that the server should not maintain any states related to specific clients.
Questions:
Does this mean that using $_SESSION[some_identifier] to preserve state between calls is not aligning with the REST style?
I'm now considering using a "short-lived token" logic instead. This token is exchanged with the server on each request, and the server provides a new token in the reply of each request. Is this approach more RESTful?
You should be using the Authorization HTTP header, used by various HTTP authentication systems such as Basic, OAuth2, or your own proprietary extensions.
Related
For single page application, so many websites are using (Or wish to use) api for their application and generally api domain is set some differenet from current one.
for ex: if domain name is "domain.com"
then api domain name is "api.domain.com".
so for fetching data we call the api from the "domain.com", then it connect to "api.domain.com", then "api.domain.com" creates a DB connection and returns responses.
I think is will be fast if we just do it on "domain.com"., because first we established a connection with "api" then api communicate to Database.
So i want to understand why are using api is better way in order to performance of a web application.
Thanks
Splitting them across two hostnames allows them to be split across two computers. This can help with scaling.
It allows different web servers to be used (e.g. you might have a server optimised for serving up static file to serving up a SPA while the API that provides its data is written using Node.js or Servlets).
It allows cookies to be limited to one of the two systems (e.g. so the cookie that identifies a user to the API isn't sent in every request to load an image from the static server).
It limits the points where the two codebases have to touch, making it easier to develop them independently. (e.g. by two different teams or with consideration for the API to be used by a client other than the SPA).
This helps in proper code managemment.
By creating an API, it can be used from a portal front-end, mobile devices and various services.
I also think it's easier to create services in the same domain for single page applications. However, if the project gets bigger, it is easier to handle things with an API.
I'm having troubles to figure out how web services handle requests and send responses, and how my site/module will handle it. So these are my questions and bellow a little about why i am asking this:
What is the right way to send a request to web service?
How a web-service will usually answer a site requesting?
How a PHP site can send a request to a web-service? Is cURL the right way?
I'm a student who are learning PHP and a lot of other things, and my job now is create a Joomla Module to show information from a web service (probably created in java or something, probably created by me, when i learn java...).
I know i will use http requests to talk with the web service, but i worry im using it wrong (making a request to the url, like the browser).
So, i did a little example site and a example API. The api uses Slim microframework to create routes, access my database and return the content in json (what means: if i access 'api.com/api/something' in my browser i see a plain white page with a lot of json). I pretend this is my web service.
The example site send a request to the API with cURL, reads the content and decode the json and do things. It seems forced to me.
I have not much support to understand web services and if i am in the right way (or far from this).
I would appreciate your help.
You are on the right track. A web service is simply a processing or storage facility intended to be accessed by some other program just like a database or fileserver service.
What is the right way to send a request to a web service
It depends. The most common implementations use SOAP or REST which define additional semantics on top of the HTTP protocol. SOAP uses a single URL as a gateway to the service and more specific selection of the functionality and the relevant data is embedded within an XML payload presented via POST. HTTP is merely a bearer for the message exchange. In REST, the HTTP part is integrated into the semantics of the transaction.
The URL identifies the location of the data (or processing function)
The payload contains only data, usually presented as POSTed JSON or XML,
further REST uses the HTTP verb (GET, POST, PUT, DELETE) to indicate the requested action
the HTTP headers are used to convey transaction meta-data.
How a web service will usually answer a request
I'm not sure what you are asking here. It should report back on the state of the request, any relevant error messages and possibly some data.
The speciifics would be unique to the API and documented.
Is cURL the right way?
While it is possible to do a lot with the HTTP wrappers functionality in PHP, libcurl offers an lot more flexibility. So, yes this it would be hard to implement a REST client without using cURL, OTOH a SOAP client is (usually) less complex at the HTTP tier but life is a lot simpler if you use a SOAP library/framework to abstract the more complex protocol.
For future questions please have one question per entry.
What is the right way to send a request to web service?
That really depends on the web service, what they require. It can be as simple as a short text string, to sending a XML formatted or JSON formatted array. You need to research the relevant web service.
How a web-service will usually answer a site requesting?
Again it depends on the web service. They are not the same. A web service will have documentation on what it expects and how it will respond.
How a PHP site can send a request to a web-service? Is cURL the right way?
Curl is a good method and is usually the method used from within PHP.
I'm creating a simple web service in PHP to serve data to some of our internal applications.
My question is around authentication/security, the implementation of the actual web service isn't a problem.
For security, I'm planning on providing each application that will be consuming the service with a unique, periodically static authentication code that they use when call into the service. The service code then checks an internal list to see if the authentication code being used is a valid one, and provides access to the data if it is.
E.g.
xxx.xxx.com/ws.php?op=getproductnameslist&authcode=329cj32x21xdd332
The service is being served over HTTPS, so transmission of the actual data should be encrypted.
I'd like some comments on the above in terms security concerns, and if there is a better way to do this.
Securing a WebService is not as simple as passing a get parameter through the URL. Get parameters are logged on HTTP server logs and easily copy/pasted and manipulated.
WebService security is not a simple problem, try to use well know solutions, I would go with OAuth. PHP has a good implementation here http://php.net/manual/es/book.oauth.php
You can also check this post about Web Services security http://www.stormpath.com/blog/secure-your-rest-api-right-way
I'm developing a social networking website. This service will be available across various mediums, for example: the web, iPhone, Facebook application etc.
My idea for this application was to have all of these properties interact with one central point for fetching and saving data: an API. My various applications would then interact with this API, sending a GET request to fetch some data; a POST request to submit some data; DELETE requests and so on.
This API will be web-accessible, so I need a way to authenticate only white-listed applications. This API will never be available for third parties to interact with or build third-party applications with; it's to facilitate my applications only so I can cut out re-coding solutions across various platforms and focus only on the logic (controllers, essentially).
Therefore, would OAuth be suitable to be used as the authentication method for the above scenario?
My knowledge of OAuth isn't great, but if it is deemed a viable solution then I'll obviously read up on it before implementing. But as far as I know it works on tokens. A consumer (for example, my website) would request a token from the application (the API in this instance) and then the application would return a token to use in subsequent requests. Or something.
When a request comes in to my application, am I then able to accept/deny requests based on the requesting application? I.e. can I deny access to applications that aren't my own? How do I differentiate between applications? Do I retain a whitelist of IP address or URLs, and compare upon incoming requests?
Any help on the above would be most appreciated.
OAuth is not designed to authenticate some applications the way you want to.
Juste create your own private way to authenticate, because you're the only one to know about your API. Dont forget to pipe the authentication in SSL and everything will be ok !
I don't think OAuth is the best solution for your problem. OAuth is great when you plan to give your API to the 3rd parties as it allows to authenticate user without giving users's credentials to the 3rd party. If you have all control over the API there is no need for this.
It's still a good idea to read about it thou. :)
I'm working on developing a native android application to retrieve data for a user from my company's website.
Because the data is specific to the user, I need to authenticate with our web server, but I'm unsure of the best way to go about this. I've been reading about REST/SOAP/HTML form auth, but I can't really find any definite 'this is how its done' anywhere. I know mobile apps do this kind of thing all the time - just look at facebook/skype/any email app - you have to login before you can do anything.
My question is - how should I architect the server side code (php) to easily allow me to authenticate a user from my android device?
I'm fairly new to the 'web service' arena - does this fall into that category? Are there any tutorials you guys would recommend looking at?
Thanks!
While I haven't developed for Android, I can suggest that you simply rely on some stateless authentication scheme, such as HTTP Basic or Digest. This means that the credentials will be passed with each and every request, and you avoid having to keep track of state, which means you can keep your API nice and RESTful.
I suspect if I were writing an android app, in most cases, I'd probably first try to get communication working with something at-least-vaguely RESTful, using HTTP Basic auth, and JSON encoding (just because PHP makes (de)serializing JSON so easy).
Of course, depending on your problem domain, that might not be ideal, but it's a good architecture to try first, because it's pretty easy all-around. If it fails you, you can go back and start swapping parts out, until you find the right architecture.
Some mobile apps use OAuth to authenticate with a web server, such as twitter has. This may not be exactly what you're looking for, but none-the-less here's an example: You would log in to web service and authenticate the mobile app (which would have requested access) to be able to utilize your data on web service, like an access key (actually called a token) with which the mobile app then utilizes to communicate with the web service on your behalf; the token could be then passed as part of the url. You'll still likely want to consider SSL or some level of encryption.
This post may also be of help for you