PxPlus User Forum

Twitter Twitter Twitter

Author Topic: Custom content for http error responses  (Read 3306 times)

Jeff Wilder

  • Silver Member
  • ***
  • Posts: 42
    • View Profile
Custom content for http error responses
« on: March 09, 2019, 02:18:01 PM »
I have a REST web service running under the PxPlus Web Server 15.10.0001. I would like to have custom content when the service responds with an HTTP error code. No matter what I try, the web server responds with the following standard HTML message after setting %Exit_Code=400.
Code: [Select]
<html>
    <head>
        <title>400 Bad Request</title>
    </head>
    <body>
        <h1>400 Bad Request</h1>
        <hr>
        <p>The Requested URL is not properly formed.
            <br>
Method: GET  URI:/restapi.pvp  ARGS:
        </p>
    </body>
</html>

How can i override this behavior to force a response with my own content? I tried adding a record to the *web\websrv.tpl with no luck.

My web service needs to respond with something like:
Code: [Select]
{
  "errors": [
    {
      "status": 400,
      "code": 4077,
      "title": "INVALID FORMAT",
      "detail": "invalid query parameter format",
      "source": {
        "parameter": "date",
        "example": "2019-03-09"
      }
    }
  ]
}

Stéphane Devouard

  • Diamond Member
  • *****
  • Posts: 122
  • PxPlus guru with skills in PHP, JS, C#, Java
    • View Profile
    • Stéphane's Web Resume
Re: Custom content for http error responses
« Reply #1 on: March 09, 2019, 11:05:43 PM »
Jeff

How about setting CONTENT_TYPE$ to application/json and
either EXIT_TEXT$ to your JSON error message
or write your JSON data to %print_fn ?

Stéphane Devouard
Portfolio | Work

Jeff Wilder

  • Silver Member
  • ***
  • Posts: 42
    • View Profile
Re: Custom content for http error responses
« Reply #2 on: March 10, 2019, 09:19:16 PM »
I have set %Content_Type$ and printed output to %PRINT_FN, but the web server continues to serve up a generic HTML page. I had never heard of setting EXIT_TEXT$. I just tried EXIT_TEXT$ and %EXIT_TEXT$ with no change.

Stéphane Devouard

  • Diamond Member
  • *****
  • Posts: 122
  • PxPlus guru with skills in PHP, JS, C#, Java
    • View Profile
    • Stéphane's Web Resume
Re: Custom content for http error responses
« Reply #3 on: March 11, 2019, 05:59:06 AM »
Sorry, I was thinking about %EXIT_TEXT$ but forgot the leading % when posting my response

Well, I guess you're using the Web Services stuff embedded within the newer versions of PxPlus

So far, any and all web services I have written in ProvideX were using V10 or prior versions, so were just CGI programs launched from Apache/IIS which were parsing incoming XML data and writing back XML responses to %PRINT_FN with the appropriate %CONTENT_TYPE$ and %EXIT_CODE set, and no pre-defined HTML was getting in the way if I happened to return anything else than an HTTP 200/201

So either you need to do the same, or I guess the Web Services maintenance interface needs some improvement on the PxPlus side with settings to either prevent it to spit out its predefined HTML pages in case of an HTTP 4xx ou 5xx status, or hooks to define special responses for special HTTP statuses

« Last Edit: March 11, 2019, 06:00:40 AM by Stéphane Devouard »
Stéphane Devouard
Portfolio | Work

Dirk

  • New Member
  • *
  • Posts: 1
    • View Profile
Re: Custom content for http error responses
« Reply #4 on: March 10, 2021, 06:17:32 AM »
Hi,

how did you write a real REST web service with providex ?
i wrote hundrets of different singel services for xml and json data, but i have no idea how to implement a real REST webservice in providex.
Maybe someone can give me a clue.

I am also interested how other people do the error handling, becuase i am not able to transfer the status code 400 back to the clients.

Thanks
Dirk

Mike King

  • Diamond Member
  • *****
  • Posts: 3810
  • Mike King
    • View Profile
    • BBSysco Consulting
Re: Custom content for http error responses
« Reply #5 on: March 10, 2021, 10:20:15 AM »
Dirk

Just an FWIW: In PxPlus 2021 due in May we have added a new global variable %Exit_include_html which you can set when you set %Exit_code to indicate you want the output you have placed in %PRINT_FN to be used along with the status code; something like this:

  json$["errors.1.status"]="400"
  json$["errors.1.code"]="4077"
  json$["errors.1.title"]="INVALID FORMAT"
  json$["errors.1.detail"]="invalid query paramete"
  json$["errors.1.source.parameter"]="date"
  json$["errors.1.source.example"]="2019-03-09"
!
  %content_type$="application/json"
  Write Record (%print_fn) DIM(LIST EDIT json${ALL})
!
  %exit_code=400
  %exit_include_html=1


We have this exact program setup on at https://www.pvxplus.com/march10.pxp so you can see the output which was based on the desired output that originally started this thread.

As for other REST style services our web services, available since PxPlus 2014, can be used to provide charts, reports, lists, and other data on demand -- suitable for use with JavaScript or other applications.  For details see:  https://manual.pvxplus.com/page/PxPlus%20Web%20Services.htm

Mike King
President - BBSysco Consulting
eMail: mike.king@bbsysco.com

Jeff Wilder

  • Silver Member
  • ***
  • Posts: 42
    • View Profile
Re: Custom content for http error responses
« Reply #6 on: March 12, 2021, 05:42:55 PM »
Thank you Mike. That is excellent! I can't wait to try it out.

Dirk, I wrote my REST web service for the PxPlus web server before PxPlus 2014 was available. If doing it today, I would most likely use the method Mike referenced in the manual.

Regards,
Jeff

Stéphane Devouard

  • Diamond Member
  • *****
  • Posts: 122
  • PxPlus guru with skills in PHP, JS, C#, Java
    • View Profile
    • Stéphane's Web Resume
Re: Custom content for http error responses
« Reply #7 on: March 26, 2021, 05:22:41 AM »
Dirk


At my last PxPlus job, I wrote a web service for CRUd operations on the main resources in the system (vendors, customers, employees, jobs, etc...)
No actual Delete operations were allowed -- but an update operation setting the ACTIVE field to false was roughly equivalent to deleting a record ;)


I used the IIS CGI interface as the product was installed exclusively on Windows servers
Only GET & POST operations were initially available, and the payload / body part of the requests was XML


I reworked a second version of this stuff, but I don't think it has been deployed after I was let go


The second version was using the URL Rewrite module in IIS to redirect requests to a front-end controller using an URL pattern
e.g.
GET https://www.myserver.com/api/customers becomes https://www.myserver.com/somefolder/restapi.pxp?route=/customers
POST https://www.myserver.com/api/customers/new becomes https://www.myserver.com/somefolder/restapi.pxp?route=/customers/new
PUT https://www.myserver.com/api/customers/010000 becomes https://www.myserver.com/somefolder/restapi.pxp?route=/customers/010000


Then the restapi.pxp front-end controller would parse the HTTP headers for authentication and authorization, the route$ CGI variable for the entity/resource identification, the payload as well as the HTTP method to call the appropriate CRUd routine and perform the database operation.

Hope this helps
« Last Edit: March 26, 2021, 05:26:33 AM by Stéphane Devouard »
Stéphane Devouard
Portfolio | Work