In Compojure one can define default 404 behavior, e.g.,
(defroutes app-routes
;; ...
(route/not-found "These aren't the droids you're looking for."))
As we've been increasing the number and complexity of REST endpoints, we've been looking into switching to Swagger / compojure-api. Swagger seems higher level and quite different from basic Compojure. What's the correct idiom for customizing 404 behavior using this library?
There is no definition in the Swagger Spec for the "missed everything else" default handler of Compojure. Swagger is about documenting existing apis, not the non-existing. Just discussed about this at #swagger on freenode.
Still, you can describe the default routes manually with compojure-api, created a sample here: https://gist.github.com/ikitommi/cdf19eeaf4918efb051a.
Note: Swagger spec doesn't actually understand the ANY -http method, but does seem to work with the 1.2 Swagger UI - will not work with codegens. To be standard compliant, you should add manually handlers for all http methods (https://github.com/swagger-api/swagger-spec/blob/e42dd2011340a12efbb531f593c0f99c831c4582/schemas/v1.2/operationObject.json#L10) to the end of your route definitions.
hope this helps.
Related
Ok, feeling dumb. I've been following https://auth0.com/blog/securing-kubernetes-clusters-with-istio-and-auth0/ to secure a flask app through an ingressgateway.
Basically, my AuthorizationPolicy is being seen (whitelisted routes are working, other routes are denied (enforced denied, matched policy none)) but anything that requires a jwt (key: request.auth.claims[...] or even source: requestPrincipals: ["*"]) fails.
Adding Envoy debug information, I don't see any Authorization header, which may be part of the problem; flask of course stores the access token as part of its session cookie (as in the linked article). And it seems as you'd need something like that for Istio to see it in the request; I tried setting an access_token cookie directly and using an EnvoyFilter to try and break it out into an Authorization header but that didn't seem to work either (I probably got the envoy filter wrong; new to them but I was trying an envoy.filters.http.jwt_authn filter with from_cookies; nice idea but I can't even tell if it's being called).
I'm baffled at this point. How do I store the user's jwt after the OIDC shuffle in such a way that the browser sends it back in a way that Istio is happy with? By default Istio really seems to want the Authorization header, but I'm not clear how to get it (or if that's desired). Seems like an obvious pattern but searching comes up surprisingly short, which makes me feel like I'm missing something Really Obvious.
This problem is somewhat involved. The short version is that my custom error.html is obeyed sometimes, but not others when using Embedded Jetty/RESTeasy. A small example can be found at https://github.com/pepperdog/sensus (the initial commit).
I have configured the web.xml with a custom error page:
<error-page>
<error-code>404</error-code>
<location>/util/error.html</location>
</error-page>
And this works if you hit a random URL: http://localhost:8080/XYZ
If you hit a RESTeasy URL configured in the web.xml: http://localhost:8080/ListMessages/books this works fine
If you hit a non-existent URL within the RESTeasy domain: http://localhost:8080/ListMessages/books_nonexistent
you only get the standard blank page 404, and not the custom 404. This has not been my past experience using RESTeasy inside a tomcat container, so my assumption is that it is Jetty related. Is this just the way it is, or am I missing something?
Thanks for any answers.
This is a very old question, but I came across while trying to solve the issue for myself.
If anybody is still looking, the solution is to implement RESTeasy as a Filter instead of a servlet. Per the docs: "The downside of running Resteasy as a Servlet is that you cannot have static resources like .html and .jpeg files in the same path as your JAX-RS services. Resteasy allows you to run as a Filter instead. If a JAX-RS resource is not found under the URL requested, Resteasy will delegate back to the base servlet container to resolve URLs."
I have been into web development from sometime. But recently came across an old technology, REST. I read various places about REST calls, what I have understood about REST service is,
REST service responds back with JSON or XML data, which can be used on client side for rendering the DOM elements.
It enhances the use of HTTP protocol.
The URL difference between a REST call and normal URL is:
REST CALL: wwww.xyz.com/getCart/12
URL: wwww.xyz.com/getCart.php?cartId=12
I got the basic difference, hitting the URL would render a page at the server end and would return the response, whereas making an AJAX Call to the REST service would simply return a JSON or a XML output which can be parsed at the client end.
My question is:
If I make my .php page to render a JSON string, and the application makes a AJAX call to the php page to get the JSON response back and use it on client side to render the DOM, then what is the difference between REST call and a normal URL call.?
How REST calls are configured differently from normal URLs?
There's a lot of misinformation and confusion about REST. I'm not surprised that these three points are what you understood from the information available, but they are wrong.
REST isn't coupled to any particular data format or media type. The most important constraint in REST is the emphasis on an uniform interface, which means in this case that the server should be able to respond with whatever data format or media type the clients accept. Under HTTP, the client will tell what formats it can understand through the Accept header, and the server should comply or fail with a 406 Not Acceptable error.
In the same way, REST isn't coupled to any particular protocol, although it's often convoluted with HTTP. Again, following the uniform interface, the clients should be able to follow any links provided by the server, for any protocol with a valid URI scheme.
The semantics of URLs are completely irrelevant to REST. All that matters to REST is that an URL identifies one and only one resource. The URL is an atomic identifier and the client shouldn't rely on any semantics embedded in it for any operations. The two examples you give are both valid in REST. There's nothing more or less RESTful about any of them.
To answer your question, under a REST application the difference you imagine doesn't exist. Hitting an URL will return a response. If the client is requesting with an Accept: text/html header, it may return the human-friendly html page to be rendered by a browser. If the client requests with an Accept: application/json or Accept: application/xml, it may return a machine-friendly format to be read by another application.
REST is just an architectural style, there is no technical difference.
One of the things that REST defines is that your URL needs to be atomic identifiers that refer to only one resource.
GET /users/:id (return the user with the given :id)
PUT /users/:id (update the user with the given :id)
Here is an answer about using a framework to make a REST API in php.
Rest puts more emphasis on the verbs, like GET, PUT, POST... You can call one method like
/api/Customers
and depending on the verb you use it will do a get, post, put or delete. You can also make more easy URL's like
/api/Customers/{id}/Orders/{id}
instead of making a method that would be
api/GetCustomersOrders?id=x&id=y.
All Web Services are APIs, but not all APIs are Web services.
APIs are application interfaces, meaning that one application is able to interact with another application in a standardized way.
Web services are a type of API, which must be accessed through a network connection.
REST APIs are a standardized architecture for building web APIs using HTTP methods.
I am wanting to expose a restful web service for posting and retrieving data, this may be consumed by mobile devices or a web site.
Now the actual creation of the service isn't a problem, what does seem to be a problem is communicating from a different domain.
I have made a simple example service deployed on the ASP.NET development server, which just exposes a simple POST action to send a request with JSON content. Then I have created a simple web page using jquery ajax to send some dummy data over, yet I believe I am getting stung with the same origin policy.
Is this a common thing, and how do you get around it? Some places have mentioned having a proxy on the domain that you always request a get to, but then you cannot use it in a restful manner...
So is this a common issue with a simple fix? As there seem to be plenty of restful services out there that allow 3rd parties to use their service...
How exactly are you "getting stung with the same origin policy"? From your description, I don't see how it could be relevant. If yourdomain.com/some-path/defined-request.json returns a certain JSON response, then it will return that response regardless of what is requesting the file, unless you have specifically defined required credentials that are not satisfied.
Here is an example of such a web service. It will return the same JSON object regardless of from where the request is made: http://maps.googleapis.com/maps/api/geocode/json?address=1600+Amphitheatre+Parkway,+Mountain+View,+CA&sensor=true
Unless I am misunderstanding you (in which case you should clarify your actual problem), the same origin policy doesn't really seem to apply here.
Update Re: Comment
"I make a simple HTML page and load it as file://myhtmlfilelocation/myhtmlfile.html and try to make an ajax request"
The cause of your problem is that you are using the file:// URL scheme, instead of the http:// protocol scheme. You can find information about this scheme in Section 3.10 of RFC 1738. Here is an excerpt:
The file URL scheme is used to designate files accessible on a particular host computer. This scheme, unlike most other URL schemes, does not designate a resource that is universally accessible over the Internet.
You should be able to resolve your issue by using the http:// scheme instead of the file:// scheme when you make your asynchronous HTTP request.
We have HTTP webservices that are RPC. They return XML representing the object the either retrieved or created. I want to know the advantages (if any) of "restifying" the services.
POST http://www.example.com/createDoodad
GET http://www.example.com/getDoodad?id=13
GET http://www.example.com/getWidget?id1=11&id2=45
POST http://www.example.com/createWidget
POST http://www.example.com/createSprocked
One thing I see is that we don't need representations for EVERY resource and we don't need to support all operations (GET, PUT, POST, DELETE) on all resources either.
Basically my question is this.
Convince me that I should be using restful services instead of RPC over HTTP and what would those restful services should be?
For one it's all about semantics, a URI is a Uniform Resource Indicator. HTTP provides methods to GET, POST, PUT, and DELETE a resource. HTTP headers specify in which format I want to recieve or send the information. This is all readily available through the HTTP protocol.
So you could reuse the same URL you use for HTML output to get XML, JSON in a way that HTTP was meant to be used.
XML-RPC and SOAP are based on calling methods that are described by an XSD or WSDL file whilst REST is based on getting/modifying resources. The difference is subtle but apparent. The URL solely describes the resource and not the action as is often the case with SOAP and XML-RPC.
The benefits of REST are that you can utilize HTTP verbs to modify a resource as supposed to a method call that could be named create/new/add, etc. Meaningful HTTP status codes instead of different kinds of error responses and being able to specify different formats on the same resource in a standard way.
You also don't have to accept ALL the verbs on a RESTful resource, for example if you want a read-only resource just return a 405 status code Method Not Allowed on any verb which isn't GET.
Should you redo your RPC calls to REST ? No, I don't think so. The benefits don't outweigh the development time. Should you learn REST when setting up a new Webservice ? Yes, I personally do think so, consuming a REST resource will feel a lot more natural and can grow much more rapidly.
EDIT
Why I feel REST wins over XML-RPC/SOAP is that when developing websites you already aggregate all the neccessary data for the output to HTML, you also write validating code for POST bodies. Why should you change to a different protocol just because the transport markup changes?
This way when you design a new website (language agnostic) if you really think of URI's as resources you basically use your URI's as method calls with the HTTP verb prefixing the method call.
That is, a GET on /products/12 with an HTTP header Accept: application/json; basically (imaginary) translates to getProducts(12,MimeType.Json).
This 'method' then has to do a couple of things
Check if we support JSON as a MIME type. (Validate request)
Validate request data
Aggregate data for product 12.
Format to JSON and return.
If for some reason in the next 4 years YAML is going to be the next big craze and one of your consumers wishes to talk to you in that way this MIME type is plugged in a lot easier than with regular web services.
Now product 12 is a resource you most likely also want to accept HTML MIME types on to display said product, but for a URI like /product/12/reviews/14/ you don't need an HTML counterpart, you just want your consumers to be able to post to that URL to update(PUT)/delete(DELETE) their own review.
In thinking of URIs strictly as resources, not just a location of a web page, and these resources in turn combined with the HTTP request to method invocations on the server side leads to clean (SEO friendly) URLs and (more importantly?) ease of development.
I'm sure there are frameworks in any language that will automatically do the mapping of URIs to method invocations for you. I can't recommend one since I usually roll out my own.
ASP.NET MVC also works on the same principle, but in my opinion it doesn't produce RESTful URIs. ASP.NET MVC makes the verb part of the URI by default having said that it's good to note that by no means does ASP.NET MVC force this (or anything for that matter) upon you.
If you're going to choose a framework at the very least they should:
Bind URI's to methods on the server
Support Object to JSON/XML, etc. serialization. It's a pain if you have to write this yourself although, dependent on the language, not neccessary all too difficult.
Expose some sort of type safe request helpers to help you determine what was requested without parsing the HTTP headers manually.
Try taking the verbs out of your URLs:
POST http://www.example.com/Doodad
GET http://www.example.com/Doodad/13
GET http://www.example.com/Widget/11/45
POST http://www.example.com/Widget
POST http://www.example.com/Sprocked
Query strings shouldn't be used for accessing a resource in a hierarchical, non-query manner. Query strings are usually ignored when caching, which is dangerous and slow.