Welcome to the SRP Forum! Please refer to the SRP Forum FAQ post if you have any questions regarding how the forum works.

error http frameworks setup

get this eoor when I add a new resource and resource id.
clicked apply then clicked 'create api' and got this error


Comments

  • I see that it means compile error.
    I now see that extra code has been added to apijobclock , I assumed it was only creating api for newly added resources.

    this is what was added to the end of apijobclock existing code (got double defined compile errors)

    API apijobclock.{resourceid}.HEAD API apijobclock.{resourceid}.GET HTTP_Resource_Services('LoremIpsum') end api API apijobclock.{resourceid}.POST HTTP_Resource_Services('LoremIpsum') end api API apijobclock.{resourceid}.PUT HTTP_Resource_Services('LoremIpsum') end api API apijobclock.job.HEAD API apijobclock.job.GET HTTP_Resource_Services('LoremIpsum') end api API apijobclock.job.POST HTTP_Resource_Services('LoremIpsum') end api API apijobclock.job.PUT HTTP_Resource_Services('LoremIpsum') end api
  • I remember I had changed the apijobclock earlier and just did 'apply' as the api was already created.
  • removed this, but it keeps adding it.
    API apijobclock.{resourceid}.HEAD API apijobclock.{resourceid}.GET HTTP_Resource_Services('LoremIpsum') end api API apijobclock.{resourceid}.POST HTTP_Resource_Services('LoremIpsum') end api API apijobclock.{resourceid}.PUT HTTP_Resource_Services('LoremIpsum') end api


  • @BarryStevens - This was a bug in a low-level service that only occurred when the name of your resource started with the same letters as your API root. In this case, your resources started out as "API" or "api" and your API root is also "api". I have a fix for this, but I do recommend not naming a resource with a prefix of "api". It's a bit redundant and doesn't define your resource in a meaningful way.
  • I did it so I could see them all grouped to-gether .
    I will change them to another prefix.
  • You can drag the top-level resources up and down to group together.
  • Sorry, I meant in the ssp list
  • Gotcha. Well, I do understand the desire to keep your stored procedures sorted. However, this approach sort of moves away from the appeal of Semantic URLs (and RESTful design) and turns it into more of an RPC (remote procedure call) design, which is what INET/O4W APIs are.
Sign In or Register to comment.